.NET Framework 3.5 SP1 Allows managed code to be launched from a network share!
Hurray, its finally fixed! manage code 'just works' from network file share!
Now I know that some of you are probably just saying 'who cares' or 'huh?' but for those of us who have hit this problem, this has been a major deployment headache, and I am happy to say that the end of this particular problem is in sight.
The problem scenario is this. If you have a managed applications like 'MyApp.exe' it works great if you run it locally (eg C:\bin\MyApp.exe), but fails when you try to run it from a network location (eg \\Myhost\bin\MyApp.exe). The problem is that the security system for the runtime treats network locations as less trustworthy than local locations, and thus throws an security exception. The problem is that failing to run managed code WHILE STILL ALLOWING UNMANAGED EXE's to run, does not provide any security (because hackers will simply use unmanaged code) but does cause nontrivial deployment headaches (manage apps can't be run from network locations).
Well, the better part of a year ago I ask Brad Abrams to do a poll on this issue and we found that there was quite a bit of customer deployment pain associated with this issue, and after much deliberation decided to fix it. The exact details were covered in Shawn Farkas Blog, however the high level take-away is that for the vast majority of scenarios 'it just works' meaning that managed code acts just like unmanaged code as far as launching EXE from network shares are concerned.
So I do encourage you to down load the .NET 3.5 SP1 service pack. It is a very low risk, drop-in update for the runtime. Once you do this, you get network launch for free. Because it is a service pack, you can also simply just wait, and get the update automatically in the next several weeks via windows update. Thus if you are software deployer, pretty soon now, with high probability your customers will have this newer runtime.
Have fun!
P.S: for those of you who are concerned that we have opened security holes by doing this, we have tried to be VERY careful not to do this. The basic rationale is that we are not opening any holes that were not already there because Windows allows non-managed exes to run from a network share. By the way, if you WANT to lock down your network access (prevent exes from a network share from running, (or even just exes that are in speical locations), you can do this with Software Policies. That is the proper way to lock down your computer.
Comments
Anonymous
August 13, 2008
You've been kicked (a good thing) - Trackback from DotNetKicks.comAnonymous
August 13, 2008
The comment has been removedAnonymous
August 13, 2008
This has got to be one of the most consistently asked for "features" of .NET from the start!    Anonymous
August 13, 2008
Link Listing - August 13, 2008Anonymous
August 13, 2008
WPF dabbling around the new WPF datagrid (part 1) [Via: jaimer ] Code Camps Southwest Florida Code...Anonymous
August 13, 2008
.NET applications now run off network pathAnonymous
August 13, 2008
[.NET FX SP1] Eseguire codice unmanaged da uno share di reteAnonymous
August 13, 2008
Soma announced the availability of Visual Studio 2008 Service Pack 1 and .NET 3.5 Service Pack 1 . InstallationAnonymous
August 14, 2008
Visual Studio 2008 SP1 and .NET Framework 3.5 SP1 enhancementsAnonymous
August 14, 2008
Ca se confirme, c'est dans le SP1 de .NET 3.5 qui a été publié cette semaine : si lancées directementAnonymous
August 14, 2008
.NET Framework 3.5 SP1 consente l'esecuzione di codice unmanaged da una share di reteAnonymous
August 14, 2008
can i give you a hug? i'm so happy right now i just don't know what to do.Anonymous
August 14, 2008
The comment has been removedAnonymous
August 14, 2008
Awesome!!! Thanks a TON for pushing for this Vance, I can't wait to start using it!Anonymous
August 15, 2008
Thank you. This makes things much easier.Anonymous
August 20, 2008
Launch .NET apps from network shareAnonymous
August 27, 2008
   With the release of the new Service Pack 1 for the .NET Framework 3.5 several changes wereAnonymous
August 27, 2008
   With the release of the new Service Pack 1 for the .NET Framework 3.5 several changes wereAnonymous
September 07, 2008
【原文地址】 .NET Framework 3.5 SP1 Allows managed code to be launched from a network share! 【原文发表日期】 13 AugustAnonymous
February 15, 2009
This change WAS acceptable if you kept the default behaviour intact and simply added the evidence of MyComputer to the network launched application by setting a registry key something like "ExpandMyComputerZone" to 1. How come can't you imagine changing default behaviour of run-time causes huge problems? It looks like all of sudden you began following any demand of republican and didn't give an inch to GOP, though Redmond has been for republican, as long as I know. I sincerely want a word from you, Thanks,Anonymous
November 21, 2010
Has this problem resurfaced in CLR4?