Why does my .NET application crash when run from a network drive?

Question

My .NET application fails when run from a network drive even when the very same executable runs perfectly fine from a local hard drive?

I tried checking for "Full trust" like so:

try
{
    // Demand full trust permissions
    PermissionSet fullTrust = new PermissionSet( PermissionState.Unrestricted );
    fullTrust.Demand();

    // Perform normal application logic

}
catch( SecurityException )
{
    // Report that permissions were not full trust
    MessageBox.Show( "This application requires full-trust security permissions to execute." );
}

However, this isn't helping, by which I mean the application starts up and the catch block is never entered. However, a debug build shows that the exception thrown is a SecurityException caused by an InheritanceDemand. Any ideas?

Credent

When you say it "fails", how exactly does it fail? Are there errors? – Aam

Does the code you write goes in the Catch? – Venesection

just got this same problem today and haven'T found a solution yet, will be watching this question... – Equivalence

Answer 1

It indeed has to do with the fact the apps on a network location are less trusted then on your local hdd (due to the default policy of the .NET framework).

If I'm not mistaken Microsoft finally corrected this annoyance in .NET 3.5 SP1 (after a lot of developers complaining).

I google'd it: .NET Framework 3.5 SP1 Allows managed code to be launched from a network share!

Cark

Verified this by having the affected users download the Service Pack, and all is good. Thanks! – Credent

Excellent! I've had to use CasPol before with a utility we created for some of our customers. It's a pain having to create a script and have it run before your utility is called, just because it's run from a network location. – Doubletree

Update: The problem fixed in .NET 3.5 SP1 seems to reappear when the .NET 4.0 runtime is installed. – Kaunas

I second {0xA3}. Couldn't figure out why I have .NET 3.5 SP1 but I still see this problem - and everyone says that SP1 fixes it. But I also have version 4 installed, so you maybe be on to something there. – Isotherm

Answer 2

Did you try Using CasPol to Fully Trust a Share?

Comber

Almost upvote-worthy, but it provides the solution without explaining the problem. – Dort

Answer 3

You may have already done this, but you can use CasPol.exe to enable FullTrust for a specified network share.

For example

cd c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727
CasPol.exe -m -ag 1.2 -url file:///N:/your/network/path/* FullTrust

More info here.

Ragan

Lazy dev version: C:\Windows\Microsoft.NET\Framework\v4.0.30319>CasPol.exe -m -ag 1.2 -zone Intranet FullTrust – Cardiology

Access is denied (from Admin shell). Typical windows. I am actually trying to run something from a VM shared to the host, needed to run office versions. – Karlee

Answer 4

If this is .NET 2.0 or greater, ClickOnce was created to really help with this deployment stuff. I only deploy to network shares using that.

Aam

Answer 5

This is security built in by microsoft into the .net framework. It's a way of stopping malware to be run locally with full priviliges, so you cannot change this programmatically in the code.

What you need to do is increase the trust of specific assemblies. You do this in the .NET Framework Configuration (Control Panel->Administrative Tools), and has to be done on each computer.

As with any security measures, it's a pain-in-the-ass, but will help the world to be less infected etc...

Interdepartmental

...stopping malware... How many malware have you found written in .NET? Any non .NET executable will be able to run from the network using full privileges (by default). The only difference is that .NET did not allow it by default while windows does. – Cark

well, blocking managed code while still allowing Win32 binaries to be executed is not a security measure... – Hurleigh

Answer 6

All I had to do was mark the files Read Only (possibly unrelated) and give all permissions except Full Control to Authenticated Users. I was encountering this issue before I did that, when I had the network share only setup for Domain Users.

I discovered this workaround because neither the admin shares (\server\C$) nor my own PC's shares had this problem.

Edit: App is targeting .NET 3.5, no SP1 here (version 3.5.7283)

Yang