Smart Client Deployment with ClickOnce

One of the sessions I attended at Day of .NET was on ClickOnce.  Someone asked a question about a ClickOnce book, and I recommended Smart Client Deployment with ClickOnce: Deploying Windows Forms Applications with ClickOnce (Microsoft .NET Development Series). Of course, I couldn't remember the name of the book at the time. I described it as "white with the blue checks" and "from Microsoft, but not the orange ones". In case people who asked may read my blog, and couldn't figure it out from my description (don't know why that would be true), I thought I'd do a blog post.

So, about the book itself, I really liked it.  It covers all of the basics, but also helped me jump a lot of hurdles that I may not have figured out on my own.  It was easy to read, and I've gone back to refer to it several times (currently has three bookmarks in it, which is one good sign of a book I'm actually using).  

Beyond the basics, the book discusses controlling updates yourself programmatically, localizing the deployment, handling data files (a little tricky with ClickOnce), deploying extensible applications (plug-ins), security, certificates, and adding prerequisite items to the bootstrapper. 

I find that the best books for me are usually ones that cover a narrow topic in depth, and this falls into that category.  So, if you're not interested in ClickOnce deployment, you'll probably never give this a second glance.  But if you are interested in ClickOnce, pick up this book.  I highly recommend it.

ClickOnce and clicking the launch link before the .NET framework is installed

Here's an interesting tidbit that I haven't seen mentioned elsewhere.  In testing a ClickOnce application on a (virtual) machine without the .NET framework installed, I first tried to run the application by clicking the launch link (just like I think many users would).  Much to my initial surprise, it popped up the dialog box to download the application file.  I checked the server configuration, and everything looked okay, meaning the .application extension was associated with the correct MIME type (application/x-ms-application).  After some reflection, I surmised this behavior was due to the fact that the .NET framework was not installed on the client machine.  Once the framework was installed, the launch link did launch the application.  So if your users cannot launch a ClickOnce application, it might be because the don't have the framework installed, not because of any server configuration.

ClickOnce and Bogus Required Assemblies

When I got by the ClickOnce issues described in my previous post and was able to install the prerequisites on the client, I thought I was home free.  You'd think that after almost twenty years of professional programming I'd have learned better by now...

After ClickOnce successfully installed the prerequisites and was starting to install my application, I got the following dialog saying that the "application requires that assembly ADODB Version 7.0.3300.0 be installed in the Global Assembly Cache (GAC) first":

My first issue was that I couldn't figure out why ADODB was required.   The client application does no data manipulation, it simply accesses WCF services on a remote machine.   The ClickOnce installation was asking for it because it was specified as a prerequisite in the Application Files dialog on the Publish section of the project properties:

For some reason, Visual Studio decided the ADODB.dll was required.  I can't say I ever figured out why.   I saw some Google threads from people having the same issue who speculated it was the ReportViewer that triggered the requirement for ADODB.dll, but I never saw any authoritative information.

In the same Google threads, I saw there were two ways people dealt with this problem.  The first is to mark the file to be explicitly included, rather than being a prerequisite.  This causes the file to be deployed along with the application.  Other people explicitly marked the files to be excluded, which is what I did:

(Note that once a file is marked as excluded it only shows up in this list when the "Show All Files" control is checked.)   Excluding the file addressed the installation issue, and my application ran fine.   If something in my application actually requires ADODB.dll, I haven't found it yet.  I also excluded the SMDiagnostics.dll which was listed as a prerequisite for some reason.  The moral of the story is that in ClickOnce files sometimes show up as being prerequisites when they are not.  If you know they are not required for your application, marking them as excluded seems to be the best way to handle this.

ClickOnce and ReportViewer

Update: As commented by Jeff below, this solution will not work for ReportViewer 2012.  Please see his comment for more details.

In my previous blog post I talked about  my initial struggles with ClickOnce and the .NET 3.0 framework.  After overcoming the initial issues, I was trying to test deploying the application on a client machine without the .NET framework installed.  So I created an XP Pro virtual machine in VMware, and installed all of the high priority Windows updates, carefully avoiding the .NET frameworks (which are all available as optional updates).
Since the framework wasn't installed, I clicked the button to Install the prerequisites, which worked well for a while.  It downloaded the .NET 3.0 Framework and the ReportViewer.   It installed the framework.  But when it tried install the ReportViewer, the following dialog appeared with the interesting message "Setup has detected that the file ...\ReportViewer.exe has changed since it was initially published.":

After some head scratching and Google searching, I had a theory as to what was causing this issue.  When publishing a ClickOnce application with prerequisites, you can choose for the client to download the prerequisites from the "component vendor's web site" or a known location that you specify (either by an absolute location, or in the same location as the ClickOnce installation files.)  I had chosen to download the prerequisites from the "component vendor's web site".
Based on information on the web, I knew there was a new version of the ReportViewer control released with VS.NET Service Pack 1, and a subsequent update (quite confusingly called Report Viewer 2005 Service Pack 1) to fix things they broke in the VS.NET SP 1 version.   So my theory was that the version it was downloading from the web did not match what I had on my local machine (and thus what the installation was expecting).
So I first bit the bullet and installed the Visual Studio Service Pack (which I'll rant about in a separate post).  And then I downloaded the subsequently updated ReportViewer.  To get it to be published, I needed to copy the ReportViewer.exe to the correct Bootstrapper folder, which on my machine is: C:\Program Files\Microsoft.NET\SDK\v2.0\Bootstrapper\Packages\ReportViewer as described in a previous post.  And sure enough, when I did this and published the application again, it was able to install both the .NET framework and the ReportViewer control on the client.
This seems like a potential issue with choosing the "component vendor's web site" to get prerequisites.  If you choose this option and the vendor updates the item to a newer version than what was on the machine when you published the deployment, it will fail to install.  Seems like the better route is to choose one of the options to install prerequisites from a known location.

ClickOnce and .NET 3.0 Prerequisite

I'm working on a WinForm application that will utilize WCF to access services on a remote server, and that will be installed via ClickOnce.  Since it's using WCF, I need to ensure that the 3.0 framework is installed on the client machine.  Luckily, ClickOnce has a nice mechanism to install prerequisites.  Unluckily, .NET 3.0 wasn't showing up in the prerequisites I could choose from.   And it should have been since I took all the necessary steps, which are: 

1. Install the Visual Studio 2005 extensions for .NET Framework 3.0 (WCF & WPF), November 2006 CTP.   
2. Copy the redistributable files (dotnetfx3.exe and dotnetfx3_x64.exe,) to the folder C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\BootStrapper\Packages\NETFX30. 

At least that's what everyone said.  After a little more research on adding custom prerequisites, I found out how Visual Studio looks for the the prerequisites, which is by looking at these registry keys in order:

1. HKCU\Software\Microsoft\GenericBootstrapper\1.0\Path
2. HKLM\Software\Microsoft\GenericBootstrapper\1.0\Path
3. HKLM\Software\Microsoft\.NET Framework\sdkInstallRootv2.0

I had no values for the first two, but the third was pointing to C:\Program Files\Microsoft.NET\SDK\v2.0\.  Under this folder, there was a BootStrapper\Packages folder that actually contained items.    So when I copied my NETFX3.0 folder from the Visual Studio folder to the SDK folder, it showed up as an available prerequisite in Visual Studio.  Which led to my next problem, that I'll blog about when I've figured out how to address it...