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. 
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
Anonymous
October 26, 2007
I ran into the problem during development. (Developing from a network share) It was only a minor inconvenience.Anonymous
October 26, 2007
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.Anonymous
October 26, 2007
By default .NET applications (EXEs) that are launched from a remote file system (eg \serverbinSomeAppAnonymous
October 26, 2007
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.Anonymous
October 26, 2007
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.Anonymous
October 26, 2007
The comment has been removedAnonymous
October 26, 2007
The comment has been removedAnonymous
October 26, 2007
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.Anonymous
October 26, 2007
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.Anonymous
October 27, 2007
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.Anonymous
October 27, 2007
A) Often. B) I don't because of the current limitation; I would like to. C) Service pack ASAP.Anonymous
October 27, 2007
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.Anonymous
October 27, 2007
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.Anonymous
October 27, 2007
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.Anonymous
October 27, 2007
A. Yes B. Fairly often C. Major release D. They are in favour of this changeAnonymous
October 27, 2007
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 networkAnonymous
October 27, 2007
Please let those managed apps run form the network share. This has been a pain at the office. We just use click once instead.Anonymous
October 27, 2007
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.)Anonymous
October 27, 2007
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 careAnonymous
October 27, 2007
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!Anonymous
October 27, 2007
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)Anonymous
October 27, 2007
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.)Anonymous
October 27, 2007
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.Anonymous
October 27, 2007
You've been kicked (a good thing) - Trackback from DotNetKicks.comAnonymous
October 27, 2007
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??Anonymous
October 27, 2007
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.Anonymous
October 27, 2007
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.Anonymous
October 27, 2007
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.Anonymous
October 27, 2007
The comment has been removedAnonymous
October 27, 2007
A) Yes B) Often C) The sooner the better D) Not an issue - it's a hassle for them as well.Anonymous
October 27, 2007
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.Anonymous
October 27, 2007
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.Anonymous
October 27, 2007
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.Anonymous
October 27, 2007
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'sAnonymous
October 27, 2007
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.Anonymous
October 27, 2007
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 ?Anonymous
October 27, 2007
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.Anonymous
October 28, 2007
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).Anonymous
October 28, 2007
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.Anonymous
October 28, 2007
Vous êtes sans doute au courant qu'il existe au moins une grosse différence entre les executables natifsAnonymous
October 28, 2007
The comment has been removedAnonymous
October 28, 2007
Umfrage: Allowing .NET EXEs to run off a network shareAnonymous
October 28, 2007
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.Anonymous
October 28, 2007
A while ago I wrote this post: Sandboxed Applications Can’t Elevate Their Own Permissions that is relatedAnonymous
October 28, 2007
A) Yes B) Daily C) ASAP. D) ASAP.Anonymous
October 28, 2007
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.Anonymous
October 28, 2007
The comment has been removedAnonymous
October 28, 2007
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.Anonymous
October 28, 2007
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.Anonymous
October 28, 2007
The comment has been removedAnonymous
October 28, 2007
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. :)Anonymous
October 28, 2007
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.Anonymous
October 28, 2007
Please, provide this feature ASAP :-)Anonymous
October 28, 2007
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 ;-)Anonymous
October 28, 2007
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.Anonymous
October 28, 2007
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.Anonymous
October 28, 2007
A) yes B) often c) now :) D) Accept it no question...Anonymous
October 28, 2007
A) yes B) all the time c) ASAP D) They would welcome itAnonymous
October 28, 2007
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.Anonymous
October 28, 2007
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 workstationAnonymous
October 28, 2007
The comment has been removedAnonymous
October 28, 2007
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 -thomasAnonymous
October 28, 2007
Dittos with Tim.Anonymous
October 28, 2007
A) yes B) very often C) ASAP D) ASAPAnonymous
October 29, 2007
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.Anonymous
October 29, 2007
A) Yes B) Often C) As soon as you can D) Wouldn't care because we already run many unmanaged exes off of network sharesAnonymous
October 29, 2007
A) Yes B) Not for deployement, but for testing sometimes C) ASAP D) n/aAnonymous
October 29, 2007
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.Anonymous
October 29, 2007
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.Anonymous
October 29, 2007
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.Anonymous
October 29, 2007
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.Anonymous
October 29, 2007
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 itAnonymous
October 29, 2007
The comment has been removedAnonymous
October 29, 2007
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.Anonymous
October 29, 2007
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.Anonymous
October 29, 2007
Scott said on October 29, 2007 5:24 AM:
A) yes B) all the time c) ASAP D) They would welcome it
Anonymous
October 29, 2007
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.Anonymous
October 29, 2007
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 !Anonymous
October 29, 2007
The comment has been removedAnonymous
October 29, 2007
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)Anonymous
October 29, 2007
The comment has been removedAnonymous
October 29, 2007
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.Anonymous
October 29, 2007
The comment has been removedAnonymous
October 29, 2007
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
Anonymous
October 29, 2007
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.Anonymous
October 29, 2007
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.Anonymous
October 29, 2007
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!)Anonymous
October 29, 2007
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.Anonymous
October 29, 2007
A) yes B) primary method of distribution C) not a huge priority as workarounds are in placeAnonymous
October 29, 2007
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!Anonymous
October 29, 2007
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.Anonymous
October 29, 2007
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.Anonymous
October 29, 2007
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.Anonymous
October 29, 2007
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.Anonymous
October 29, 2007
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.Anonymous
October 29, 2007
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 changeAnonymous
October 29, 2007
I have several applications that we use in a lab environment, and this causes major issues for myself.Anonymous
October 29, 2007
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.Anonymous
October 29, 2007
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.Anonymous
October 29, 2007
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 ?Anonymous
October 29, 2007
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.Anonymous
October 29, 2007
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.Anonymous
October 30, 2007
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.Anonymous
October 30, 2007
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)?Anonymous
October 30, 2007
The comment has been removedAnonymous
October 30, 2007
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.Anonymous
October 30, 2007
This is a great idea - taking this limitation away relives one of my biggest anoyances with .NET EXEs. See the linked post for more detailsAnonymous
October 30, 2007
This is a great idea - taking this limitation away relives one of my biggest annoyances with .NET EXEs. See the linked post for more detailsAnonymous
October 30, 2007
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!Anonymous
October 30, 2007
A. Yes B. Fairly often C. Major release D. They are in favour of this changeAnonymous
October 30, 2007
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 itAnonymous
October 30, 2007
A. Yes B. Fairly often C. ASAP D. They are in favour of this changeAnonymous
October 30, 2007
A. Yes B. Fairly often C. ASAP D. They are in favour of this changeAnonymous
October 30, 2007
A) Yes B) Daily C) ASAP D) That's meAnonymous
October 30, 2007
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.Anonymous
October 31, 2007
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?Anonymous
October 31, 2007
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.Anonymous
October 31, 2007
A) very frequently. B) very often, this limitation causes problems of course C) Now, SP/HotfixAnonymous
October 31, 2007
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!Anonymous
October 31, 2007
a) yes b) about once a week c) never. I can live with this limitationAnonymous
November 01, 2007
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)Anonymous
November 01, 2007
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.aspxAnonymous
November 02, 2007
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.Anonymous
November 03, 2007
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.Anonymous
November 04, 2007
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.0Anonymous
November 06, 2007
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.Anonymous
November 07, 2007
A) Yes!!!!! B) Often! C) In a service pack D) I am the sysadmin, and this would help TREMENDOUSLY.Anonymous
November 07, 2007
The comment has been removedAnonymous
November 07, 2007
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.Anonymous
November 09, 2007
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.Anonymous
November 10, 2007
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.Anonymous
November 12, 2007
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.Anonymous
November 15, 2007
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.Anonymous
November 16, 2007
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.Anonymous
November 18, 2007
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.Anonymous
November 19, 2007
A) Yes. B) All the time. C) ASAP. Service Pack to at least 2.0 and above. D) ASAP.Anonymous
November 20, 2007
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.Anonymous
November 20, 2007
A) All the time B) Yes C) Yesterday D) ASAPAnonymous
November 28, 2007
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.Anonymous
November 28, 2007
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!Anonymous
December 11, 2007
Change it asap it's extremely annoying!Anonymous
December 21, 2007
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.Anonymous
December 21, 2007
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.Anonymous
December 30, 2007
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.Anonymous
January 22, 2008
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.Anonymous
May 12, 2008
Today I'm excited to announce the public beta availability of a major new release of WPF. Since we shippedAnonymous
May 12, 2008
Today I'm excited to announce the public beta availability of a major new release of WPF. Since we shippedAnonymous
May 12, 2008
VS2008 and .NET Framework 3.5 offer a ton of customer value from Linq to Ajax and much more.  TheAnonymous
May 12, 2008
Ceux qui ont lu mon post concernant l'execution d'application .NET depuis un partage réseau et l'appelAnonymous
May 12, 2008
Today I'm excited to announce the public beta availability of a major new release of WPF. Since weAnonymous
August 13, 2008
Hurray, its finally fixed! manage code 'just works' from network file share! Now I know that some ofAnonymous
August 13, 2008
This has got to be one of the most consistently asked for "features" of .NET from the start!    Anonymous
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 August