Application deployment to network drive

2019-04-12 06:27发布

问题:

I have a .NET 4 WPF application that needs to run inside a company network.
The application does not use local files (it does have an app.config file but it only contains some connection strings) for data storage but a central SQL server database. What are the downsides of putting the application files on a shared network drive and just creating a shortcut to the application executable for each user?
I've found some data on the subject in the following links but I couldn't get a clear answer:
Run a .NET program from a mapped drive or shared folder - Pros/Cons
Run a .NET program from a mapped drive or shared folder
http://support.microsoft.com/kb/832742
It would also be nice to know how stuff works when using this approach, are the application files being copied to the local user or something else happens?

回答1:

My question for you is why would you want to? Why not just publish the .NET application using click once to the network share?

When you run the application from the network share, a copy of the program is loaded into memory on the client machine, and requests for supporting files will transverse the network as well, to be loaded into memory. On top of this, you have to check for any prerequisites, and may experience some failures.

If you publish to the network share, when you complete the publish wizard, your browser will open up to a webpage that resides on the network share. Just share the URL to this and users will be able to 'install' the program on their machine. Best part about this way is updates are automatic and you don't have to worry about interrupting users workflow when publishing updates.

ClickOnce applications do not require admin permissions to install, and will install its own shortcuts for the users. I have built and deployed several of these, and most users are comfortable enough with the install process to access it through a link from an email.

EDIT

You can also distribute a shortcut to the .application file once you deploy, as long as you are confident users have the pre-reqs installed. This will launch the application if it was installed, or install and then launch.



回答2:

I've done this with an application we run internally.

Depending on settings, .NET may simply refuse to load or execute an assembly from a network drive because of the potential for that executable to be a security risk. So your program might not run or might throw an exception when it tries to use a DLL.

Another downside to simply having a shortcut to an executable on the network will be when you go to deploy an update. Those files will very likely become locked, and you'll either have to go to every computer and make sure the software is shut down, or remove the user's lock on the server which might be painful. I found a bug in my program pretty quickly after deploying the first time, and found this problem right off the bat. Avoid it.

I have all of the files needed to run the program in a well-known location on the network (configurable). When a new user needs the application, I simply copy everything over to someplace on their computer and make a shortcut on the desktop (or start menu, possibly Startup folder) for them to use. The program then automatically looks at some metadata (version information) in that directory from time to time, and if it's newer, automatically updates itself.

This requires a separate executable for updating in addition to the application executable to avoid performing shadow copies and rebooting. The following basic things happen in my application:

  1. The application determines if a newer version is out on the network drive.
  2. If so, it updates the updater executable, then launches the updater with the process ID of the application as a command-line parameter, then terminates itself.
  3. The updater waits for the process it was passed to die before proceeding (so the application executable is not locked).
  4. The updater updates the application files.
  5. The updater then re-launches the application.

I haven't run into any problems with this scheme yet.