.NET executable won't load referenced assemblies when started from \\localhost\xyz

Question

My .NET executable abc.exe references several assemblies. One of them is called xyz.core.exe. I have trouble getting it to work when it is being started from a network location specified through a share name with a path such as \\localhost\xyz\abc.exe. This works fine if I mount a network drive letter named Z: on \\localhost\xyz and if I launch Z:\abc.exe.

.NET seems to become confused while trying to load the xyz.core.exe assembly from the share. It throws a System.IO.FileNotFoundException exception with the following fusion log information:

Assembly manager loaded from:  C:\Windows\Microsoft.NET\Framework\v2.0.50727\mscorwks.dll
Running under executable  \\localhost\xyz\abc.exe
--- A detailed error log follows. 

=== Pre-bind state information ===
LOG: User = Workstation\arnaud
LOG: DisplayName = xyz.core, Version=2.5.2.1001, Culture=neutral, PublicKeyToken=...
(Fully-specified)
LOG: Appbase = file://localhost/xyz/
LOG: Initial PrivatePath = NULL
Calling assembly : abc, Version=1.0.0.0, Culture=neutral, PublicKeyToken=...
===
LOG: This bind starts in default load context.
LOG: No application configuration file found.
LOG: Using machine configuration file from     C:\Windows\Microsoft.NET\Framework\v2.0.50727\config\machine.config.
LOG: Post-policy reference: xyz.core, Version=2.5.2.1001, Culture=neutral, PublicKeyToken=...
LOG: Attempting download of new URL file://localhost/xyz/xyz.core.DLL.
LOG: Attempting download of new URL file://localhost/xyz/xyz.core/xyz.core.DLL.
LOG: Attempting download of new URL file://localhost/xyz/xyz.core.EXE.
LOG: Attempting download of new URL file://localhost/xyz/xyz.core/xyz.core.EXE.

Looking at this through another angle with Process Monitor, I see a few attempts to access on my local drive with the following paths:

C:\xyz\xyz.core.dll
C:\xyz\xyz.core\xyz.core.dll
C:\xyz\xyz.core.exe
C:\xyz\xyz.core\xyz.core.exe

as if the loader mis-understood the intent of loading from a network share and dropped the \\localhost to use C: instead. The problem seems not to be related to security settings (I have never messed with CASPOL on my machine) and I am using .NET 3.5 SP1 which allows executables to be started from a share.

And the fact that starting the program through the equivalent mapped network drive letter works should confirm that this is not a security issue.

The problem is not related to the fact that the reference is to an EXE assembly either, as it produces the same kind of load errors with references to plain DLL assemblies.

Any ideas of what could be the cause of this loading problem? Has anybody else run into such a situation?

Judson

Your trace shows that the \\localhost\xyz share is mapped to c:\xyz. That sounds reasonable. What is it actually mapped to and where are the assemblies? – Proverbs

Answer 1

I can't explain the "C:\xyz\xyz.core.dll" (except as a curiosity), but the rest is exactly what I would expect.

This seems all tied into code-access security. Until recently, you would need to use "caspol" to configure CAS to allow you to execute the exe from any type of network share. This was changed (either .NET 3.5 or .NET 3.5 SP1) such that mapped shares ("f:" etc) do get execute permission, but UNC shares do not.

You can use "caspol" to grant access to the UNC (like this), but IMO it is a far better option to switch to ClickOnce deployment. This can still be via a network share, but it includes additional publication information that lets the runtime mount it. I believe it can also be used to deploy such that it works offline (when the network is unavailable) but update automatically from the share when possible I know this works for http deployment - I believe it works for network). The IDE presents this under the guise of "publish", and it is about 5 clicks all done.

Deland

Answer 2

I am confused - if you use localhost it is supposed to go to the local harddrive.

Are you trying to remap the localhost to point elsewhere? If this is the case this can be what causes problems - try to use a different name

Lankester

No, going through \\localhost\share forces Windows to go through the network stack at some point and access the share itself, not map to the local disk directly. Using the real name of the machine I am using produces exactly the same result. – Judson