Why you should not use Clickonce deployment as your enterprise application's deployment methodology

Why you should not use Clickonce deployment as your enterprise application's deployment methodology (especially for banks and securities companies).

Introduction

If you decide to build your enterprise applications through .NET, may be the deployment strategy is one of the most important jobs in your whole project. Failure of the deployment strategy may result in lower customer satisfaction and also increase maintenance costs. Through my experience of building enterprise applications for banks and securities companies, I'll suggest four very clear reasons why you should not use Clickonce as your deployment strategy for your enterprise applications.

Three reasons why you should not choose Clickonce

Reason 1. Clickonce does not support proxy networks

If your customer company uses proxy servers for their network security and if your application is deployed under Clickonce technology, simply, your application doesn't get deployed under the proxy network.

And also I found that almost every bank and securities company uses a proxy network (HSBC, City Bank, Goldman Sachs.. and so on..). So if your clients are companies like that, just don't try to use Clickonce deployment because it does not work at all (there is a way to run Clickonce under a proxy network, if you have the power to order every customer to fix the settings of the machine.config file which is located very deep inside the Windows folder).

Reason 2. Assembly verification time is too long

Even though your application has a moderate number of assemblies, your clients should wait more than minutes to be deployed.

Reason 3. Customization is not allowed.

If you have more than 50 assemblies to be deployed, a financial company's network security device may disconnect your deployment process forcibly with sync flooding failure. Even though you know the cause of that failure, you can not GZip your assemblies into lesser than five physical files because Clickonce does not support doing that.

I haven't been in a corporation yet where ClickOnce does not work. Two were financial organizations but not banks. So it is possible that it does not work on a proxy network but this would not limit it for the majority of non-bank organization (which are many). So that is a good warning but only a valid reason if it does not work in your organization/corporation.
Dwipayan Das' post about it working in .NET 3.5+ could/should be verified by other users here.

Reason 2 - It's not long to wait for assembly verification. I've built and deployed a complex application and the wait was never minutes. Just how big is this application where one has to wait minutes?

Reason 3 - Yes, customization is limited with ClickOnce and deployment is overly complex but it is very, very usable. You can even just use it for a "bootstrapper" install where you install a stub program with ClickOnce that brings down the full main program from a server or even modules of the app as they are needed (install on demand).

What is overlooked by the author is the big advantages of ClickOnce:

1. You can write WinForms apps instead of WebForms apps. Which can be 5-7 times faster to develop for complex apps. This is a MAJOR advantage that few people realize.

2. WinForms is a mature technology while web technology is still trying to fully emulate. If your program is moderately to highly complex it's much easier to build a WinForms ClickOnce version that works wonderfully well instead of struggling with all the UI workarounds needed for WebForms implementations.

3. Internally used apps do not have to be web apps in order to be deployed and updated via web server. ClickOnce works fine.

4. "Legacy" WinForms applications do not have to be ported to WebForms. Just set them up to install and run with auto updating via ClickOnce.

Really, ClickOnce is a highly useful, very overlooked technology that provides great "force multiplication" in the enterprise.

If the author could post his "launcher software which replace clickone" that would be nice to review as an alternative.

Even having purchased VS 2010, I don't use clickonce. It doesn't seem to allow your normal programming procedures like you get with NSIS or INNO. It does not install programs normally, and there seems to be issues with multiple copies of the same program in the .net program store if you change the program without updating the assembly version.

I suppose ClickOnce would be good for small office envrionments.

However, I stay with Inno because you can specify exactly where you want ALL of your application components to go, you can check for running processes and do exactly what you want with your program using the installer.

ClickOnce just isn't so programmable - in my opinion, it is way too "automatic". However, I think that "automatic-ness" is the idea MS was trying to achieve. The idea (again, IMHO) is to remove all the time and necessary knowledge spent in understanding different computer systems and in how to install the applications. If you are going to let MS automate your install, you have to be willing to sacrifice what *you* think should be done and accept what MS thinks should be done.

I think ClickOnce might have been nice if you were given a long list of checkboxes with various options on how you want your installation to act. You do get a few options with ClickOnce, but with ClickOnce, you will never come close to the traditional program installation.

In my wanderings of trying out new applications, I tend to avoid any that are ClickOnce - they have issues, in my experience. Their settings files are hard to manage (if you can find them), if the server that hosts the ClickOnce installer is no longer available, your installer doesn't work (out of luck legacy!), and you can end up with multiple installations of the same program without knowing it.

Maybe I am wrong in some of my comments, but I have adopted the practice of not spending too much time on applications that don't work the way I expect them to (that is, they are not intuitive). Usually, I can figure a program out very quickly, but I have not had good experience with either making or using ClickOnce applications.

Reason 5: You cant change the install path.
Reason 6: Every update will saved on the computer. If you have a program that is 50 mb and 20 updates installed. 1 Gb of disk space is gone.
Reason 7: ClickOnce uses the registry also. If your client uses a program like DeepFreeze your updates are gone when you restart the pc.

I developed launcher software which replace clickonce technology. if your clients are limited number and also they use your application under unlimited network environment, and your application is not so complex, clickonce is quite simple and easy technology to use.
but if your application is complex and also loading time and stability is critical matter, you'd better develop additional launcher software which meets your requirement.