Troubleshooting ClickOnce deployment issues
August 25, 2007 9:18 pmHi! It looks like you're new here. Welcome! If you like what you see, I encourage you to subscribe to my RSS feed. If you're worried about adding another RSS feed that will add to your information overload, don't! I'm not a prolific poster. Thanks for visiting!
Over the last few days I ran into several puzzling ClickOnce deployment problems. I want to document and share these so that I’ll remember them better, and so others might find help with similar issues.
The first issue:
I uploaded new versions of my files several times, but every time I attempted to download the refreshed versions, no matter which computer I tried it on, all I got were old files. Ctrl+F5 in IE didn’t make a difference. Clearing the Internet Explorer history, cookies, temporary files didn’t make a difference. I even contacted my web host to see if they have any caching issues on the server side. In the end I stumbled across my installation of Fiddler, the HTTP debugging proxy. I looked at the raw HTTP dumps, and then I saw the issue: I’m behind an active caching proxy on my home network. The proxy was giving me old files all the time.
First issue solution:
Clean out the cache files on my proxy server. It happens to be squid, so this did it:
service squid stop
echo “” > /var/spool/squid/swap.state
service squid start
The second issue:
During the troubleshooting of the first issue I had started suspecting the ClickOnce caching system to be at fault. So I used “mage -cc” and “rundll32 dfshim CleanOnlineAppCache” to clean out the cache. No change. Then I started manually deleting files from the cache location on the hard drive. Bad mistake. Now I got weird deployment errors, talking about COM objects not being available, and “interesting” HRESULT errors: The referenced assembly is not installed on your system. (Exception from HRESULT: 0×800736B3). I uninstalled the .NET Framework 2.0 and 3.0 and reinstalled them. No change. Luckily I found an article on the MSDN forums that pointed me to a registry location to check out: HKCU\ Software\ Classes\ Software\ Microsoft\ Windows\ CurrentVersion\ Deployment. I checked it out and found a bunch of registry keys that I remembered seeing when I cleaned out the cache files before. So what would happen if I deleted all those keys? Maybe it would “reset” ClickOnce completely? Luckily it did.
Second issue solution:
Clean out both the ClickOnce cache files [C:\Documents and Settings\(User)\Local Settings\Apps\2.0] by hand (completely), and also clean out the registry keys under Components, Marks, PackageMetadata, StateManager\ Applications, StateManager\ Families and Visibility underneath HKEY_CURRENT_USER\ Software\ Classes\ Software\ Microsoft\ Windows\ CurrentVersion\ Deployment\ SideBySide\ 2.0
Caution! Your Mileage May Vary. Deleting registry stuff is dangerous! Make a backup first.
Categories: Software, Software development
2 Responses to “Troubleshooting ClickOnce deployment issues”
Hi, maybe this is a newbie question but why does .NET require to increment the version number on everytime an application is deployed via clickonce? This is very annoying especially when I make a test version multiple times; but maybe there is some reasonable explanation. Why can’t .NET recognize the new files and without generating a new version number and filling the cache up?
Good question. I can’t speak for Microsoft, so I can only give you my guess. It probably has to do with the complexity of checking timestamps/file contents and whatnot. Checking the version number is a well-defined, relatively reliable, non-ambiguous way of doing things. If you’re using Visual Studio, you can tell it to increment the version number automatically every time you publish your files, so it’s not too much of a headache for me personally. It doesn’t even have to be a major or minor version change, it can be all the way down in the revision group (1.0.0.xyz). I’d ask the question on the Microsoft MSDN forums, if I were you.
Care to comment?