I gave a talk in Mountain View at the South Bay .Net User Group meeting on August 5th. This was a general talk about ClickOnce Deployment and how to use it. Almost everyone in the room was a Windows Forms or WPF developer, which seems rarer and rarer these days as people migrate to web applications. There were a lot of questions, and a lot of good discussion about things that people would like changed in ClickOnce deployment.
The most frequently requested feature in that meeting and in the MSDN ClickOnce Forum is to install a ClickOnce application for all users rather than a specific user.
This is difficult because the files are stored in the user’s profile, where the user has read/write privileges. One of the design goals of ClickOnce is to provide a deployment technique that allows customers to install applications without elevated privileges. Installing an application for all users requires privileges.
Another design goal was to protect the client machine from problems caused by software installations. Do you remember “dll hell”? This was the problem that happened when another application came along and replaced a dll that you were dependent on, and caused problems for your application, or vice versa.
In a ClickOnce deployment, it is possible to include most of the dll’s locally with the deployment, rather than installing them in the GAC or the windows system directory. (This is excluding, of course, the .NET Framework and other prerequisite applications such as SQLServer Express.) You can even deploy the SQL Compact Edition dll’s or DirectX dll’s. This allows you to maintain strict version control on the dll’s that you include in your deployment. Microsoft would have to figure out a way to handle this if the application were deployed for all users; if they weren’t careful, you could easily end up in dll hell again.
On the other hand, if they just chose to put the files under the All Users profile, once again you have the permissions problem that Microsoft sought to handle with ClickOnce deployment, because the user can’t write to those files without elevated privileges. Also, If Microsoft stored the deployed files in the “All Users” folder, they would have to figure out what to do if UserA was logged on using the application, and then UserB logged on and there was an update available. Do you kick off UserA? Do you forego the update because UserA is already running the application? What is UserA always leaves his account logged on? How will you ever do an update?
This request has been passed on to Microsoft, but I haven’t heard of any plans to include a change to this in .NET 4.0, so I wouldn’t expect any quick results. Doing an all-users install is counter to the design goals of ClickOnce deployment, so I think it’s going to be something everyone has to live with, at least for now. Using XCopy or a setup & deployment package and rolling your own incremental update methodology would be the way to go if you absolutely have to have an All Users installation.