October Appearances

You can meet me at one of these events (oooooh, aaaaah):
10/2/2009 Silicon Valley Code Camp
10/8/2009 Central California .NET User Group
10/14/2009 East Bay .NET User Group
11/18/2009 San Francisco .NET User Group

I’m going to be speaking this weekend (October 2nd) at the Silicon Valley Code Camp. My session is at 11:00 a.m. and is on the difficulties of ClickOnce Deployment, and some of the bugs I have uncovered and how to deal with them. I have several topics for discussion, but will try to address questions that people bring, and then discuss whichever topics they are most interested in.

The questions that seem to be asked the most in the forums are about desktop shortcuts and deploying data or just including extra files. Deploying data is a big one, and I have done a bunch of tests to see exactly how to deploy a SQLCE or SQLExpress database with your ClickOnce application. I will be blogging that some time in the not-too-distant future.

If you miss the SVCC event, and/or want more detail, come to the East Bay .NET User Group meeting on October 14th at University of Phoenix in Livermore. It’s right on the west edge of Livermore, barely out of Pleasanton. I will be covering the data deployment and certificate issues and basically the same topics as CodeCamp, but in more detail.

If you are interested in VSTO development, I will be giving a talk at the Central California .NET User Group meeting on October 8th. That one will cover how to create an Outlook Add-In, including modifying the ribbon, and I’m thinking data binding in Excel and maybe Forms in Outlook. I will also discuss ClickOnce deployment of a VSTO application and the bug I discovered therein.

If that interests you but Fresno is too far away, I will be giving the same talk in San Francisco on November 18th.

I also have an update to the “expiring certificate problem”, and I will be adding the new content here and linking the previous entry to the new one. I have also translated the code into VB.Net for those of you who are VB developers. (Unlike many C# developers, I don’t feel there is a whole lot of difference between the two languages, and do not discriminate based on your language of choice.) I just need to pass it by someone at Microsoft to make sure it’s completely accurate and then I will post it.

Installing a ClickOnce Application for all users

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.