views:

482

answers:

3

This may be a silly question for some of you, but what are Pros/Cons of running a Windows Forms .Net application from a shared drive. Up until recently I didn't even know this was possible. From research it looks like .Net 3 SP1 allows this behavior (without requiring any security changes).

I am curious as to any concurrency issues or scalability.

Also, I am assuming .Net is still required on each client that will run the app from the shared drive. Any help is appreciated.

+2  A: 

You need to have the correct .Net version installed on each client but there is no reason why you shouldn't be able to run from a shared drive, we do that here and at clients without a problem as long as the user has access to the share.

Otávio Décio
+4  A: 

We have a number of console programs written in .Net that do nightly batch processing. These programs "live" on a SAN accessed via mapped drive. Since we're still on .Net 2.0 the processing server had to be specially configured to allow these programs to run, and of course the processing server needs the framework installed, but otherwise it works great. .Net3.5sp1 would even fix the special configuration.

Now, this scenario is probably different from what you're thinking about. If you want to deploy an application to a shared folder so that a lot of different users can access it, this is a bad idea. If you write to any data files in the same folder as the app (a bad idea anyway, but people do it all the time) then those files are shared (and locked) by all users. Also, any user currently running the program causes the file system to place a lock on the program file, potentially locking you out of deploying updates. If you want to do this, .Net provides an excellent system called ClickOnce to support deploying apps to network shares.

Joel Coehoorn
+1  A: 

Concurrency and scaling is not an issue but in the most extreme circumstances. You are just using the network share as a drive to supply the assemblies. The app still runs on the work station, consuming operating system resources and CPU cycles from that machine only. Unlike a ASP.NET app.

If the app itself uses some kind of shared resource, not untypically a dbase server, concurrency and scaling definitely play a role. But that will be the case whether or not the app runs from a network share.

One consideration: deploying an update can be tough. You'll have to get all users to exit the app so there's no lock left on any assemblies. Building that into the app would be wise. Something as simple as a FileSystemWatcher looking for a specific file name will get the job done.

Hans Passant