Before I can answer this question, first let me explain how regular software distribution is done. BTW, the context of this discussion is in regards to Windows EXE applications (not web applications). I mention that because this deployment technology is web based, but what’s being deployed is an actual Windows executable. A web browser is only involved during the launch of the application and not during the execution of the application.
How Windows software is normally deployed:
Without Click-Once technology, to deploy a Windows executable over the internet, you first create the EXE file and any DLLs and config files that go along with it, then package them up in an .MSI installation package file or maybe a .ZIP file. You upload that file to a web server, then provide a web page with a link to the file (or distribute a link in e-mail). The user then clicks the link and uses the browser’s capability to download and save or download and run the file. Then the installation program is launched and the user answers the questions in the install options. When that’s done, a new entry exists in the installed programs (so the user can go to the control panel and uninstall it), the files are installed usually under c:program files, or c:program files (x86). An icon is optionally installed on the desktop, the start menu, and/or the quick-launch bar. Entries are added into the system registry and potentially, DLLs are installed in the machines GAC (Global Assembly Cache) and/or COM components are installed machine-wide.
The next part becomes more difficult: Updates:
If you find bugs in your software that you’ve deployed or have added new features, how do you distribute the fixes to your user base? How do you notify them that there’s a fix available? There are many solutions, but none of them are great. They usually require some way to contact the users and those methods inevitably leave some users out because they can no longer be contacted. Upgrading over an existing installation is difficult, especially if you are many versions into the life of the product, there are multiple versions to contend with.
Security:
Unless you sign your distribution, your users can’t be guaranteed that what they’re downloading is what you published. Imagine a hacker got onto your web server and replaced your software with malware or just replaced one of the files, still turning your software into malware. How do you ensure that doesn’t happen?
Problems encountered with deployment:
- Creating an installation package (not too difficult, usually, but can be, and must be done if there’s anything more than a single .EXE).
- Difficult to ensure that what’s being downloaded by the user is the same thing you put there (like backups, people are generally not concerned about this type of hack until it happens).
- User’s can’t be sure that what they’re downloading is what you deployed (no standard way).
- Difficult to prevent someone from stealing your software and publish it on their own server (and a modified one at that).
- When the user installs, machine wide changes are made, even if it’s just adding uninstall capability to the control panel.
- Uninstalls can go bad, making uninstalling or updating virtually impossible without a significant amount of tedious work.
- Updating software becomes more difficult as more versions are released.
- Difficult to ensure the user is running the latest version.
- Difficult to prevent users from running old versions. (Maybe you’ve changed a web service API or removed an old URL, or some old data structure is now incompatible with the latest version, etc…)
How does Click-Once deployment make this better?
All of the problems above are solved with Click-Once deployment.
Distribution is nearly identical. You deploy your software to a web server and provide a link on a web page (or e-mail the link to users). But, to deploy, you do it directly from Visual Studio by right-clicking your project and choosing “publish” (This resolves issue #1 above). Visual studio prompts you for a certificate to use to sign the distribution (this resolves issues #2, & #3 above). It then prompts you for a file share or FTP path to publish to. It also prompts for the URL from which the users will launch the application. This makes it very difficult for theft (#4 above). With this, the Click-Once run time on the user’s machine will ensure that they’re launching it from the URL you provided during deployment. If it’s not on the URL you specified, Click-Once will refuse to run the application.
When the user runs the application (always done via a URL to your site), the application is downloaded to something similar to the Internet Cache folder… Call it a “Click-Once cache”. No machine changes are made, unless your application has dependencies like DirectX, XNA, etc… that need to be installed (more on that later). The files are simply copied into the cache folder. This resolves issues #5 & #6 above. Subsequent runs will run directly from the cache, but will check online for a newer version and according to your settings when you deployed, will either force a download of the latest version, or allow for 1 back level version to be run. This resolves issues #7, #8, & #9 above.
Regarding dependencies:
One exception to the advantage of not making any machine wide changes are when you’re deploying an application that has dependencies on other technology, such as DirectX, XNA, etc… If your application requires those, obviously, the users machine must have them installed. With Click-Once deployment, you can indicate in your deployment whether you want to include the dependencies with your distribution, or have the Click-Once technology on the user’s machine go and get those dependencies from the vendor’s web site and install them before the first run of the application. The effort on your part is to simply check a check box on or off. There is a optional web page produced when you deploy your Click-Once application that will list all of the dependencies so the user knows what’s required and what may be installed, along with a “Run” button that the user can click to launch the application (which also checks the user’s machine for the dependencies).
You also have the option of actually installing it locally (putting it in c:program files, adding it to the list of installed apps that can be uninstalled, adding icons to the start/programs menu, the desktop, and/or the Quick-Launch bar.
Even if you don’t want it installed locally (usually the preferred option), you can still optionally have icons placed in the start/programs menu, the desktop, and/or the Quick-Launch bar. These icons simply point to a file in the deployment on your web server. This gives the user the user experience as if it were installed, but it always goes online to look for the latest version and runs that if it’s available, otherwise, it’ll run the one from their local cache.