0

Short story

I have a weird problem and couldn't find any solution for it across internet.

This is probably not important for a problem but I prefer to mention that I had two separate projects and decided to combine them into one solution. Both projects were/are simple winform application. They worked separately after compiling: directly in Visual Studio during debugging (no matter in debug or release mode), locally outside debugger and after copying them into some folder on local network.

However after merging them, one of the application stopped working when it is started from the network.

Stop working means?

I attached debugger to the already running process and found out that:

  1. Code in frmMain.Designer.vb in Partial Class frmMain in Private Sub InitializeComponent() works properly. This is checked by making a breakpoint at the begin of Sub and going step-by-step through the code until End Sub.
  2. Code in frmMain.vb in Public Class frmMain in Private Sub frmMain_Load(sender As Object, e As EventArgs) Handles MyBase.Load is not triggered. After going out from InitializeComponent() (point 1) code does not enter frmMain_Load. Main form is shown on the screen with all controls but not initialized/cleaned, without icon etc.
  3. Clicking some buttons on main form allows me to open child forms but they are also not initialized/cleaned.

  4. Closing child form by clicking on "X" doesn't close the form (normally does). Clicking on cmdClose button on the same child form closes the form. Button has DialogResult property set to Cancel. Form itself has CancelButton property set to cmdClose. Pressing ESC also closes the form.

    Private Sub cmdClose_Click(sender As Object, e As EventArgs) Handles cmdClose.Click
    Me.Dispose()
End Sub

  5. Closing the main form (no matter if by "X", cmdClose button or ESC) hangs up the application.

    Private Sub cmdClose_Click(sender As Object, e As EventArgs) Handles cmdClose.Click
    Me.Close()
End Sub

  6. If I open Windows Explorer and go to the final location of application on shared network drive starting from the mapped drive Y:\folder and start application from there - it works.

  7. However if choose the same final destination through \\server\share-name\folder and start application from there - it doesn't work.
  8. Point 6 and 7 acts the same if application is started by a shortcut on desktop and in this shortcut target path to application is defined in one of the two methods.

Windows 7, .Net Framework 4.5.

Do you have any clue how to solve it and where the bug is?

yarecky
  • 97
  • 8
  • Are you deriving your classes or something of the sort? It almost looks like you combined the projects but the code is still using a reference to a DLL. – JuanR Mar 30 '17 at 17:49
  • There are two different permission sets that could be the cause. "NTFS" permissions would give you access to the directories as if you were on the machine, but shared folder permissions are different. The issue could be that the users don't have access to all the folders/files required by the app via the share, but they do via NTFS. A second potential issue could be in the way that you are building file paths, but it's hard to tell anything without any code. – ps2goat Mar 30 '17 at 17:57
  • 1
    I believe .NET programs run under different CAS policies depending on where they are started from. You can try the config setting mentioned [here](https://weblog.west-wind.com/posts/2011/Mar/22/Loading-Assemblies-off-Network-Drives) to see if it helps you. – Bradley Uffner Mar 30 '17 at 17:59
  • @Juan @ps2goat No, I'm not deriving anything. These apps worked when they were alone no matter how they were started and by who. Myself I have problem when I start the app from explorer which normally opens using server path not mapped path. These were working previously as they are not version 1.0.0.0... I fixed the situation for now by changing shortcuts in all users by modifing path to target by `Y:\` not `\\sever\`. I have no point why code does not switch from `InitializeComponent` to `MyBase.Load`. – yarecky Mar 30 '17 at 18:02
  • @Bradley Uffner Tomorrow at work I'll check it as I have no clue after spending hours trying to find root cause. Thanks. I'll keep you inform. – yarecky Mar 30 '17 at 18:04
  • @Juan To be precise, both apps reference to the same `dll` (3rd project, multiple classes, own namespace). Because each of the apps compile to own subfolders under main solution folder, compiled `dll` is copied to both subfolders obviously. These apps are completely different and works separatelly and are distributed to different users. I combined projects to stop wasting time on verifying if added/changed code is shared `dll` project has impact on any of apps. – yarecky Mar 30 '17 at 18:16
  • I would suggest you compare the call stack in local vs network versions for step 2 that you mentioned in your original post. It might give you clues. – JuanR Mar 30 '17 at 18:59

1 Answers1

0

Explanation of error

I decided to extract the icon from application executable instead of resource like it was before to avoid adding two times the same icon file to the executable: first as an application icon which is added in Project/Properties/Application/Icon and second as an form icon added in Project/Properties/Resources.

The problem is if in any place in code (in my example in Private Sub form_Load(sender As Object, e As EventArgs) Handles MyBase.Load) you add

Me.Icon = Icon.ExtractAssociatedIcon(Assembly.GetExecutingAssembly().Location)

it will not work with UNC paths returning

System.ArgumentException
The filePath does not indicate a valid file or the filePath indicates a Universal Naming Convention (UNC) path.

Error occurs in runtime after form closing. Method

Assembly.GetExecutingAssembly().Location

returns correct path (as string for example \\server\share-name\folder) but method

Public Shared Function ExtractAssociatedIcon(filePath As String) As Icon

does not accept UNC path.

Solution

To solve this issue 2 clumsy solutions are proposed here and here.

Community
  • 1
  • 1
yarecky
  • 97
  • 8