What are the problems with deploying an .EXE to a network drive and having users execute the .EXE over the network?
The advantage is that upgrades only need to be made to the one location. What are the disadvantages?
views:
220answers:
12
A:
The main disadvantage would be the network drive being unavailable.
Then each language, which you didn't specify, the EXE is written in matters. As .NET has some security issues running from a network drive.
Clarence Klopfstein
2010-08-23 02:21:53
I'm aware of the security issues with .NET. Anything else?
Craig Johnston
2010-08-23 02:41:40
No. Nothing else comes to mind.
Clarence Klopfstein
2010-08-25 14:05:47
A:
It depends on what the application does. My application would be a problematic over-the-network deployment because the configuration files it uses are all in the same folder as the EXE, or in a subfolder. If every user runs off of the network, they could potentially modify the configuration files and screw things up for everyone else.
Thankfully, my app is only going to be deployed on separate workstations. :)
Dave
2010-09-07 05:08:03
+1
A:
One problem is file locking. In a Windows environment, if a user executes the application directly from a network share, the application's files are locked. This prevents the application from being updated with a newer version if someone has left the application open.
You can go around this by disabling the network share before updating the app and then again enabling it.
Mikael Koskinen
2010-09-07 05:13:23
You can also rename the exe. It won't kill the connections but will let you put a new file out there. Users will get the new file the next time it is loaded. I've done this when a minor update is needed and having users run two different versions for a short time wont break anything critical.
bugtussle
2010-09-10 18:13:21
A:
They might not have all the files your app needs installed. If they don't, you'll need to create a setup. If they do and it works and everyone's drives are mapped correctly, you should be fine.
Beth
2010-09-07 16:55:05
+1
A:
For our program we decided against a shared exe. We thought it would be harder to support (IT needs to kill users to unlock files before updates, users wont know where the exe is on the network, share\network file permissions need to be modified by IT, etc) and that we should emulate the behavior of other programs when possible (client software is normally installed on the clients).
bugtussle
2010-09-07 19:40:22
A:
If you write your application using an Object Capability Security model, as defined in Mark S. Miller's Ph.D. thesis, Robust Composition: Towards a Unified Approach to Access Control and Concurrency Control, then you will not have any security drawbacks.
On the other hand, the "disadvantage" is that you must now manage access control via the object graph. The application should only have access to whatever permissions you give it. As some have already mentioned, Windows has a basic protection policy which locks the application files and thus prevents anyone from modifying the EXE until the application instance(s) is closed.
Really, the key issue here is you have to ask yourself what authority the program and its component parts should have. If it requires local user permission, then you will either have to design around that or give the program permission.
Understanding the implications of this, and doing it well, is not an easy task.
That's kind of rude. I gave a technically valid answer - NOT every answer has to be an instantaneous KLUDGE fix for a problem. If you want to use another approach with undecidable security properties, go right ahead. Here is a different way to learn the subject: http://www.object-oriented-security.org/
2010-09-10 20:01:33
A:
IMHO this is a really bad design decision. We have a third party application in our company which is designed exactly like this.
In order for the program to run properly it requires full sharing for that folder; In this case the worst part was that the program had the freaking DATABASE in the same shared folder (yeah, I was shocked too when I found out)!!! Didn't take too long till someone wiped every file that was not in use from that folder, including the database of course :)
I really recommend a client-server approach, even if you have to buy/build a smart installer with auto-update features to overcome deployment issues.
Bogdan
2010-09-07 20:11:55
Full sharing is not needed to run an exe off of a network drive in the Windows environment. Even if the exe needs to write data to the directory it is in, only Read / Execute permissions are needed to run the exe. Poor database / file access design isn't a reason to blame the method all together, but possibly a reason to consider other options to limit possible application design or deployment mistakes.
userx
2010-09-11 08:31:00
Bogdan
2010-09-11 10:47:57
Just because the executable is read-only doesn't mean that the executable can't write to other directories. Most programs actually deploy themselves to Program Files which for non-administrators actually is a read-only location of a computer. Temp files, saved documents, etc. are all saved in your user My Documents folder, Desktop, Application Data (AppData) folder, etc. where a user DOES have full (or at least write permission). As such, deleting your My Documents folder doesn't delete anyone elses! If you have a specific question, this is stackoverflow after all, post a new question :)
userx
2010-09-11 17:18:57
+4
A:
The EXE is one thing, but you also need to consider any DLLs and other shared resources that may be associated with the app.
Some DLLs may be shipped with the EXE - you'd have to put those on the remote drive with the EXE, which would cause additional network traffic if it needed to use them.
Other DLLs may be part of Windows, but there could be versioning issues here if your workstations have different versions of windows or even different service packs or patches but they're all running a common version of the app.
And what about licensing? Does the app's license actually allow you to install it on a network drive - many software companies are very specific about this sort of thing, so you need to really be careful if you don't want to get caught out.
In short, it sounds like a good idea to get a quick win for your deployment management, but it probably causes far more issues than it solves.
If you really want to go down this path, you maybe should consider alternatives like remote desktop (eg Citrix or Terminal Server) or something like that - there are much better ways of achieving your goals than just sticking everything on a network drive.
Spudley
2010-09-08 12:23:48
+3
A:
I would instead consider creating an MSI ( http://en.wikipedia.org/wiki/Windows_Installer ) file for your application and a Group Policy to facilitate distribution throughout your company ( http://support.microsoft.com/kb/816102 ).
There are a number of freeware MSI tools, a good ones that come to mind are http://www.advancedinstaller.com/ and http://wix.codeplex.com/
userx
2010-09-11 08:36:51
A:
I run a vendor's app like this at work. They didn't design for it, but it works without an issue. I have all the shortucts pointing to the UNC path. This particular app doesn't use files in the exe directory, so file locking isn't an issue. Its also hooked up to SQL Server for the data, so the data store isn't an issue either. (Would be a major problem if the app used a local SQLite, Access, or some other file based DB.)
If your app is a .Net app, this WILL NOT work without some major modifications to each machine's security settings, which is probably bad idea anyway. If you're talking about a .Net app, you should use ClickOnce. I use it for a few apps at work, as well, and it's great, and easy to use.
The problem is there isn't a definitive answer to your question, just a bunch of "it depends" qualifications. The big issues, AFAIK, are using local files for data storage, be they text files or databases. It is awesome for updates, though, which is why the app mentioned above is run like this.
Tim Coker
2010-09-12 16:24:05
A:
This is perfectly doable. Be sure to set the "Run from CD-ROM" (I think?) flag in the Visual Studio settings when compiling -- this prevents the image from being backed directly by the binary, so you can upgrade it while people are running it. I am not running Windows at the moment, so I can't check, but you may be able to set this flag for DLLs, too.
One problem with doing this is that if your program associates itself with files, when the network changes and computers are renamed everybody's PC starts to run like a dog. Explorer has a tendency to query these things at funny times.
Another more serious problem is that if somebody accidentally deploys a broken version, it's not just the early adopters who get stuffed!
For an easy life, personally I recommend XCOPY deployment...
brone
2010-09-12 21:46:36
A:
For .NET applications, we have observed BadImageFormatException which we have come to believe is from network glitches (or computers loosing network connectivity at key moments, for example using WIFI) while reading the EXE or DLL files.
Ross Bradbury
2010-09-12 23:56:45