Windows 8 and ClickOnce : the definitive answer revisited

Since I posted the article titled Windows 8 and Click Once: the definitive answer, it became clear that it was not actually the definitive answer.

I got a ping on twitter from Phil Haack from GitHub telling me that this did not fix their Smart Screen filter problem.

After talking to him, and seeing his build and signing commands, I discovered they recently changed their signing certificate. For those of you who remember the early days of ClickOnce (2005) when you changed the signing certificate and everybody had to uninstall and reinstall the application, this seemed too likely an indicator to ignore.

Reputation

I didn’t talk in my article about “reputation” (and I should have, so I duly apologize here for that). In my first conversations with Microsoft, they mentioned that an application had a reputation, and this reputation had some bearing on the appearance of the Smart Screen Filter, and this reputation was built based on how many people had installed your application.

When I asked how many people had to install your application before the Smart Screen filter stopped interrupting the running of the application, I could not get a clear answer. Of course, this makes sense that they wouldn’t want to make their algorithm public, because you could publish your app, install it X number of times yourself, and make it reputable. (I’m not suggesting you do that, but if you do, please post back and tell us your results. Inquiring minds want to know.)

Since we’ve been in business for a few years, and have well over a thousand customers (probably thousands) who have installed the desktop application, this didn’t impact us. The reason I didn’t mention it in the blog post is because I created a new Windows Forms test application and deployed it solely for the purpose of testing the information in the article, and had no problem with the Smart Screen Filter. I installed the application maybe a dozen times while messing with the build commands, so I figured, “Wow, the number of installs required is pretty small.” Haha!

So on behalf of Phil, I pinged my contact at Microsoft, and he went off to investigate. After a bit of research, he found some information internal to Microsoft. I won’t quote it directly in case I shouldn’t, but the gist of it was this: The digital certificate information may be taken into account when determining the reputation of the application. A-HA! I thought to myself (and immediately started humming that song, “Take On Me”.)

So the problem at GitHub is probably due to the certificate being updated right about the same time they start signing their assembly for customers using Windows 8. I expect that fairly soon, as people install or get updates (if they are using automatic updates), their reputation will be sterling and nobody will ever see the Smart Screen Filter again when installing GitHub.

Knowing this, it makes sense that my test application didn’t get stopped even though it was a brand new application. I signed it with my company’s signing certificate, which has been in use for several months.

Which leads me to another issue I noticed when talking to Phil. I noticed that rather than using PostBuild or BeforePublish commands, he was using AfterCompile commands to sign his executable. I asked him about it.

PostBuild, BeforePublish, and AfterCompile, oh my!

Apparently when Phil signs his executable using PostBuild or BeforePublish commands, when the user installs it, he gets the dreaded “exe has a different computed hash than specified in the manifest” error. He found that using AfterCompile instead fixed the problem.

I went back to Microsoft, and they soon verified the problem, and said it is due to WPF applications having a different set of targets and execution order, so the standard AfterBuild/BeforePublish commands don’t quite work. So the bottom line is this: The signing of the exe doesn’t work right with BeforePublish or PostBuild if you are using VS2012 and you have a WPF application. In that case, you must use AfterCompile. So in the original post, use case #3, but put in AfterCompile instead of BeforePublish.

If you are using VS2010, OR you have a Windows Forms or Console application, you can use PostBuild or BeforePublish with no problem.

Hopefully we now have the definitive answer to handling the Smart Screen filter and signing a ClickOnce application that will be run on a Windows 8 machine.

Thanks to Zarko Hristovski and Paul Keister, who also reported the problem with the BeforePublish command, and who verified that AfterCompile worked for them. Thanks to Phil Haack for the answer to a problem I didn’t know existed yet. And thanks to Saurabh Bhatia at Microsoft for his help with Windows 8 and ClickOnce.