views:

598

answers:

4

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?

A: 

use this:

Start this then run your app:

http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx

this will show you exactly what is going on under the hood

James Campbell
This is what I initially did: run Process Monitor to see what was happening. And I can't still figure out why .NET is trying to load the referenced assembly from the wrong path...
Pierre
+1  A: 

This answer might far off, but I've run into it before, it could be something to look into.

http://johnnynine.com/blog/RunningANetApplicationFromANetworkShare.aspx

kaze
It is highly recommended to run .NET application locally instead of from a network share.
Lex Li
This was valid before .NET 3.5 SP1. In 3.5 SP1, Microsoft decided to grant full trust to .NET programs started from a share. See for instance http://blogs.msdn.com/shawnfa/archive/2008/05/12/fulltrust-on-the-localintranet.aspx.This is not the issue at hand. Or else, the execution from the Z:\ path would not have worked either.
Pierre
A: 

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

mfeingold
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.
Pierre
+1  A: 

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.

Marc Gravell
ClickOnce doesn't support command line applications.
sixlettervariables