.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 (21)
  1. You’ve been kicked (a good thing) – Trackback from DotNetKicks.com

  2. MichaelGG says:

    I agree with the rationale – as long as people can go running unmanaged code willy nilly.

    But that makes me wonder: What’s different in the security analysis in 2008 than it was in 2001 or so (why wasn’t it like this since 1.0/1.1/2.0…)?

  3. This has got to be one of the most consistently asked for "features" of .NET from the start!    

  4. Link Listing – August 13, 2008

  5. WPF dabbling around the new WPF datagrid (part 1) [Via: jaimer ] Code Camps Southwest Florida Code…

  6. .NET applications now run off network path

  7. [.NET FX SP1] Eseguire codice unmanaged da uno share di rete

  8. Khurram Aziz says:

    Soma announced the availability of Visual Studio 2008 Service Pack 1 and .NET 3.5 Service Pack 1 . Installation

  9. Visual Studio 2008 SP1 and .NET Framework 3.5 SP1 enhancements

  10. CoqBlog says:

    Ca se confirme, c’est dans le SP1 de .NET 3.5 qui a été publié cette semaine : si lancées directement

  11. .NET Framework 3.5 SP1 consente l’esecuzione di codice unmanaged da una share di rete

  12. darrenkopp says:

    can i give you a hug? i’m so happy right now i just don’t know what to do.

  13. To answer the question: what is differnet now than when we shipped that promped the change?

    The simple answer is that we made a mistake.  In 2001 we believed we are the avant-guard in making things ‘secure by default’ and thus biased our decisions believing that we would eventually ‘plug’ the hole of unmanaged code running from a network share.   We also did not appreciate the pain this decision would cause.  

    However over time, we realized that we were naive.    The cost/benefit of changing the behavior of unmanaged code is simply too high.   Moreover it also become clear that for security to work, it must be simple, which means treating cases uniformly.   Thus if you want to disallow launching exes off the network you should not have one way of doing it for managed code, and a completely different way for unmanage code.  

    In fact there IS a way of locking down exe launch uniformly (see Security Policies above), so really it became abundantly clear that really the ‘right’ approach is to treat security wholisitically (not just the managed case) and make managed code and unmanaged code as simmilar as possible (after all from an end user’s perspective, who cares if code is managed or not?)

    So to sum up, we made a mistake (frankly we make lots of them), and sadly it is VERY difficult to fix mistakes when you have millions of users to break, and even more so when security is involved.   Thankfully, in this case we were able to convince ourselves that we could  fix this one after the fact.

    Vance   (.NET Runtime Architect)

  14. JWilcox says:

    Awesome!!! Thanks a TON for pushing for this Vance, I can’t wait to start using it!

  15. Thank you.  This makes things much easier.

  16. Launch .NET apps from network share

  17.    With the release of the new Service Pack 1 for the .NET Framework 3.5 several changes were

  18.    With the release of the new Service Pack 1 for the .NET Framework 3.5 several changes were

  19. 【原文地址】 .NET Framework 3.5 SP1 Allows managed code to be launched from a network share! 【原文发表日期】 13 August

  20. Subli says:

    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,


  21. Jack says:

    Has this problem resurfaced in CLR4?

Comments are closed.

Skip to main content