Poll: Allowing .NET EXEs to run off a network share


By default .NET applications (EXEs) that are launched from a remote file system (eg \\server\bin\SomeApp.exe), will not be considered trusted and typically will fail (unless specifically designed to run with low trust).  This is in direct contrast with unmanaged applications which always give full trust to launched programs, regardless of location.  From a quick search, I know many of you have run into this issue and have found some work arounds

The .NET runtime team is considering changing this behavior so that managed applications act just like unmanaged one in this respect.  We believe that it will not decrease security, but there is risk and effort required for any change and would like feedback on its likely usefulness to customers.  image

A) Have you ever run into this limitation (a security exception when running a .NET application from a network file share)?

B) How often do you use network file shares for deploying applications (managed or otherwise)?

C) If you think we should make this change, when would be a good time?  Is it something we should do sooner in a service pack of the .NET Framework or later in a full release of the framework.   Note, we are DONE with .NET Framework 3.5, so there is zero chance it is getting in that release. 

D) Can you ask your local network admin what they think of this issue?  Would they be in favor of this sort of change?  If so, when?

Please comment on this post, link back to your post or send me an email!


Update: 10-28:
I passed the early feedback around the CLR team, and they suggested I added some clarification on the propsosed change…


 


1)     The change we are considering is best thought of not a change in policy, but rather new evidence associate with launching an EXE.    This new evidence would only exist if a managed EXE was loaded by the win32 CreateProcess API direct.   Thus it does NOT affect hosted scenarios (eg web browsing on the Intranet).     


2)      We believe that this will NOT reduce security in any meaningful way because when you launch an EXE off a file share, you ARE trusting the file share.   That EXE can be unmanaged code, and as such it has the ability to do ANYTHING the current user can do.    Thus disallowing managed EXEs (but continuing to allow unmanaged EXE to launch), does not serve a useful security purpose.   


 I hope that helps…


Update (8/13/2008):  Thanks to your feedback, we just enabled .NET EXEs to run off a network share in SP1. 

Comments (155)

  1. Struan says:

    I ran into the problem during development. (Developing from a network share) It was only a minor inconvenience.

  2. Marc Brooks says:

    There should be no difference between an .EXE running from a local drive vs. a mapped drive or a UNC. As it is now, however, this prevents deploying software to diskless workstations and really hosed a setup we wanted to use for POS workstations in a major retailer. In the end, ironically, we ended up hosting everything in kiosk-mode IE.  That’s a really hokey workaround.

  3. By default .NET applications (EXEs) that are launched from a remote file system (eg \serverbinSomeApp

  4. gblock says:

    I have ran into this problem working at several small ISVs. We ran into this as we migrated a very large legacy VB app. In these environments having to copy everything local was not a viable solution, especially for the various QA and executives throughout the company who wanted to run the latest stable build. We worked around this by creating a custom policy that would trust the network location. It was a real paint point for us until we determined the work around.

  5. Mark Sowul says:

    I suspect the majority of people will be more strongly in favor of the convenience afforded by changing this – but what about the ability to mark "trusted servers"?  This way, if you’re launching an app off a company application server, it isn’t the same as if you’re launching a random app off a coworker’s PC.

  6. Stefan Koell says:

    If you ask me, allowing .NET EXEs from network shares or UNC paths should be allowed by default – at least in the local network. .NET 1/1.1 allowed to turn off security completely which was great for development. Newer version only allowed to trust explicit locations – which is a pain to maintain.

    My wish would be: bring back the caspol -s off to disable it completely for development off network shares. AND create some easy maintainable group policy objects to define trusted UNC and mapped network drives in controlled desktop environments.

    cheers

  7. Stefan Koell says:

    If you ask me, allowing .NET EXEs from network shares or UNC paths should be allowed by default – at least in the local network. .NET 1/1.1 allowed to turn off security completely which was great for development. Newer version only allowed to trust explicit locations – which is a pain to maintain.

    My wish would be: bring back the caspol -s off to disable it completely for development off network shares. AND create some easy maintainable group policy objects to define trusted UNC and mapped network drives in controlled desktop environments.

    cheers

  8. Micky says:

    A) Often

    B) Quite often. We either use network shares or SFX zip files on network shares.

    C) As soon as possible πŸ™‚

    D) They couldn’t care less since we have already many native EXEs run everyday from shares everywhere.

  9. A) Too many times.

    B) For managed apps – zero, since I know the limitation exists. If it weren’t for the limitation, I would start using this method much more often.

    C) I would think that a dedicated patch (for all framework versions(!)) would be in order, as well as every service pack that comes out and the framework’s vNext.

    D) Same as Micky above me.

  10. Henry Boehlert says:

    The underlying problem is that it’s way to hard to configure CAS. Fix this and everything else just falls into place.

    A) We’re running our build tools from ClearCase MVFS drives which are mapped as network drives.

    B) Only for development/build/test.

    C) For the next standalone framework.

    D) It’s hard to explain why native and managed are treated differently. You should find a solution that applies to both.

  11. John says:

    A) Often.

    B) I don’t because of the current limitation; I would like to.

    C) Service pack ASAP.

  12. Byron says:

    A) Often

    B) I would use executables from network shares more often if I knew there would not be runtime security issues.

    C) The next standalone framework version.

    D) They would prefer it since we would not have to copy as many files locally to servers.

  13. Peter Ritchie says:

    A) often

    B) I’ve had a couple of clients where the My Documents directory was actually on a network share.  Which make developing .NET applications with the default installation of Visual Studio rather difficult.

    C) After 7 or so years with this "feature" I think it’s a little late to change now.  It’s destabilizing and will make lots of code/installs redundant/broken.  Testing it will be a nightmare.  For example, if someone has modified policy to allow a subset of fulltrust on single UNC what will a newly deployed fulltrust for UNCs do to that policy?

    D) Most of the network admins I deal with would simply turn the feature back on by configuring network shares to be lower privilege.

    Yes, it’s been a pain point for many the past 7 years; but so have many quirks in .NET, many quirks that can’t be changed because many people are already relying on that functionally.  This policy is the same.

  14. Steve Owens says:

    First off, THANKS FOR ASKING!!  Just hearing the question posed from MS’s side brightens my day.

    A. Yes!  I can’t say "often", since after the first time, you’ve been "burned".  But I do *think* about it each time I have to write/deploy an app locally.

    B. I feel strongly that a local network share should be trustworthy, because the company treats employees as trustworthy.  This has been an issue, particularly as was mentioned already, with diskless workstations.  Sometimes, the Smart Client model is just not a good option.  We ended up going with the more expensive Wyse model with XP and lotsa memory so that we could have a "local PC" and install our apps.  

    C.  ASAP.  I could wait until 3.5.  πŸ˜‰

    D.  It would not make their lives any more difficult.  They would not really notice any difference at all, our LAN is not particularly restricted.  It would just make the dev’s life easier.

  15. divil5000@hotmail.com says:

    A. Yes

    B. Fairly often

    C. Major release

    D. They are in favour of this change

  16. Nitin says:

    A) Yes we have run into this issue and its pretty

    annoying.

    B) Nearly all software applications that we create need to be accessed from the network

  17. qwerty says:

    Please let those managed apps run form the network share. This has been a pain at the office. We just use click once instead.

  18. a) I run into this issue occasionally.  Often enough to be frequently annoyed, but not often enough to remember how to change the permissions.  Usually I just give up and make a locas copy.

    b) I do not anticipate deployment to a network share.  (I have reliability requirements that include functioning without network support.)

    c) This is a major change in the security expectations of the .NET framework.  I would expect this change to be in a major release and not a service pack.

    d) I don’t work with any network admins.  (One man ISV.)

  19. KISHOR says:

    Yes, Please consider this change as soon as possible, we have written separate applications to just do this!

    Answers:

    A) It is not often that we run into this problem but it is ALWAYS we run into it.

    B) Always run from network all .Net apps

    C) ASAP

    D) Not sure and also don’t care

  20. Aaron Lerch says:

    A) We’ve run into it deploying some common tools (that don’t require an install) to network shares.

    B) We use network shares frequently for internal applications, and our customers use it on occasion for some of our support software

    C) I think changing this in a service pack would be fine, as it isn’t breaking, it’s "enabling" – it would need to be well documented, of course

    Thanks!

  21. Mike says:

    A) Some times

    B) We’re using ClickOnce, it’s a considerable solution.(the application will run as a trusted application in spite of the fact that our clients is running on the network’s security policies)

    C) Since there’s some alternative solutions, that’s not a critical issue, maybe in next generation of the .NET Framework

    D) Here, our network man prefers to not change anything (lazyyyy man!! :D)

  22. Mike Swaim says:

    A) Yes, I have run into this limitation. I ended up going with ClickOnce to get around it, but that has problems of its own. (Certificate expirations, can’t put debug and production versions of the app on the same machine.)

    B) We use network file shares for our non-net applications. It obviously doesn’t work without a lot of futzing agound for .net programs.

    C) It should be in a service pack.

    D) Our division network admins don’t care, since they don’t handle application deployment. (We have a designated developer for deployment.)

  23. jim welch says:

    A) Often

    B) Very often

    C) As soon as possible. Service pack if possible.

    D) Already have multiple other executables running from network drives, so not an issue.

  24. You’ve been kicked (a good thing) – Trackback from DotNetKicks.com

  25. monkey {no} magic says:

    interesting. yes i have had issues with this. in the early days a big thing was made of xcopy deployment, most lateral thinking devs/network admins immediatley tried deploying to a share only to find that it was SO NOT xcopy in this scenario. that said I totally agree with peter richie. perhaps a switch in either the .config or pre-clr .ini file would be a good solution for future framework releases??

  26. Aaron says:

    A) yes.

    B) since you currently need to setup trust for the application or path not very often.  the real benefit would be to have a simple app that does not need an installer.

    C)As soon as possible.

    D)They would prefer it.  It would limit the need to do client installs. But we do have group policy to allow our apps to run.  Just be nice make this easy for our customers.

  27. Jeremy says:

    A) Yes

    B) For the majority of our .NET apps

    C) I’d leave in the current behavior as the default, but make it easier to configure trust for network locations.  The caspol utility is not user friendly and I miss the configuration GUI that was installed prior to 2.0.

  28. Shawn Oster says:

    Yup, <a href="http://a-simian-mind.blogspot.com/2007/07/running-net-20-app-from-network-share.html">ran into this</a> the other day and I found it amazingly annoying.  Not sure why anyone ever thought this was a good idea.

    Anyway, please oh please make an EXE, regardless of .NET or native, run the exact same from a share as from a local drive.  It’s issues like this that I pick Delphi over WinForms for Win32 development.

  29. Rossco says:

    To me, a network share is virtually the same as a local drive considering 1GB connectivity is almost the norm these days in a business.

    A) Yes

    B) If this was allowed, would do all the time for dev and UAT versions of software. (ClickOnce is used for Prod)

    C) Make the change the default in the next major verion (.net 4?) and provide a easy workaround to until then.

    D) As long as the change is easy our network team wouldn’t have any problems (maybe via a Group Policy until this is made the default in the next version)

  30. Patrick Bennett says:

    A) Yes

    B) Often

    C) The sooner the better

    D) Not an issue – it’s a hassle for them as well.

  31. dmurillo says:

    A) Yes, often

    B) Very often

    C) ASAP, a service pack for every version of .NET

    D) As stated by Micky above: They couldn’t care less since we have already many native EXEs run everyday from shares everywhere.

  32. Alfred Myers says:

    A) Yes. Back in 2003 when I was doing Windows Forms applications development we were considering using a file share for deployment.

    B) Never. It seems a bad idea since the files get locked for updates if there is at least one instance of the application running. Imagine that happening at places where people don’t shutdown their computers and leave the application running. I never tried to circumvent this, but if it is possible then it might turn into a good option.

    C) I’m not really concerned about this.

    D) I don’t have one at hand now. Mine is very concerned about security so he would probably prefer the things as they are now, but since unmanaged applications can run, I don’t know if this is really an issue.

  33. A) Yes, I ran it to it twice…until I just decided to store everything I develop locally because at the time I couldn’t determine the workaround.

    B) Sometimes.

    C) The change should be done sooner rather than later in a service pack.

    D) They are not likely to care about this.

  34. Anastasiosyal says:

    A) Often. Our software is located on an internal app server that everyone accesses via a share.

    B) Often. Integral part of our architecture.

    C) As soon as possible

    D) It would make sense to have this restriction if it also applied to unmanaged exe’s

  35. Alan Rueckgauer says:

    A) Yes.  This is a major problem, since most of my customers use folder redirection.

    B) Frequently

    C) ASAP.  Push a Service Pack.  Make it configurable, with the default being the current state to prevent unintended/unforeseen issues.  Collect all of the affected settings into a single one-form panel instead of the PITA .NET config tool we currently have that are confusing as all heck.

    D) Irrelevant if the default is for things to stay as is, and a straight-forward config control panel for changing is included.

  36. julian says:

    A) Yes

    B) Every multi-user winform project on a LAN (which is about all my winforms projects)

    C) ASAP. Normal exe’s can do it so why bother disabling .net

    D) ASAP. Now we use batch files to copy to local disk.

    What if there is no local disk ? Allow this app by hand on all workstations ?

  37. Mike says:

    A) Yes

    B) Most winform projects, which are used by multiple workstations.

    C) ASAP.

    At least some management tools like in .Net 1.1 should be installed with the runtime per default.  The managementools should allow to export specific setting for an app as script for deploy as logonscripts to other machines.

  38. Bruce says:

    Many developers in our company are using ClearCase dynamic view in development. The dynamic view is working as a network drive so we always run into this issue. It’s not hard to resolve it but it’s annoying that there is no easy way to turn it off (or on).

  39. Igor Abade V. Leite says:

    A) Several times. Most than often it could be avoided by using ClickOnce, but most companies haven’t even heard of it (sad but true).

    B) Unfortunately, almost always. There are customers who still believe that’s the best way to redistribute and keep internal applications up-to-date.

    C) It doesn’t really matter. I mean, that had happened so many times that most people are aware of it by now.

    D) I bet they approve it. That would be much easier than asking them to deploy MSI packages with the exported policy setup.

  40. CoqBlog says:

    Vous êtes sans doute au courant qu’il existe au moins une grosse différence entre les executables natifs

  41. matt says:

    As the lead developer and the network admin, I say yes, we need this back. The security error has forced me to use clickonce, which I like. But you cant beat just replacing an exe on the network.  thanks

  42. Umfrage: Allowing .NET EXEs to run off a network share

  43. guruparan says:

    A) Yes

    B) All the Time!! (Winforms)!!..if asp.net website can run, why not a winform (anyway asp.net website is different from winform..) but web & desktop apps are miggling now a days!

    C) ASAP.

    D) ASAP.

  44. Guy kolbis says:

    A while ago I wrote this post: Sandboxed Applications Can’t Elevate Their Own Permissions that is related

  45. John Schroedl says:

    A) Yes

    B) Daily

    C) ASAP.

    D) ASAP.

  46. Wes says:

    A) Yes

    B) All the time

    C) Now

    D) Now

    FYI: One way I’ve been getting around this is by create a matching batch file that copies to the local temp directory and runs from there. Thats much easier than having someone change there security settings.

  47. deruss79@hotmail.com says:

    a) Yes

    b) internal tools, used often

    c) soon

    d) unaware yet, but will be more as more .net apps are adopted.

    Taking this opportunity to list some annoyances:

    – deployed msi – works but is not ideal as it clobbers the existing policies, which is undesirable in development environment

    – mixed mode C++ apps – even simplest app won’t load without an exception, so can’t even popup friendly message box to warn the user about lack of permission.

    – URL policy – seems to not perform DNS resolution properly for mapped network drives (?)

    – caspol.exe – creates mulitple entries with same name, rather than override existing entry

    – .Net config tool – no ‘refresh’ command; only available in SDK.

  48. Oidon says:

    A) Have you ever run into this limitation (a security exception when running a .NET application from a network file share)?

    Yes

    B) How often do you use network file shares for deploying applications (managed or otherwise)?

    Rarely

    C) If you think we should make this change, when would be a good time?  Is it something we should do sooner in a service pack of the .NET Framework or later in a full release of the framework.   Note, we are DONE with .NET Framework 3.5, so there is zero chance it is getting in that release.

    A service pack should only address bugs, not introduce new or different functionality. Thus, a full release.

    D) Can you ask your local network admin what they think of this issue?  Would they be in favor of this sort of change?  If so, when?

    I suppose that would be me. I am impartial: neither in favor nor opposed to it.

  49. MIke says:

    A. Yes

    B. All the time

    C. ASAP

    D. I tell THEM what to think.

    This should never have been in.

    What a pain to always add the .Net exe as allowed.

  50. a) All the friggin’ time.

    b) All the friggin’ time.

    c) As soon as possible.  HotFix, SP, premier download.

    d) I’m not the local admin, but I’m the architect and engineer for all of .net within the bank.  And I think it sucks.

    Background – I’m the .Net SME for a *very* large bank in the US.  We roll out a lot of our applications via a network share, and are continuously stymied from this issue.  It actually causes many of our businesses to prefer to *not* use .Net.

    It would be different if the security configs had a decent GPO implementation, but xml file configs via GPO is an all or nothing deal, which also sucks.

  51. Johnc says:

    A. Yes

    B. Never because of this issue but if we could I’d recommend it to thousands of our customers who would certainly embrace it wholeheartedly.

    C. ASAP in a service pack

    D. Silly question, of course most network admins would be in favour of this, it gives them more control and it’s patently obvious that it’s no more of security risk.  Why even have this poll, just do it already. πŸ™‚

  52. Wesley Davis says:

    The (already metioned) idea of "trusted servers" is something long overdue.

    The problems I’ve had have always been intranet related – something that is both known and necessary.

    The key is to make it easy on the IT shop – not just developers but sys admins and those doing the SMS end – to designate what is safe and what is not. That includes policy-level "same for everyone" and "no end user configuration action required."

    Ideally it should be even easier than the hassles of designating safe zones for Click-Once.

    Some of these .exe things are well below "click once" and merely immediate "fix" things (a workaround to some known problem of whatever variety) put out for internal use.

  53. Himanshu Shekhar says:

    Please, provide this feature ASAP πŸ™‚

  54. Patrick says:

    I’ve pretty often run into that issue.

    Creating software where only one .EXE in one place has to be replaced by a newer version is keeping upgrading and support quite simple. Most of my customers have one or more servers, and quite a lot of clients. If I had to update the software on all clients, it would take too much time.

    I would be glad, if you would change this as soon as possible. So a hotfix or something like that would be the best solution for me.

    I tried many workarounds, but as soon as the major version number of an .EXE or .DLL changed, I had to go through all the procedure of making the app trusted on all clients.

    I don’t think that this would be any security issue. Cause if someone wants to overcome this, he would just use managed code πŸ˜‰

  55. guido says:

    A. Yes

    B. All the time

    C. ASAP

    D. I tell THEM what to think.

    This should never have been in.

    What a pain to always add the .Net exe as allowed.

  56. mrpotatohead says:

    A) Yes

    B) I don’t but want to. it’d make a massive difference to deployment, support and maintenance.

    C) ASAP.

    D) They’d welcome it, our users wouldn’t have to update hundreds of clients, they’d just update a few network shares.

  57. richardm says:

    A) yes

    B) often

    c) now πŸ™‚

    D) Accept it no question…

  58. Scott says:

    A) yes

    B) all the time

    c) ASAP

    D) They would welcome it

  59. Kiran says:

    Eventhough I like the idea of allowing it. I rather not have it back and control deployment using clickonce or caspol. It has its benefits. But, clickonce could use some upgrades.

  60. steve bohlen says:

    a) Yes, since CAS is such a bear to configure on every wkstn that might need to run the app

    b) all the time (at least with 1.1-based apps); this limitation as enforced (and tightened up) under the 2.0 CLR has actually prevented us from migrating several winforms apps to from 1.1 to 2.0

    c) since 3.5 is baked, its really got to be done via an SP (since I don’t want to wait for fx 4.0)

    d) network admins consider that security happens at the NETWORK level, not the client OS level; ask most of the network admins I know about CAS and they have about zero idea what you’re talking about (this is a generalization based on my exp; please don’t flame this opinion!).  Network admins I know want to control access to apps on UNC shared via UNC share perms, not client OS CAS settings that have to be carefully constructed via complex GPOs or manually configured @ ea workstation

  61. Tim says:

    A) yes

    B) I cant any more because of this but all mine were!

    C) Today?  

    D) They dont see it as their issue

  62. twoelfer says:

    Brad,

    a) yes.

    b) almost every day. ("myDocuments" is on a share for backup purposes, thus every "test" project automatically gets cretated on a share.) (we also have a lot of utilities located on a share)

    c) as soon as possible

    d) i am the local network admin and i think the current implementation stinks.

    WM_THXASKING

    -thomas

  63. Chad says:

    Dittos with Tim.

  64. netsrac says:

    A) yes

    B) very often

    C) ASAP

    D) ASAP

  65. Bruce says:

    On every app written in .Net, currently the majority of the programs sent to customers is written in ‘unmanaged’ code with some managed code to help out.

    As soon as posible.

  66. Bob says:

    A) Yes

    B) Often

    C) As soon as you can

    D) Wouldn’t care because we already run many unmanaged exes off of network shares

  67. Ma says:

    A) Yes

    B) Not for deployement, but for testing sometimes

    C) ASAP

    D) n/a

  68. Pete Brown says:

    A. Yes, We re-wrote a VB6 application that was running its EXE off of a server into .NET.

    B. I now only use shares for updating installations.  We work around the issue by auto-installing new versions from the network.

    C. ASAP

    D. I don’t think they even know what .NET is.

  69. JoeW says:

    A) Yes, often

    B) By putting an enterprise policy change in place we trusted a specific deployment file share.

    C) Service Pack please.

    D) The local network administration saw the original policy enforcement as a good thing.  They want to be in a position of managing the desktop and removing the capability of running from a network location.   That said, I find myself to resorting to unmanaged code to write utilities that you don’t necessarily want a full blown deployment package for.  As you say in your post, as long as unmanaged code exists it doesn’t add to the overall security of the system.

  70. Marc Messer says:

    a.) Yes

    b.) Often

    c.) Service pack needed.

    d.) Our network admin likes the idea of him having to do less work every time we need a network path trusted in the GP.

  71. In the educational community or any space were we have public labs, it is important for a student or user to be able to log into anyone of the machines in the lab and have the appearance of a single consistent machine. A users documents are thus on a mounted file share so they have seamless access from any machine. As we started going to .NET this posed many problems, so Yes to A. Additionally, many of the users are developing programs but can not be considered experts (or even novices yet), so:

    A: Yes.

    B: Not really deployment, but student lab builds from Visual Studio

    C: By next Spring

    D: It would simply their life. We have other precautions to prevent a machine from getting corrupted.

  72. Matt says:

    A) Yes – when running code on our compute farm we are forced to add to our build full trust to this location.

    B) constantly

    C) service pack rather than wait for a release.

    D) not had a reply – likely they would like it

  73. Jared Saindon says:

    Why not spend the effort you would otherwise, spreading the word about how to have the Framework trust specific locations.  RTFM!!!  I don’t see how you can say that this change will not affect security.  I can now email links to my virus as I leave a large organization in a huff.

  74. Anthony Trudeau says:

    Frankly the more limited an executable is until I configure otherwise the better.  The only thing I’d ask is to make the configuration for developers and administrators easy.

  75. Clinton Pierce says:

    A) Yes, frequently

    B) We use almost nothing else.  Our user’s applications and their data all reside on the network, and are accessed as mapped drives or through UNC.

    C) It doesn’t matter particularly when from the dev standpoint.  When we deploy a new Citrix server, workstation, etc.. the infrastructure group is in the habit now of adjusting security on the "Intranet" zone to "Low".

    D) Yes, and probably sooner than later as far as they’re concerned.

  76. JD says:

    # Scott said on October 29, 2007 5:24 AM:

    A) yes

    B) all the time

    c) ASAP

    D) They would welcome it

  77. sgm says:

    a) Many times, especially when adding functionality to an old COM-based application deployed in a network share, using .NET

    b) Rather frequently

    c) Any time is good. Service Pack would be preferrable.

    d) As long as it only affects local network, they’d be ok with it.

  78. Bill says:

    A) Yes, this used to be our standard deployment method.  

    B) see A

    C) a service pack would be good, but enable the feature only when logged into a domain.

    D) our admins don’t care, but our Desktop team would really like it !

  79. Peter Ritchie says:

    How would using CreateProcess to differentiate directly execution by the user (e.g. double-clicking) have the ability to differentiate between automated execution and manual execution?

  80. Andrew Zonenberg says:

    A) No – all my code is unmanaged.

    B) I think I’ve done it once.

    C) I’d recommend it being put in a service pack, and providing an easy-to-use .CPL applet to allow changing it back to the default if requested. (New functionality has been put in SPs – SecurityCenter was deployed to XP in SP2)

    D)

  81. Dan says:

    A) Yes

    B) Not at all, we xcopy deploy local on demand

    C) Service Pack w/ Group Policy Change.

    D) IT boys don’t care. Less work for them the better. right now they would have to hit each box to adjust the .Net Pol.

    I would rather that the domain is trusted and workgroup is not by default.

  82. Marcus Ryan says:

    A) Yes

    B) Many of our apps are deployed this way.

    C) As much as I’d like to see it sooner than later and have it apply to all the frameworks, my desire for consistency overrides; I would say that changing security defaults to LESS restrictive should NOT be done with a service pack.  It should be a clear change in the next .NET version.

    D) No opinion; it hasn’t caused them much trouble either way.

  83. James Freeman, Sr Developer says:

    A) Yes

    B) Never in current position, but did often in last.  Especially impacts development of "utility" type apps designed to allow a few users to launch processes, as you don’t want to install such on local machine.  (Users may frequently change and so might the app.)

    C) For those who would be benefitted, it would probably be sooner rather than later.  Corporate America is probably not deploying the latest version of the Fx, however, (we are only on 2.0), but smaller, more nimble companies might be benefitted by an earlier release.

    D) We are too big.  Sorry I cannot provide feedback here…

  84. Joshua says:

    I would like to see the change made.  If it doesn’t really cause a problem with security then I see no reason to prevent it from running.

    If it’s a problem then we should be deploying locally anyway.  Thanks, and keep up the great works ya’ll!

    – Joshua

  85. Randy says:

    A) All the time.

    B) Would like to daily.  Instead we end up having every machine have it’s own copy of the .exe.

    C) ASAP.

    D) They could care less.

  86. MarcT says:

    I’d love this change. I use subst to map C:Projects to the P drive, and managed apps think it’s on the network, so I couldn’t run them until I finally figure it out and changed my settings. Very frustrating and weird in this case.

  87. Matt Varblow says:

    This sounds like a great change.  I like the idea of using the CreateProcess evidence for this.  I’d at least like to see it in a .NET 3.5 service pack.  (How soon can you ship one?)

    A) Yes

    B) Often

    C) ASAP

    D) They don’t care.  (They would if our workarounds affected them!)

  88. Paul Haggard says:

    A nice feature perhaps.. The easy way around this is to download assemblies from a web service or remoting and load via reflection.   I have a production application that uses this method to bootstrap applications through a generic client exe.

    Probably in trusted network environment this would work OK, but only if the environment is truly trustworthy.

  89. Jason Stern says:

    A) yes

    B) primary method of distribution

    C) not a huge priority as workarounds are in place

  90. The Janitor says:

    The REAL problem ist that the runtime’s error message here is of NO USE for any average user and it does not give ANY clue to the reason or even the solution. That’s a really shame!

  91. Robbie Price says:

    If one was really clever could one ask for permission to run the software the first time, and until permission to run is explicitly granted by the user.

  92. Steve says:

    A) Yes

    B) Often

    C) As soon as possible, and fix Framework 2.0 with the same change.

    D) Would work like non .NET exe’s, whats to ask?

    I think the answer is pretty clear already after a few days of open polls.

  93. Adar Wesley says:

    A. Yes

    B. Not often, but with XCopy deployment for .NET apps, this would be great.  You just dump everything in a folder on the local net and everyone can use the same installation.

    C. As soon as possible.

    In the enterprise environments I know, the network share is _MUCH_ more protected (and therefore secure) than the local computer.

  94. Brice says:

    A. Yes.

    B. During development, we frequently use file shares to share frequently-updated development versions of our non-managed software.  If we could deploy managed apps over file shares, we would look at the performance impact and consider giving our customers the option of installing to a file share.

    C. No opinion.

    D. Since this is no different than running a non-managed app over a file share – which we do all the time – the admins won’t care.

  95. Steve Cooper says:

    A.  Yes.

    B.  All of the programs we’ve written in-house are run from network shares except for the two .NET programs that are only used by a dozen or so employees (out of >10,000 employees).  If we could run .NET programs from network shares, all of our in-house programming would move to .NET.  As it is, we’re back to C++ and 3rd party products.  Management want’s .NET because of the increased ROI (development costs).  We just can’t do it because of the decreased ROI imposed by the LAN restrictions (LAN admin costs).

    C.  Make the change as soon as possible and include .NET 2.0 in the change.  Last week isn’t soon enough!

    D.  I asked our LAN admins and they got all excited, asking when it will happen.  Frowns all-around when I said MS was just asking about it.  They _HATE_ having to manage individual workstations.  With programs that run off shares, it’s mostly work for the devs (aside from a very small amount of LAN admin work at the end).  With workstation deployments, it’s a LAN admin headache every time a new program version is released and with the >100 in-house-built programs, new versions are a weekly occurence.  Security is not a concern — We run unmanaged code all day every day on every workstation and have had no problems.

  96. Dan F says:

    A. Yes, and its not immediately obvious what the problem is, which tends to confuse customers

    B. Quite often when deploying to customers. It’s not such an issue with apps with an installer, but for configuration utilities and the like it’s a PITA to have to tell the client to copy them locally.

    C. ASAP

    D. The admins here would like this change

  97. Steven Walsh says:

    I have several applications that we use in a lab environment, and this causes major issues for myself.

  98. We’ve had the problem, and decided it was good.

    We tell people to run a "security MSI" that sets the trust to full trust for apps signed by OUR key.

    Then network deployed .NET apps work, and joe Luser doesn’t go around being "helpful" dropping his latest C# express "tool" for others to use

    We’ve come to liking the way things are.

  99. Kevin Ryall says:

    A. Yes, we encounter this issue all the time – network shares are frequently used to deploy minor utilities.

    B. We use network shares frequently for unmanaged apps, and we have an unmanaged wrapper for managed apps just to work around this.

    C. As soon as possible, service pack probably

    D. Our admins don’t understand the difference between managed and unmanaged apps. If anything, they think we’ve done something wrong if our apps get a security warning where our older apps didn’t.

    In retrospect, this was a bad decision and it has caused us quite a bit of unnecessary work without improving security in the slightest – as the unmanaged wrapper we use now to deploy managed apps locally cannot be more secure that the managed app alone.

  100. Cheong says:

       I ran into problem in development (Out company policy require us to develop the projects on shared drive with volume shadow copy and regular backup, but that’s because the company use VB6 in the beginning. I managed to tell them allow me to develop in local). Perheps it’d be good idea if they allow the assembly run when the running account has debugging permission?

    Please at least allow us to run debug version in full trust across network drives.

       We usually deploy application on network drive for easier update, but because of that limitation, we figure it’d be easier for us to just "robocopy" the file to local location by login-scripts. Anyway in domain policy we give full trust to the scripts created by GPO, why don’t just make it a default policy to trust assemblies be run on \<domain controller>netlogon ?

  101. Ed says:

    I’ve encountered this many times.  Initially, you don’t know what the problem is.  It’s only after long searches do you find out the problem, and that there’s practically nothing you can do about it.

    A file share should be treated like a local drive.

    An .exe should act just like any other .exe.

    Otherwise, you are drawing arbritrary lines in the sand that users can’t understand.

    A. Yes

    B. Yes, would like to if the restrictions were removed

    C. Should be in a full release to make the change obvious.

    D. Our admins don’t understand the problem.  An .exe is an .exe.

  102. yum says:

    A) Yes, and we found it the hard way when deploying as finished app to the customer.  Seems like a stupid way to find this out (why the difference from an unmanaged exe, since it IS also an exe, for goodness sakes?).

    B) All the time, since this is also a tradeoff between richness and the pain that comes from PC deployments.

    C) May I suggest making this fix retroactive from, say. .Net 2.0 onwards.  From what you said, seems like you are thinking about post .Net 3.5.  Upgrading to .net 3.5 involves too many other considerations for large deployments.  I’d like MS to walk some miles in my shoes in these kinds of environments.

    D) An exe is an exe.  What’s the diff?  Why MS made a difference in this aspect is infuriating.

  103. a) yes

    b) Sometimes use network shares, both internal and for our customers

    c)soon (service pack)

    d) I’m not likely to ask IT for anything!!! It takes 6 months to get easy stuff done.

    We ran into this problem back in the days of Beta 1.0. The solution we used was to run an install that added a security codegroup to the machine policy level that used a strong name as the entry condition, set the codegroup’s permission grant to FullTrust, and the we signed our assemblies with that strong name. We’ve been doing this for over 5 years.

    This worked but it requires the user to run an install at administrator privelege level, and is a problem for xcopy deployment. It is rather limiting.

    Making the changes as suggested seems like a reasonable approach.  I don’t want an exe located on a file share (intranet zone) treated exactly the same as a local drive, however, it is reasonable to relax this as typically (in our case, anyway) file shares are just about as trustworthy as local drives (all are within the same firewall).

    I would NOT want full trust granted to executables loaded from an internet zone. This is a stronger level of guarantee then simply using the evidence of CreateProcess – I want the evidence of internet zone to override that.

    In other words, I don’t care how it is launched, if it is from the internet zone I don’t want it granted full trust.

  104. Ned Bush says:

    We ran into this just the other week trying to upgrade an application to .Net 2.0.

    I’d prefer that either the restriction was removed or at least it was easier to figure out what we needed to do to relax the security policy.

    If you don’t feel comfortable removing the restriction, maybe if the error we got when we tried to run a program off a share gave us directions or a URL on modifying the security policy (with notes on what we will need to do if we deploy this way so that users don’t have to muck with their settings individually)?

  105. Steve W says:

    a) Yes. We’ve built a .NET GUI app that had to run off the network by requirements (we had to implement a copy-local workaround). We also use our own .NET-based wrapper around the .NET compiler API’s instead of Visual Studio, and this means we effectively can’t double-click on the "compile it" makefile if it’s on a network drive … irritating.

    b) Never, now. If it worked, we would build apps once or twice a year that use this for deployment, but would use it every day for dev.

    c) The sooner the better, from my perspective. I would have been happy if this were fixed in .NET 3.5. I’m definitely less happy about waiting for the next release, which could be years out.

    d) Yes. I manage the appdev guys and the network policies, so the two departments’ policies are very much in line. πŸ™‚

  106. chris says:

    I work in an environ. where all interal apps are run off a network server.  I used the CasPol.exe to set the permissions on the folder that hosts all internal programs so it was only a one-time run.  I just had all users of the first .NEt coverted program run a custom setup that had the caspol directives included.

    Granted if you trust the share then you should trust anything on the share.  True, but if we are going to see more trust factors then let’s go to the .exe level.

    Just add caspol type work directly into the installers.  I had to search the net for a solution and then use a third party install script to do it.

  107. Chris Alcock says:

    This is a great idea – taking this limitation away relives one of my biggest anoyances with .NET EXEs.  See the linked post for more details

  108. Chris Alcock says:

    This is a great idea – taking this limitation away relives one of my biggest annoyances with .NET EXEs.  See the linked post for more details

  109. Nate says:

    A) Yes, often.

    B) Often for unmanaged apps, rarely for managed because it’s too painful.

    C) As soon as possible, in a service pack.

    D) IT department would definitely be in favour of a change asap, as they are the ones pulling their hair out trying to work around the issue.

    We are an ISV and ship products with some managed code.  Many of our customers want to install the product on a network share so we are constantly trying to explain the workarounds to them.

    We’ve never understood this limitation precisely for the reasons you mention, that any unmanaged app on that same network share will run, so why should a managed app be considered less secure?

    Nice to hear you’re rethinking this!

  110. Bill Grubbs says:

    A. Yes

    B. Fairly often

    C. Major release

    D. They are in favour of this change

  111. Brian Wildrick says:

    A) Yes

    B) About one-third time in major projects at a previous job

    C) Next major release would work

    D) He says he’s alright with it

  112. Mike Prince says:

    A. Yes

    B. Fairly often

    C. ASAP

    D. They are in favour of this change

  113. Charles says:

    A. Yes

    B. Fairly often

    C. ASAP

    D. They are in favour of this change

  114. Schabse says:

    A) Yes

    B) Daily

    C) ASAP

    D) That’s me

  115. Bruce says:

    A) Constantly.  As someone said, our My Docs is mapped to a network drive so I had to change all those mappings so I could develop.

    B) We are a new-to-.Net in-house applications, so we don’t have many yet.  I have developed at least one application as a Web app simply because of this limitation, as I would have preferred a forms app.

    C) I would like to see it immediately, retrofitted to ALL running .Net versions.

  116. A) Yes.

    B) Would use it more once the limitation is lifted.

    C) Soon – SP/Hotfix

    D) Many other exe’s run across the network, so why limit ot managed .NET only?

  117. Roy Pardee says:

    Wouldn’t the behavior you propose be equivalent to assigning fulltrust to code coming from the local intranet zone?  

    For sites where that’s a tolerable solution, it’s easy enough to accomplish via group policy and/or .msi-borne CAS policy tweaks I think.

    My vote would be to not make this change.

  118. Bruce Cowan says:

    A) very frequently.

    B) very often, this limitation causes problems of course

    C) Now, SP/Hotfix

  119. Ethan Nagel says:

    A) Yes.

    B) When it’s needed, it’s really needed.

    C) ASAP – SP/Hotfix (for 2.0+)

    We hit this issue on a major project and it was seen by my customer as a limitation of .NET, not a security feature and I had to agree.   We ended up creating a batch file to solve the problem… how embarassing!

  120. codelinezero says:

    a) yes

    b) about once a week

    c) never. I can live with this limitation

  121. JohnGalt says:

    running software from a network path = bad software design.

    Developers, sure go ahead let them do it. But no one else needs to do so. Deploy using click once or any other archtecture you wish, but deploy your app. Applications go on computers, data goes on servers. Very simple concept that has stood the test of time (even asp.net works this way)

  122. richardt says:

    No. Please no.

    The only way I can accept EXE’s on network shares to be executed is if it is signed by a trusted cert. This should be an opt-in only feature and which a network admin has to explicitly configure.

    More thoughts here: http://www.bitcrazed.com/2007/11/01/RunningNETEXEsFromNetworkSharesByDefaultJustSayNo.aspx

  123. a) Yes

    b) Would do a lot more often if it wasn’t for this limitation

    c) ASAP – but, important to have a way of verifying that a client has this capability

    d) I am the Sysadmin (see above)

    I would really like to develop on a network drive (to get the advantage of regular server-based shadow copies, backups etc), but it’s a real pain having to repoint the bin directory for every project because of this limitation.

  124. Paul Ehmig says:

    A) Often

    B) Quite a few times. I use clickonce, because of avoiding the hassle of caspol.exe with its poor documented examples.

    C) In a service pack. I prefer that you keep it like it is now but improve caspol.exe and add really good examples and a tutorial.

    D) Changing existing applications is very improbable.

  125. GPCottle says:

    A) Yes

    B) Always

    C) Service Pack for all versions of the Framework

    D) No problem.

    That said, my employer requires all .NET applications be string name signed and applies a policy for that. With that in place, it is possible to run from a network drive. Only problem, is that with that policy in place, I cannot develop ASP.NET 2.0 applications. 1.* is fine, but I cannot get the policy to work for 2.0

  126. Russ C. says:

    A) Indeed!

    B) A lot more if we could

    C) A Service pack sounds good.

    D) My sysadmin would find it makes his life easier as one of our development tools could be shared between the entire team from one place and everyone would get the latest updates.

  127. David Walker says:

    A) Yes!!!!!

    B) Often!

    C) In a service pack

    D) I am the sysadmin, and this would help TREMENDOUSLY.

  128. David Walker says:

    I’m not entirely sure why network shares are less trusted than the local computer.

    Our network shares reside on our SERVER, after all.  

    If the disks on the server have been compromised, and somehow, a non-authenticated user has written over EXEs or DLLs on our MAIN SERVER, then we have a huge problem.

    Or if an authenticated user somehow was able to write to our local code deployment locations, then something has gone horribly wrong.

    (For apps deployed locally, a virus could drop a replacement rogue app more easily on the LOCAL computer than on our SERVER, where the users don’t have write permission to the code-source-paths.)

    Please explain to me why network shares should be considered less trusted than the local computer?  It’s easier to muck up the local computer than it is to muck up the SERVER.

    David Walker

    If an authorized user is doing the

  129. Jonas Andersson says:

    A) We frequently run into this problem. Out installation program runs a .Net program to migrate version data after installation which means that we now cannot install to a share (VB6 versions had no problem).

    B) Very often!

    C) Put it in a service pack.

    D) Our Network admin doesnt care, but our customers would like to run from a network share.

  130. A. Yes I have.

    B. We don’t use shares due to the security issues.

    C. The next service pack for all .NET framework versions.

    D. Loves the proposed change.

  131. A) Yes, often

    B) Often except for managed ones because of this problem

    C) Sooner in a service pack

    D) Local network admin’s would love it ASAP.

  132. A) yes, often. Normally during development.

    B) all the time, but for now we’ve had to manually add a new "full trust" key to machine policy

    C) as soon as possible

    D) this doesn’t change security, so admins should have no problem with it.

  133. Nitin Badole says:

    I think EXE, whether run from local drive or any network share, always run in the security context of logged in user. So there should not be difference in behaviour of the application when it’s run from a non-local drive.

    This is unnecessary security checking in .NET as anyone can copy the EXE locally and work with it. It should be corrected in the next major release.

  134. Robert McNeill says:

    All our company customer applications are run off the network.  Since the configuration is now a separate tool, we now have to install both the runtime and the configuration tool and then configure it for each new or rebuilt PC. Way too much work.

  135. Miral says:

    A) Every day.  (Well, not the exception, but running apps from network drives.)

    B) Frequently.

    C) As soon as you can.  Retrospectively, too (service packs for older frameworks).

    D) They’re fine with it.

    .NET 1.1 wasn’t too bad since the CAS security app came with the runtime.  It’s been more painful in 2.0 since that’s no longer the case.

    Maybe another option you could do would be to prompt the user when running a new app from a partial-trust location (similar to what the shell already does in XPSP2), but having options to run with partial or full trust and to remember the setting — and bring back the security control panel so this can be adjusted as needed.

  136. Petteri Kaila says:

    A) Yes.

    B) All the time.

    C) ASAP. Service Pack to at least 2.0 and above.

    D) ASAP.

  137. Jouni Junttila says:

    A) Yes, the last time was 30 minutes ago.

    B) Always – that’s how we do our deployment

    C) ASAP! Would be nice to get it to .NET Framework 2.0, but seems that it will not get done?

    D) They would want it done – NOW.

  138. Krister says:

    A) All the time

    B) Yes

    C) Yesterday

    D) ASAP

  139. A .Net Dev Bod says:

    a) Yes lots of times

    b) Majority of the time

    c) Without meaning to go against the grain of many of the posts in this thread.. Don’t bother.

    In my environments we simply get around the problem by utilising a DFS referral and set policies for just 1 location for all our assemblies. (Or use ClickOnce in .NET 2.0).

    I don’t think that the security of managed code should be compromised in this manner IMO it kind of defeats the some of the purpose .NET.

    I think the approach should be to make the management of .NET Security policies easier/more dynamic via GPO for example or a management server. Enhancements to CASPOL would be useful so that you could append/validate security settings without blanket overwriting the settings that there may be in Security.Config.

    d) I am both a developer and a sysadmin and to ensure my network/application integrity, I wouldn’t want to implement this change.

  140. Developer/admin says:

    a) Yes, lots of times

    b) Our not managed applications are deployed on the network share, for the managed app we have to work out new deployment schema – currently it generates huge amounts of additional work when installing end upgrading apps on every enduser computer.

    c) Yesterday!

    d) ASAP! Local network should not be treated as unknown location!

  141. Amy Freelander says:

    Change it asap it’s extremely annoying!

  142. Brent Flesner brent.flesner@illinois.gov says:

    Running .Net Apps from a server share would save us a ton of work.  We have written a custom block updater service which connects to a DFS UNC path to update .net applications installed locally on 6000 computers.  We use SMS to deply initial release and manifest and then we use the update block service to update them afterwards.  

  143. Abel says:

    I might be mistaken, but this might also relate to a security issue that occurs when an ASP .NET website(pre-compiled) that has its virtual directory pointing to a UNC Path. This is fine if you are working on your local machine as  you can customize the security setting (by setting full trust). However if you are using a shared hosting these kind of customizations are most likely impossible.

    I think this would help out a lot for most shared hosting providers and their users.

  144. peterchen says:

    Yes please!

    A) YES!  B) Frequently for lots of inhouse tools

    C) ASAP please – as a patch with a configurable option somewhere? Or simply as a patch that throws the switch?

    D) He agrees with me. (it’s me myself, but that’s beside the point). Security-Wise, the low trust does nothing. Every more "agile" user will try to copy the files lokally and skip any warnings.

    Cranking out fun little .NET utilities to make everyone’s life easier is fun. getting them run from a network drive is not.

    It is currently a real problem for moving some parts of the develop environment to a shared location (where they belong), since custom .NET build utilities are involved.

  145. Vic D'Elfant says:

    A) Yes I have, unfortunately.

    B) The organisation I’m working for runs all unmanaged software off a central "Apps" network drive. My .NET application is – as far as I know – the first managed application to be introduced to their systems (and it certainly won’t be the last) so this restriction is going to cause severe problems when it comes to application deployment and maintenance.

    This not specific for this organisation, but it leaves a bad impression about your application if end-users get security exceptions and you have to explain to them that this is more or less intended behavior and that they’ll have to jump through hoops to get it fixed. This would be something I could live with if there were to be an easy way of changing this behavior, but there currently isn’t.

    C) The obvious answer: yesterday. In order of preference: an easy to redistribute (i.e. one with a /silent mode) hotfix, the next service pack, the next full release.

    D) Yes, they would be, and as soon as possible. This issue is probably going to require yet another policy change which has to be mirrored to the workstations and/or a change to the workstations’ image, meaning yet more time which has to be invested and more annoyances.

  146. Tim Sneath says:

    Today I’m excited to announce the public beta availability of a major new release of WPF. Since we shipped

  147. Tim Sneath says:

    Today I’m excited to announce the public beta availability of a major new release of WPF. Since we shipped

  148. VS2008 and .NET Framework 3.5 offer a ton of customer value from Linq to Ajax and much more.&#160; The

  149. CoqBlog says:

    Ceux qui ont lu mon post concernant l’execution d’application .NET depuis un partage réseau et l’appel

  150. Today I&#39;m excited to announce the public beta availability of a major new release of WPF. Since we

  151. Hurray, its finally fixed! manage code ‘just works’ from network file share! Now I know that some of

  152. This has got to be one of the most consistently asked for &quot;features&quot; of .NET from the start!&#160;&#160;&#160;&#160;

  153. &#160;&#160; With the release of the new Service Pack 1 for the .NET Framework 3.5 several changes were

  154. &#160;&#160; With the release of the new Service Pack 1 for the .NET Framework 3.5 several changes were

  155. γ€εŽŸζ–‡εœ°ε€γ€‘ .NET Framework 3.5 SP1 Allows managed code to be launched from a network share! γ€εŽŸζ–‡ε‘θ‘¨ζ—₯ζœŸγ€‘ 13 August