We're in the process of writing a new Windows Forms app and the desktop
support folks want for it to be run from a network share. I know it's
possible (i.e., just have the framework on the clients and a desktop
shortcut to the exe out on the network)... but is it really a good idea?

What are some arguments for and against running a .NET Windows Forms client
from a network share? Here is my initial list... I'd appreciate any
additions, corrections, perspective, or opinions:

FOR (running app from network share):
--- smaller footprint on the client (only need a shortcut); no need to have
an application folder.
--- easy deployment - just update the copy on the share (of course this
point is mitigated by ClickOnce or similar home grown updator logic)

AGAINST (running app from network share):
--- slower initial application startup time (as the exe and all supporting
..dll files must travel across the wire to the client before everything can
get started)
--- fewer .config options because App.config won't be there (i.e., won't be
able to make use of Trace Switches on a client-by-client basis, etc).
--- fewer options for logging information locally [in an expected location,
at least] because there will be no application folder in which to write
various local log files.
--- cannot make use of the GAC on clients, and therefore cannot share
components (.NET dlls) amongst apps on the client.

Any additional important points?

Thanks!

[quoted text, click to view]

I have a "home grown" updater assembly. It creates an XML file based on the
files contained in the distribution folder and then performs a comparison
and transfers new files to the local drive. Occasionally issues arise where
files are locked or are in some inconsistent state (transferred over a WAN
and are corrupted) and the user needs to delete their local folder. Perhaps
you can have similar issues with Click Once? Personally I felt I was playing
with potential installation / deployment problems with Click Once and it
seemed like overkill but others hopefully will share their experiences.
Also, figuring out how to obfuscate the assemblies as part of the Click Once
procedure seemed to require some investment of time that I was not willing
to make at the time.

If the application creates files that need to be accessible in a common
place then you can use the path of the executable as a reference point to
the network. This can also be a bad thing if there are folders that could be
accessed by other users to see sensitive information. (As a side note if you
start an "updater" executable from the network that then spawns the locally
based executable you can get to both the network location and the local
folder location programatically).

You can tell if users are using the software quite easily by using file lock
information. This can be handy in some cases.

You can easily take the application offline with an entry in the app.config
that prevents users from starting and remaining in the software.

[quoted text, click to view]

If it is a WAN based application then the startup time can be totally
unacceptable.

Users can remain in the software and prevent updates so you need to have a
mechanism to deal with this.

Security needs to be adjusted for the "Local Intranet" zone to execute off
the server (although a home grown updater would also require this as it
would be on the network as well).

I have software deployed both ways and even customers that use it both ways
(LAN from network, WAN from updater). I would say network for small user
base and local deployment for large user base. Just be sure that your
deployment model is rock solid, i.e. when testing do things like interrupt
the deployment, power off the computer, delete files, log on as a different
user etc to make sure that the deployment always works correctly.

SP

[quoted text, click to view]

[quoted text, click to view]

What about security? A program that is started from a share is not
trusted, right?
--
Ludwig Stuyck