6

I'm writing a windows forms application to be sold to small to mid-size corporations and be used by users on a LAN.

To make it easier for network administrators, I'm thinking of using .Net 3.5 SP1 and have the app running from a network share. This way, client installation is minimal (I know they must have .Net 3.5 SP1 installed).

Admin will install the app in a server, running a windows installer and then email the users the path to the network path so they can start using the app. The alternative is to have the admin install the app in hundreds of PCs, which I try to avoid. Every time I update the app , admin has only to re-install it in a single server.

I want to get your opinion if you used such deployment, what the pitfalls are and what should I be aware of.

Thanks in advanced.

Improve this question
2
  • 1
    Upvoted, because you care.
    – Joseph Kern
    Dec 23, 2009 at 20:20
  • +1 - Wholeheartedly agree.
    – Evan Anderson
    Dec 23, 2009 at 20:21

8 Answers 8

Reset to default
3

Typically, I'd prefer you to just package the application in a Windows Installer (MSI) package. I can deploy that to any number of PCs painlessly in just a few minutes.

I'd rather have the application on the hard disk drives of my PCs versus sitting on a "shared folder" on a server. Odds are good that the application will startup very poorly if the "shared folder" on the server is across a slow WAN line, but the application's user experience, with respect to accessing a remote SQL Server database, may be acceptable over the same WAN line. As such, I'd prefer the application on the PC's hard disk drive.

I also consider my LAN bandwidth to be a precious commodity, and dragging down a program across the wire each time a user starts it seems wasteful to me.

Improve this answer
6
  • I love MSIs. This is a must for application deployments.
    – Joseph Kern
    Dec 23, 2009 at 20:21
  • I can't understand why anybody would use anything but MSI for deployment of Windows applications. I'm sick to death of EXE-based setup programs.
    – Evan Anderson
    Dec 23, 2009 at 20:24
  • Protip: Use 7-zip to open an exe installer and see what's inside. If you download the itunes installer (for example) and open it with 7-zip, guess what you'll find? A slew of MSI!
    – Joseph Kern
    Dec 23, 2009 at 20:32
  • @Joseph: Definitely. Any time I run an EXE-based installer and end up seeing familiar Windows Installer dialogs I start to get suspicious. Checking the event log for "MsiInstaller" entries confirms it, and a quick trip over to the "%TEMP%" directory normally reveals the MSI files that the EXE-based setup unpacked.
    – Evan Anderson
    Dec 23, 2009 at 21:31
  • 1
    Definitely this. Hard drive space is plentiful for most, and the tools are available and easy to use and deploy an MSI using a Software Installation GPO. Visual Studio provides a built-in feature to create an MSI setup package for any .NET project, it is super-easy.
    – Greg Askew
    Dec 23, 2009 at 23:29
2

Evan makes some very good points. I would like to address your update process as well: While I understand that you want to simplify the upgrade process, this can be dangerous. Simple isn't easy.

I would (as an administrator) like to see an MSI installer (with an uninstaller). Upgrades should be handled the same way. In this way, our installation process can also be our upgrade process.

May I also add your first feature request? Make a registry setting that contains the version information of the application. This should be set during installation and reset during upgrades. While not a huge fan of the registry in general this is the windows paradigm. It's much easier than checking the version of the DLLs (or whatever files you'll be using).

Thank you so much for asking us sysadmins what we want. Please come back when ever you have questions, and bring your friends.

Improve this answer
2

You should look into ClickOnce Deployment. Wikipedia description.

Improve this answer
2

+1 for clickonce deployments. I use this to manage 3 app's over 100+ machines in 4 countries.

Improve this answer
1

One thing I would like to add is that .NET application executed from a network path runs under low privileges. Depending upon what your application is doing, this may not be a big deal. But you should check this before you choose this path. There are good suggestions provided on this thread - Click Once, MSI and deployment via GPO. I can say I have used all of them in some capacity. With Click Once you don't need a lot of help from administrator except setting up a virtual directory for hosting your forms app.

Improve this answer
0

I would definitely suggest you AVOID doing this. If your planning to run your application through a network share, then your at the mercy of windows networking when there is failure. Windows shares are slow and often not reliable when many users access the same share. This is due to its complicated networking model.

I have an application which reads files off a share. Often we get random errors which locks us out of the share. There are numerous problems which are just perplexing. I highly suggest you avoid running over a share.

May i recommend a different solution ? Recode your user interface to be a web service. Then, run your application on a web server. Your clients can then use a browser to use your application. Winforms can easily be converted to webforms.

Improve this answer
2
  • It sounds to me like he's planning on dragging the program across the wire via Windows file 'n print sharing, but accessing the data in an SQL Server instance. If he were doing "shared file database", though, I'd agree with your assessment 100% re: not using such an architecture.
    – Evan Anderson
    Dec 23, 2009 at 20:22
  • Andrew, Winforms CAN'T easily be converted to webforms. My app can't be coded as a ASP.Net site because the web platform is limited on what I'm doing.
    – anon2009
    Dec 28, 2009 at 14:29
0

Well this kind of deployment is very established, it's been used since pretty much the dawn of computing. Of course it works fine but clearly puts a lot of load onto the network, if this is in an office with nothing but 100Mb/1Gb links and plenty of server capacity then it'll be fine but this would be pain to run over an internet or low-bandwidth connection.

Improve this answer
0

At the risk of getting hit on the head, I'd prefer it if you developed your application for the end user and not the system administrator. I have several reasons for this:

  1. What if there is no network? You're limiting your potential customer base if your application can't be installed and operated completely on a single machine.

  2. What about companies that don't have network admins? How much work is it going to be to have someone who normally handles accounts payable doing your installs and updates? They'll probably need to hire a consulting company to assist them so you've just added to the TCO for your application. You've also made your application dependent on having a particular infrastructure in place.

  3. There's nothing I hate more than an application that needs to run from a network share. Loading exe's and DLL's over the network is a recipe for problems. A momentary loss of conectivity or congestion and your application stops running correctly because it's lost it's connection to needed exe's and DLL's, etc.

  4. I'm a sysadmin, I'd like my job to be easy but sometimes it's not and that's a fact of the job. Sometimes my job requires me to visit end users to install and update software. If I don't want to do that then I'm probably in the wrong line of work.

When you build cars you build them for the consumer, not the mechanic.

Improve this answer
2
  • I'd argue that, in many cases, a car built for "the mechanic" is good for the consumer, too. An app that's easy to install and maintain on a fleet of PCs ought to be pretty easy to install on a single PC. W/o any offense intended, if you believe that physically visiting computers is the right way to update software then you're betraying the fact that you don't have a large number of computers to be responsible for. If I visited computers to perform updates I'd never get anything done.
    – Evan Anderson
    Dec 24, 2009 at 2:31
  • @Evan: Point taken and no offense taken. I'm not saying that I prefer to visit end users or that it's the most effective, efficient means of installing and updating software. I'm saying that, at the end of the day, it's part of the job. Personally I prefer to deploy software via GPO.
    – joeqwerty
    Dec 24, 2009 at 3:16

You must log in to answer this question.