There have been a lot of copies of Windows 8 sold since it came out a few months ago, and the Surface Pro was just released. (In fact, I’m writing this on my brand new Surface Pro, which I really like, but that’s a subject for another time.)
If you’re using ClickOnce deployment, you’re probably wondering how (or if) it’s going to work with Windows 8. I’ve worked with Saurabh Bhatia at Microsoft to ensure that this article will cover what you need to know. We use ClickOnce at GoldMail (whose product is now called Point Across) for our desktop product and VSTO applications, as well as several internal utility applications, so I’ve also tested this on our products to make sure it’s accurate.
If you are hosting your deployment on a file share or on an intranet, you won’t have to make any changes. You can go get ice cream now while the rest of us soldier on.
If you are hosting your deployment on the internet, you will eventually get calls from your customers who have upgraded to Windows 8 or purchased a Windows 8 machine. So let’s talk about that.
I’m not going to talk about the bootstrapper right now; that’s going to come up later. For now, let’s concentrate on the ClickOnce application itself. When a user installs a ClickOnce application on Windows 8, here’s what happens:
- ClickOnce gets the manifest, checks the certificate, and shows the ClickOnce prompt with “trusted publisher” or “unknown publisher” (depending on your signing certificate).
- The user clicks the Install button.
- It checks the certificate on the executable. If it’s not signed, the Smart Screen Filter is triggered.
So here’s what the user experience looks like when you install a ClickOnce application on Windows 8:
You get the standard install prompt:
The publisher is known because I am signing the deployment with a signing certificate purchased from a Certificate Authority – in this case, Verisign.
If you click Install, it shows the standard install dialog and actually installs the application. But then it shows a blue band across your screen saying, “Windows SmartScreen prevented an unrecognized app from starting. Running this app might put your PC at risk.”
There is a small “More Info” link under the warning, and a big “OK” button on the bottom of the dialog. Which one would you click? Which one would your customers click? Most people will click the OK button.
If the user clicks OK, the dialog closes, and nothing else happens. Now let’s say the user goes to TileWorld (I’m borrowing David Pogue’s name for the new Windows 8 interface formerly known as Metro). The user can see the application there in the list of apps because it actually got installed. If he clicks on it to run it, nothing happens. So congratulations! The user has installed your application, but he can’t run it.
What happens if the user clicks “More Info” instead of “OK”? He sees the following screen, and he can choose “Run Anyway” or “Don’t run”.
For “Publisher”, it says “Unknown publisher” – this is referring to the executable, which is not specifically signed. Only the manifests are signed. This has never been a requirement for ClickOnce deployments. Until now.
If the user chooses “Run Anyway”, it will run the application. Yay! And when he goes back to TileWorld and tries to run it from there the next time, it will work and will not prompt him again. Yay!
So let’s say he clicks “Run Anyway”, and now he has no problem running your application. What happens when an update is published and he installs it? Uh-oh. The smart screen filter interrupts again, and he has to select “More Info” and “Run Anyway” again.
Is there a way to circumvent your ClickOnce application being captured and stopped by the Smart Screen Filter? Yes. Otherwise, this would be a much shorter (and depressing) article. All you have to do is sign the application executable after building it and before deploying it. For this, you need your signing certificate and signtool.exe, which is one of the .NET Framework tools. There are three points in the build/publish process at which you can do this:
1. Post-publish
2. Post-build
3. Pre-publish
#1: Signing the application executable post-publish
To do it post-publish, you have to do the following:
- a. Publish the files to a local directory.
- b. Use signtool to sign the exe for the application.
- c. Use mage or mageUI to re-sign the application manifest (.exe.manifest).
- d. Use mage or mageUI to re-sign the deployment manifest (.application).
- e. Copy the files to the deployment location.
If you’ve already automated your deployment with a script and msbuild, this may be the choice you make. If you publish directly from Visual Studio, the other two options are easier.
#2: Signing the application executable post-build
To do this, you define a post-build command in your project. Assuming your certificate (pfx file) is in the top level of your project, you can use something like this:
"C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\bin\signtool.exe" sign /f "$(ProjectDir)TestWin8CO_TemporaryKey.pfx" /p nightbird /v "$(ProjectDir)obj\x86\$(ConfigurationName)\$(TargetFileName)"
- The double quotes are required.
- “C:Program Files (x86)Microsoft SDKsWindows\v7.0A\bin\signtool.exe” is the path to the signtool application, used to sign the executable.
- $(ProjectDir) points to the top directory of the project. The subfolder “\obj\x86” will vary depending on your build output path. The above was created and tested on VS2010. On VS2012, my subfolder is just \obj.
- $(ConfigurationName) is the build configuration name, such as Debug or Release – this is required because it signs it in the obj directory and has to know which folder to use.
- $(TargetFileName) is the name of the application executable.
- TestWin8CO_TemporaryKey.pfx is the name of my certificate file, which is in the top folder of my project.
- /p nightbird – this is the password for my temporary certificate
I have specified the full path to signtool.exe. I tried to do this with one of the msbuild variables that points to the location of the .NET framework files, but it doesn’t work – it doesn’t translate the variable until after it executes the statement. If you print it out in the post-build command, it shows the right location in the Visual Studio output window, but gives you an error that it can’t find it when it actually runs this statement. I’m saving you some time here, because I messed around with that for quite a while trying to get it to work, and after asking Saurabh at Microsoft, he couldn’t get it to work without specifying the whole path, either. So if you get it to work with a msbuild variable, let me know how.
After you’ve created your version of the post-build command, you need to put it in the project properties. Double-click on Properties and click on the Build Events tab. Put your command in the Post-build event command line box.
Now build the project, and the output window will show the results.
If you now publish the application and put the files in the deployment directory, the user can install it and will not see the Smart Screen Filter. Yay!
What if you have multiple programmers working on the application, and they all build and run the application? Every programmer must have signtool.exe in the exact same location for this post-build command to work for everybody. If you have a 32-bit machine, the folder for the “Microsoft SDKs” is under “C:Program Files”, without the “(x86)” on the end. And someone might actually install Windows to a drive other than C. If their signtool.exe file is not in the same location, they can’t build and run the application, which means they can’t put in changes and test them.
Only the person publishing the application really needs this build command to work. So how do you execute this only for the person publishing the application? You can set up a pre-publish command.
#3: Signing the application executable pre-publish (recommended solution)
The pre-publish command is executed after building the application and right before publishing it. There is no box for this under Build Events, so you have to add it to the project yourself. (Be sure to clear out the post-build event command line before doing this.)
To add a pre-publish command, right-click on the project in Visual Studio and select “Unload Project”.
Now right-click on the project again and select “Edit yourprojectname.csproj”.
It will open the csproj file in Visual Studio so you can edit it. Go down to the bottom and add a new section before the </Project> line. You’re going to put your pre-publish command line in this section.
<Target Name=”BeforePublish”>
</Target>
So what do you put in this section? You are going to specify a command to execute, so you have to use Exec Command, and put the command to execute in double quotes. Since you can’t put double-quotes inside of double-quotes (at least, not if you want it to work), you need to change the double-quotes in your command to " instead. So my build command from above now looks like this:
<Exec Command=""C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\bin\signtool.exe" sign /f "$(ProjectDir)TestWin8CO_TemporaryKey.pfx" /p nightbird /v "$(ProjectDir)obj\x86\$(ConfigurationName)\$(TargetFileName)"" />
After making this match your parameters, save the csproj file and then close it. Then right-click on the project and reload it:
Now if you build your project, you won’t see anything about signing the application executable in the output window. It will only do it if you publish, and there won’t be logging letting you know it signed it. How do you know if it worked? Go to the folder you published to, and look in the Application Files folder. Locate the application executable in the folder for the new version. Right-click on it, choose properties. Look for a tab called “Digital Signatures”. If it’s not found, it’s not signed. If you do see it, go to that tab; it will show the signature list and the signer of the certificate. You can double-click on the signer and then view the signing certificate.
How will the application work after publishing it with a signed executable?
If you sign your executable and your deployment with a valid certificate from a Certificate Authority like Verisign using one of the methods above, when the user clicks install, it will install without stopping and showing the SmartScreen filter, and updates will do the same. Yay!
Do I have to use a certificate from a Certificate Authority to circumvent the Smart Screen Filter?
Yes.
Is there any workaround?
No.
If you try the old tried and true “install the certificate in the trusted publishers store on the client computer”, you will find that this does not circumvent the Smart Screen Filter. You must have a certificate from a valid Certificate Authority. Without one, your customer will get the Smart Screen filter when he installs the application, and every time he installs an update.
What about the bootstrapper (setup.exe)?
The bootstrapper (setup.exe) is signed the same way as the ClickOnce deployment; this happens when you publish. When run, this installs the prerequisites and then calls the ClickOnce application installation. If your certificate is not from a valid CA, the Smart Screen Filter will catch it. This isn’t as critical a problem as the ClickOnce deployment itself because in most cases, your users will only run this the first time.
What about VSTO applications?
If your VSTO application is deployed via a file share or the intranet zone, you will not be impacted. If your VSTO application is deployed via the Internet zone, you may be impacted.
There is no executable for a VSTO application, just an assembly, so you don’t have to do any extra signing. However, the following is true:
If you sign your deployment with a certificate from a CA, everything will work fine, and the Smart Screen filter will not interrupt either the setup.exe or the vsto file from installing the app or keep the app from running.
If you are using a test certificate, setup.exe will be caught by the Smart Screen filter. If you click ‘Run Anyway’, it will install the prerequisites, but it will not let you install the VSTO application.
If you install the test certificate in the Trusted Publishers store, setup.exe will still be caught by the Smart Screen filter, but the VSTO application can be installed and run. This is strongly advised against, as installing the certificate on the user’s machine introduces a significant security risk.
Which method to you recommend?
The advantage of the post-build command is that it is transparent. You can easily go into the Build properties and see there is a post-build command. A pre-publish command is kind of hidden in the project file. However, everybody has to have signtool.exe in the same place, and for us that’s a non-starter. Also, if I did leave the post-build command in there, someone might change it to match their path and check in the change, causing a problem when we actually try to build the application for production.
I used the post-build methods to test my build command until I got it to work, and then ported it to a pre-publish command.
To summarize, a flowchart:
In summary, here’s a flowchart to help you easily see whether your users will get the Smart Screen filter when they install your application on Windows 8.
One last note: The first version of VS2012 had a bug where the bootstrapper created when publishing a ClickOnce application would not work on a Windows XP machine. This problem was fixed in the first update.
[edit: Fixed build paths, some \’s were missing. Added recommendation. –Robin 2.26.2013]
[edit: After publishing this article, I heard from a couple of people who were still having problems. Please check out the next blog article about this if you are still having problems with the Smart Screen filter, or getting the dreaded “exe has a different computed hash than the manifest” error. –Robin 4.14.2013]
Tags: ClickOnce
RobinDotNet's Blog 
February 25, 2013 at 11:37 pm |
Thanks Robin, this is really helpful. I’ve been signing exes for some time because it’s recommended for QuickBooks add-ons, but you’ve taken things a step farther than I ever did. One thing to watch out for: when you switch from VS 2010 to VS 2012, you may find that you get manifest errors with the post-build technique. That’s because the manifest signing in VS 2012 is done before the post build (at least that what I’ve found). If you sign the manifest before the exe is signed, the signature doesn’t match. I’m hoping that the pre-publish event wil fix this problem and allow me to use VS 2012 for deployments.
February 26, 2013 at 12:44 pm |
Hi Paul,
Thank you for your feedback. I have tested the code on VS2012 using the post-build method, and it works fine (for me).
If you have any add-ins installed for Visual Studio, you should use the Publish options from the BUILD command rather than the Publish button in the Publish dialog. The one under the BUILD menu goes directly to msbuild. The one in the Publish tab goes through Visual Studio (that’s the best explanation I’ve ever managed to wrangle out of Microsoft, apparently there’s some black magic going on there), and there is sometimes a race condition that results in it trying to do the signing before the build is completed, and you get an error saying something like the exe was not found. This could be the issue you were seeing, rather than a difference between VS2010 and VS20102.
Robin
April 10, 2013 at 11:02 pm |
Sorry to report the the PrePublish event did not fix the problem. I’ve entered a connect issue on this:
https://connect.microsoft.com/VisualStudio/feedback/details/783418/clickonce-publish-results-in-invalid-hash-when-exe-is-signed-with-vs-2012
April 14, 2013 at 10:39 pm |
Please check out , which addresses your issue.
–Robin
February 26, 2013 at 9:45 am |
Thanks for the thorough article on the topic. In what way do you believe that having ClickOnce deployed to an intranet mitigates this problem? I believe the Smart Screen can be disabled via group policy, but do you know of another way?
-Glenn
February 26, 2013 at 11:43 am |
The smart screen filter is only invoked when installing applications from the Internet zone. If a user is installing it from the Intranet zone, it will not show the SSF. You can see the zone security settings in IE under Options/Security.
February 27, 2013 at 1:48 am |
Great article Robin.
Looks like you are the only person on the WWW who actually write about Click once, regularly 🙂 Thanks for that 🙂
February 28, 2013 at 6:22 am |
[…] Read original post at RobinDotNet's Blog […]
March 2, 2013 at 4:30 am |
Hello Robin,
Thank you very much for all the details !
As a WPF/Clickonce freelance developer, I was a bit afraid of this W8 Smart Screen filter.
So, there is a workaround ! The only problem is I need to pay a certificate authority now to sell my products….It’s probably cheap for an organisation, but not for an individual.
Do you know a “low cost” authority in this case ?
Once again, many thanks for all your click once articles !
Xsch
March 5, 2013 at 3:09 pm |
Hi xsch,
Thanks for your feedback! As for a low-cost cert authority, I think godaddy sells code signing certs for a lower cost. I have no personal experience with it, but that’s what I’ve been told.
Robin
March 3, 2013 at 11:19 am |
Thank you for this excellent article!
I was getting grey hair from the Windows 8 smartfilter behaviour when using click once.
Actually I got this approach to work with Red-Gate SmartAssembly (obfuscation)
If I processed the assembly with SmartAssembly first and then signed it (both in “AfterCompile”)
Then the executable was obfuscated AND signed!
Without you SmartFilter would still be a pain in my … 🙂
March 5, 2013 at 3:08 pm |
You’re welcome. It was going to be a royal p.i.t.a. for us, too! And thanks for the info about using it with obfuscation.
Robin
March 7, 2013 at 12:08 pm |
Robin,
We have been fighting similar issues with out Click Once deployment. Using the following order we are running into an issue where our Application won’t run. The click once install displays the following error “File, MyFile.exe, has a different computed hash than specified in manifest.”
Deployment Order (all done via MSBuild)
1) Create App Manifest (mage.exe)
2) Rename Files to .deploy
3) Sign MyFile.exe.deploy
4) Create Deployment Manifest
5) Sign Deployment Manifest
We have tried signing MyFile.exe before renaming the files to .deploy, but we receive the same error.
Any thoughts or suggestions would be much appreciated.
Thanks
-Phil
March 7, 2013 at 12:22 pm |
Hi,
First, I need clarity on what you are calling the app manifest and deployment manifest. The application manifest is the one that is in the Application Files\version\ folder, like yourapp.exe.manifest. The deployment manifest is the one with the file extension .application. (Yes, someone at Microsoft wasn’t paying attention when they named those).
Having said that, I think you need to do those steps in this order:
1. Sign exe file.
2. Rename files .deploy.
3. Create application manifest.
4. Create deployment manifest, with link to application manifest.
5. Sign deployment manifest.
You always have to create the .exe.manifest file first, and then point the deployment manifest to it and create the deployment manifest. You can do this manually with MageUI just to see if it works, before automating it with mage. Note that if when you sign the deployment manifest with mageUI, you have to go to the application manifest and re-select it, even if it’s right, before signing the deployment manifest. I assume the same to be true when using mage.
Robin
March 8, 2013 at 7:31 am |
Robin – Thanks for the quick reply. Correct, those are the files I was referring to as app manifest and deployment manifest. We made some progress this morning. We ended up using the following order (renaming the files to .deploy before creating the app manifest created errors ie. has mismatched identity file name” error).
1. Sign exe file.
2. Create application manifest.
3. Rename files .deploy.
4. Resign application manifest
4. Create deployment manifest, with link to application manifest.
5. Sign deployment manifest.
Following the steps above we are still prompted by the smart screen, but our name now shows up under Publisher after selecting more info. This feels one step closer. I don’t know if that brings up any other thoughts on what might be causing the smart screen to display, if so I’d love to hear your thoughts, if not thanks again for all the help you have given so far.
Thanks,
Phil
March 21, 2013 at 12:47 pm |
On our company the SmartScreen disappeared after some test downloads in various machines.
April 6, 2013 at 4:48 pm
There is a ‘reputation’ that also goes into the determination of whether the Smart Screen shows up or not, but it’s more than a few downloads. I don’t know exactly how many, because my company has thousands of customers that run our desktop application every day.
March 8, 2013 at 3:32 pm |
Imagine, if you will, a small fast-food restaurant called John Doe’s Burgers. Located on either side of John Doe’s Burgers are a McDonalds and a Burger King. Across the street, there’s another burger shop called Jim Smith’s Burgers. Jim Smith’s Burgers has more locations and more business revenue than John Doe’s, but not nearly as much as the national chains.
Now imagine McDonalds and Burger King each paying annual fees for Extended Vigilance (EV) reputation protection to their own choice of Culinary Authorities (CAs) thought by the public to be trustworthy. John can’t afford to pay the fees, so he operates without paying the fees. Jim has a bit more cash flow, so he pays the standard reputation protection subscription rate at one of the CAs, but just can’t afford the EV price.
A large corporation that cares deeply about the diets of all its customers, let’s call it Master-diet Solutions (MS), only wants its customers to eat healthy food. Their product dominates the home and corporate marketplace, making up almost 90% of all dietary systems. It believes that protecting its customers from unhealthy food is a good thing for its business and for its shareholders. To achieve this goal, MS set up a list of CAs that meet its own standards and distributed it to all of its customers. Were that all it had done, MS would have done nothing wrong.
What happens next is absurd to the point of unimaginable, but please do try to humor me. Upon the release of its latest product, Intestinal Excavator 9 (IE9), MS hires a street gang calling by the name of “Smart Street Filters” (SSF) to perform a very specific task. The SSF’s stand around in front of every eatery that’s open to the public except one – MS’s own restaurant. At McDonalds and Burger King, the SSF’s dress professionally in bright green suits, smile, wave, and encourage customers to enter because they have an EV Certificate hanging on their door. At Jim’s, they wear yellow and speak to everyone who walks out the door after looking in the customer’s bag. They wear a look of concern and caution as they say, “You know, not many people eat that product. In fact, Jim’s isn’t very well known. You should probably throw that burger away immediately and not eat it. It might make you sick.” And over at John Doe’s Burgers, they’re even more menacing.
The SSF gang, dressed in red and wearing big stop signs with the letter X on them, stops everyone who enters John’s store. They harass them, blocking the door, telling them they shouldn’t go in and that John’s food might be poisoned. They eventually let them in if they insist, but not without giving them one last menacing glance. On their way out, the customers are accosted again. SSF gang members grab the customers’ food and tell them they should immediately discard their burgers, even if they were free. SSF claims the food is most likely poisonous, infested with worms, or contain viruses. These actions are performed despite the fact that these same gang members have tested the burgers repeatedly and found no trace of poison, worms, or viruses. They refuse to give the food back to the customers until the customers perform a series of dance steps, the instructions for which are listed in small print on the part of the SSF T-shirts they keep tucked in their pants with only a “look here” note and an arrow directing the way to the instructions situated above the belt.
As a result, most customers won’t eat at Jim’s Burgers and almost none will eat at John Doe’s Burgers, even though the food might be better or less expensive. As the gangs are not acting directly on behalf of the CA’s, they’re not obviously getting sent out by them; however, they do change their colors immediately when someone displays a new EV certificate. After an undisclosed and uncertain amount of customers have ignored them and eaten the burgers anyway, the SSF gang gets bored and wanders off from Jim’s business, but they always stay at John’s twice as long. Even worse, they come back every time either Jim or John introduce a new product, starting their reputation clocks all over again.
When asked about the SSF gang’s activities, MS only had this to say:
“Burgers served with the standard burger serving certificates and even burgers served without certificates continue to build reputation as they have since Burger Reputation was introduced in IE9 last year. However, the presence of an EV burger certificate is a strong indicator that the burger was prepared by an entity that has passed a rigorous reputation validation process and was prepared on a grill which allows our systems to establish reputation for that entity more quickly than for burgers prepared without a certificate or with non-EV certificates.”
In this situation, do you really believe MS isn’t getting paid off by the CA’s? If they are, it’s a violation of the Sherman Act.
Of course, the MS I’m referring to here is Microsoft, and the CA’s are the certificate authorities listed in its Trusted Root Certificate Authority Program. Me? I’m trying to run off the yellow shirts.
April 6, 2013 at 5:03 pm |
Microsoft is not getting paid off by the CA’s. Imagine if you will a world where people write viruses and sneak them onto other people’s computers, and they intercept requests to install applications and replace the files with their own, or piggyback them with their own. Now imagine who gets blamed when that happens on a Windows computer. The person who wrote the virus? No, of course not, Microsoft gets blamed.
Anyone can create a certificate using makecert.exe that comes with the Windows SDK, including the hackers. If you want a Verisign certificate (for example), they check you out and make sure you are a valid business, you have a business license, and you have a presence where you say you have a presence. So if you install a ClickOnce application signed by Verisign, it is guaranteed to be from a company that is valid.
People complain and complain about viruses getting installed on their machines, but every time Microsoft puts in more protection, they complain about that as well. The Smart Screen filter is a warning system, and does not keep the user from running the application if he really wants to. The user can read the screen, click on “More Info” and select “Run Anyway” if he so chooses.
May 2, 2013 at 1:41 pm |
If an end user or a group policy administrator installs the publisher’s certificate into the Trusted Publishers store and the issuing certificate into the Trusted Root certificate store, SmartScreen Filter should not prompt the user for ANY reason, as they have already “clicked” their consent to trust the publisher by having installed those certificates. That is the problem. I’m sorry you couldn’t understand the extended metaphor. If an organization chooses to issue its own code signing certificates for use inside its own organization, and installs those certificates in the Trusted Publishers store on its own computers, what right does Microsoft have to tell the organization that it should not trust the organization’s own in-house developed software?
May 5, 2013 at 11:03 pm |
If you are working for an enterprise and your system support guys are creating their own valid certificates, then yes, that should work. I see that case so rarely, that I assumed you were using a test certificate created in Visual Studio. Sorry about that.
There is a second bit that comes into play, especially if you have a new certificate (or one not known to Microsoft). There is a “reputation” that is determined based on the number of installs for an application signed with a specific certificate. There’s some combination used by Microsoft in their algorithm for deciding whether to display the SSF or not. At some point, enough people will have installed the application to build up the reputation, and the SSF will no longer be displayed. I mention this in the follow-up blog entry after this one.
Robin
March 18, 2013 at 1:24 pm |
Robin, Here is Mricosoft’s page on this.
http://blogs.msdn.com/b/vsnetsetup/archive/2013/01/09/windows-smartscreen-prevented-an-unrecognized-app-from-running-running-this-app-might-put-your-pc-at-risk.aspx
the gotcha is that you need to sign the .EXE in the \obj\ folder not the BIN folder.
March 22, 2013 at 8:23 pm |
I have a click once application and just got our signing certificate. I compiled the code and the executable is signed. I right clicked on the exe and it shows our company name under the digital signatures. However, I am still getting the Windows SmartScreen when I run the application. When I hit more info, it correctly shows our company as the publisher, so that is good. However, it still shows the SmartScreen filter. Am I missing a step? It was mentioned that a reputation needed to be built up before it would go away. What does that mean? Is there a way to register with the SmartScreen filter so it will stop showing up?
April 6, 2013 at 4:44 pm |
Are you using a certificate signed by a trusted certificate authority such as Verisign? Or is it a self-signed certificate? I have had one person report still seeing the smart screen filter even though they have a cert from a CA; I’m working with someone at Microsoft to find out what the deal is and will post a follow blog entry, hopefully this week.
Robin
April 10, 2013 at 7:43 am |
My certificate is from Thawte, which should be a trusted certificate authority.
April 6, 2013 at 4:47 pm |
Make sure you sign the .exe in the \obj\ vs. The bin folder.
Jeff
April 14, 2013 at 10:38 pm |
Yes, that’s in the build commands that I’ve posted.
-Robin
March 29, 2013 at 2:11 pm |
Robin – Great article! This was the gem I was looking for and I now have ‘bark’ free Win8 deployments. You’re recommended solution (#3) also helped me solve an additional problem, how to sign additional assemblies (DLLs) that are included with the deployment.
I added a “AfterBuild” target command to each of the DLL projects to sign them before the main project publishes. Works great!
Thanks again.
April 2, 2013 at 10:22 am |
Glad the article was heopful. BTW, you don’t have to sign your dll’s for ClickOnce. You just have to sign the main executable.
April 2, 2013 at 10:26 am |
You are probably right, but I was finding that anti-virus like Avast barks during the download phase of ClickOnce if the DLLs weren’t signed also. So for good measure, all the assemblies get love and everyone lives happily ever after..(or at least until the next Windows OS)..
Thanks again.
April 14, 2013 at 10:21 pm |
[…] I posted the article titled Windows 8 and Click Once: the definitive answer, it became clear that it was not actually the definitive […]
May 13, 2013 at 12:50 pm |
wonderful blog… saved me a lot of time. Thanks a ton!
May 16, 2013 at 2:49 am |
Great article for signing click once, but I have signed my WPF Application with a code signing certificate from godaddy and it shows it as signed. BUT I still see the smartscreen window. Is there any why how to get this not to show up.
ehm. OT: You may can help me a PE File not found exception I’m getting all 3-5 times I’m publishing the application.
Thanks alot
May 16, 2013 at 4:20 am |
forget the first section. didn’t read the second article
May 16, 2013 at 9:32 am |
Do you get the PF File not found exception when building, when running, or (only) when publishing? If it’s when building, I’d post it to the C# or VB MSDN Forum. If it’s when publishing, I would post it to the MSDN ClickOnce forum.
Robin
June 8, 2013 at 9:49 pm |
[…] IE9 and up (on Windows 7 and reportedly even more so on Windows 8), you may have to bypass Smartscreenfilter warnings like […]
June 14, 2013 at 2:23 am |
Good blog Robin, very informative (regarding Mr Anonymous, he should accept that Microsoft didn’t ‘invent’ the Internet. If it had, then security would be totally different and we probably wouldn’t need certificates at all …)
Perhaps you can help me with my ClickOnce problem ….
A properly signed and authenticated ClickOnce MyApp.exe doesn’t seem to want to create ANY directories beneath Richard>AppData>Local>Apps>2.0 when it is run on the client system (where ‘Richard’ is me logged in as an Administrator). This means that when MyApp.exe runs, it finds its own status is ‘Application is not installed’ and it can’t really do anything.
Can you think of any reason why the client system won’t create any sub-directories beneath Richard>AppData>Local>Apps>2.0 for MyApp.exe to run in?? This is ‘me’ trying to do this and all the Security on my account is exactly as when the account was created in the first place … Very strange
Thanks
November 1, 2013 at 3:33 pm |
Sorry, I missed this. Did you manage to resolve this issue? It sounds like a security issue with the local folders, not a ClickOnce problem.
June 14, 2013 at 3:27 am |
Figured it out … was running MyApp.exe instead of MyApp.application … <= its THIS ONE that does the business!!!
Cheers Robin
p.s. its still a good blog btw !
June 21, 2013 at 6:27 pm |
Congrats on figuring out your problem, and thanks! Glad my blog is helpful to you.
Robin
June 14, 2013 at 10:07 pm |
Hello Robin,
I am in a pickle with this. My ClickOnce application runs fine on XP/Vista/7 but as expected, comes to a halt on Windows 8. There is no way around this issue? I am forced in trying to obtain a certificate for my app, so I can have it signed and work with Windows 8?
I am not a professional developer and I sure can’t afford to spend hundreds on a certificate just so that it works on Windows 8. If there is no other way around, do you recommend any places where I can get a more economical certificate? The cheapest I found was GoDaddy and even then, it’s $200/yr!
June 21, 2013 at 6:32 pm |
I know, right? I have already shared this opinion on the behalf of many to Microsoft. They even closed the hole where you could install your self-created certificate in the certificate store on your customer’s computer to avoid the warning dialog. They did this because it’s ultimately really unsecure, and opens people up to all kinds of malice.
If you don’t want to buy a code signing certificate, just tell your customers to click “more info” and “install anyway”. You can explain why to your customers. The thing about it is, if a project is signed, people know you are a real person and you’ve been validated by VeriSign (or whoever), and you’re probably not a spammer. If your customers know you, or are interested enough in your product, they’ll install it anyway.
Of course, if you’re writing Office apps, you have to buy a certificate, no way around it. It won’t even install.
Robin
June 21, 2013 at 7:06 pm |
Go to sysdev.microsoft.com and sign up and it will give you a link for a $99 code signing cert from VeriSign! Been doing this for 6 years or so….instead of paying $499.
June 21, 2013 at 7:07 pm |
Thanks; I’m sure people will really appreciate that information!
Robin
June 21, 2013 at 7:56 pm |
Here is the actual link.
https://sysdev.microsoft.com/en-US/Hardware/signup/
“VeriSign Code-Signing Certificates for Microsoft Authenticode ($99 USD)”
June 21, 2013 at 7:49 pm |
I would like to make sure my app is properly signed before its first release. For some reason I’m not able to have this problem on my development PC, even though I get the same “Install”/”Don’t Install” prompt.
Question: In the project properties, the Signing tab has a section for “Sign the assembly”. If I check that and provide the same cert used for signing the manifests, is that equivalent to signing the EXE as explained in this article? If not, any tips on how to recreate this issue so I can confirm that following the steps helped?
Thanks.
June 24, 2013 at 12:12 am |
The checkbox in the signing tab for signing the assembly is to create a strong name key and sign it with that; this is not the same thing, and won’t do you any good. Is your dev machine running Windows 8? Is the certificate installed in the cert store? If so, I’d remove it from there before installing the application. Or try installing the app on a different machine.
Robin
July 9, 2013 at 2:19 pm |
Yes, my dev machine is running Windows 8 and I removed the certificate from the store before trying. I will try on another machine, thanks.
July 4, 2013 at 10:59 am |
Has anyone considered what requiring an EV cert, to avoid smart screen, does to a Team Build environment? EV certificates require a hardware USB token which prevents building from a virtual machine. The hardware tokens from Safenet-inc won’t allow signing from a service and also require a password upon signing. The first effect of this is that you can never RDP into the build machine because this runs inside a service and therefore can’t access the EV certificate once accessing the computer from RDP. Additionally, you need to run Team build in interactive mode from the console to sign your code from Team build. When you do a build that signs code you will need to enter a password from the console on the build machine before signing is possible. The build machine must remain logged in to sign code. Our build machine is in a locked room that most developer can’t enter. Did Microsoft really think this through? Couldn’t we have just had VeriSign call Microsoft for instant reputation on our existing certificate? The EV certificate completely destroys a Team build environment and any possibility for continuous integration.
July 29, 2013 at 9:36 pm |
I’ve never heard of ClickOnce supporting this kind of certificate. I’d say since it’s not supported, it’s not a choice I would make for my code signing certifiate if my build machine was in a locked room.
Robin
November 4, 2013 at 11:23 am |
Robin, EV certificates are the only way to establish immediate reputation. EV certificates are supported by signtool.exe and work with mage.exe as my experiments have shown. EV certificates are something your page should talk about. When using click once with a public facing web site, not having immediate reputation will prevent 99.9 percent of windows 8 users from running your application. This make click once technology obsolete for anyone but a LOB software package. For LOB the cert isn’t really an issue because they will use provided workarounds..
July 17, 2013 at 5:09 am |
I am developing windows app for the client.
Client provided me with Comodo certificate for code signing (pfx)
App publishing is done via ClickOnce
After signing the app I still got this messages:
Publisher:
Unknown publisher
Any idea why , and how to fix this ?
thx
July 29, 2013 at 10:01 pm |
Are you installing on Windows 8? Are you getting “unknown publisher” on the executable, or on the first install screen? If it’s on Windows 8, are you signing the executable?
Robin
August 21, 2013 at 9:29 am |
Hello Robin,
I have a Click Once App that run wells on Windows XP. I have just install Windows 8 with IE 10 and am having a little problem. In IE, the .application (Manifest) file is being downloaded and displayed in the View Downloads Form and it says, “do you want to open this file”, then i need to click on the Open button in the Downloads Form, for the application to open. In XP, the application is opened automatically and the View Downloads form is not shown.
August 21, 2013 at 9:39 am |
Note: The clickOnce App is published to a URL (as a website)
September 6, 2013 at 11:14 am |
You need to set the MIME types on the ClickOnce files. IE is not seeing the manifest as a ClickOnce application’s manifest. Check out this article, which lists all of the required MIME types.
Robin
September 28, 2013 at 4:02 pm |
Hello Robin!
I just want to say thank you. This was a really great article and it helped me a lot with my ClickOnce app on Windows 8.
best regards
Ole H. Oftedal
http://www.timeflex.no
October 2, 2013 at 7:53 pm |
Hi Robin
I’m still getting tripped up by the SmartScreen filter, but this time it’s with my prerequisites Setup.exe. Odd, since it’s signed with a valid VeriSign Authenticode certificate.
What do you make of it?
Thanks,
Jeff Bowman
November 1, 2013 at 3:00 pm |
Are you separately signing setup.exe, or are you signing the whole deployment at once? How are you creating setup.exe? Just publishing from VS?
Robin
November 2, 2013 at 12:43 pm |
Hi Robin
> separately signing setup.exe => post-build (method 2).
> publishing from VS => Yes.
It turned out that SSF just needed to get to know me, that’s all.
We’re getting along fine now 🙂
Thanks,
Jeff Bowman
October 3, 2013 at 3:53 pm |
Hi robindotnet…. have you had any experience with ClickOnce applications installed on Windows 8 with uiAccess=true in the app manifest? I’m finding that unless I set key EnableLUA=0 in the registry, I cannot run ClickOnce apps in Windows 8 with uiAccess=true. If I leave EnableLUA=1, I see a “This requested operation requires elevation” error. Thoughts?
November 8, 2013 at 10:11 pm |
Thank you very much for this article. It really helped me.
November 18, 2013 at 8:49 am |
You said:
“This is strongly advised against, as installing the certificate on the user’s machine introduces a significant security risk.”
What kind of risk? For who?
Tks.
February 21, 2014 at 3:08 pm |
For you. If anyone gets the certificate, they can sign their own deployments with it. Since the customer has the certificate installed on his machine, he will install anything signed with that certificate, which could be malware from another source, and you will be blamed because it was originally your certificate.
November 27, 2013 at 10:26 am |
Hi Robin:
Great blog!
I’ve been trying to deploy a VSTO office customization using ClickOnce in VS2013. However, I am consistently getting the error you show above: Customized functionality in this app will not work because the certificate or it’s location is not trusted…
I am publishing from visual studio and trying to deploy to my website by just copying the published files. I configured signing the files using a Verisign Authenticode Code Signing Cert under the “Sign the ClickOnce manifests”. And I tried the BeforePublish method you mention above. I’ve also tried signing using mage.exe on the .dll.manifest and .vsto in the version folder and then on .vsto in the publish root. But nothing seems to resolve the error.
I was under the impression that with the Verisign Code Signing Cert I wouldn’t have to add my site to the user’s trusted sites list in IE to allow the install.
Am I missing something?
Thanks!
Steve Cotter
February 21, 2014 at 2:58 pm |
You don’t need to separately sign the deployment manifest with a VSTO application, so take that back out. The windows 8 “sign the exe” issue doesn’t apply to VSTO applications. Be sure that you are setting the installation URL correctly to the folder or URL where you are copying the files to. Please post back the whole error message and exactly where you’re seeing it.
December 18, 2013 at 1:35 pm |
I am following these steps, but I am getting a error message when installing the application. The error is MyApp.exe, has a different computer hash than specified in manifest.
I assume this is because this changed the .exe. How can I make the hash’s the same?
I see Phillip Bred address this problem with the following solution below, but I am not sure how to take the steps he mentioned after step one. This also sounds like a manually process. I would like to automate it.
1. Sign exe file.
2. Create application manifest.
3. Rename files .deploy.
4. Resign application manifest
4. Create deployment manifest, with link to application manifest.
5. Sign deployment manifest.
February 21, 2014 at 3:05 pm |
“Different computed hash” means that some files are signed at one point, others are signed at another point. After changing the exe, you have to re-sign the manifests. Or you have to sign the exe file before the manifests are created.
February 23, 2014 at 9:05 pm |
Hi Robin,
Thanks for the very helpful post.
I recommend adding /t http://timestamp.verisign.com/scripts/timstamp.dll. This will timestamp your digital signature.
If you don’t do this, then when your code signing certificate expires you might find that your application silently becomes broken again, and this will probably happen on a Friday evening right before your vacation.
March 9, 2014 at 11:10 am |
Thanks Daniel, that’s very helpful.
Robin
April 14, 2014 at 8:31 am |
Robin,
Nice article, which I’ve found an enormous help.
On the relative paths issue, I ended up writing a batch script which I placed in my project directory (I needed to sign and timestamp several other project outputs to include in the publish, so I needed to refer to “..\MyOtherProject”). You can construct the msbuild strings and pass them to the batch script as arguments and then they’ll be properly resolved, eg:
I’m sure this could be adapted for your own example too, eg:
and in the script (if you’ve got the path to signtool.exe included in your system path, although you can use relative paths in the batch file as well):
@echo off
signtool sign /f %1 /p %2 %3
signtool timestamp /pa /v %3
April 14, 2014 at 10:44 am |
Thanks for the info, I’m sure that will be helpful to people!
Robin
April 14, 2014 at 10:50 am |
oops, forgot to escape those < and > tag ends…
the tag contents in the first eg was:
Exec Command=”$(ProjectDir)signdll.bat ..\MyOtherProject\bin\$(ConfigurationName)\MyOtherProject.dll
and in the second, it was:
Exec Command=”$(ProjectDir)sign.bat my.pfk mypasswd "$(ProjectDir)obj\$(ConfigurationName)\$(TargetFileName)"”
April 14, 2014 at 10:51 am |
Details, details, details… 😉
January 27, 2016 at 6:43 am |
Super article:-) I used it a lot when debugging/trying to figure out what was wrong.
*** This is for those who try to sign after 1.1.2016. This is the first important step: ***
If you sign code or ClickOnce publication after 31.12.2015 with a certificate based on the Sha1 algorithm you will get this problem.
You must buy a new certificate for this to work. When you buy a new certificate you automaticly get the new Sha256 based certificate.
This is a shift for the whole SW industry and you can read more about i here:
Kind regards
Ole Henrik Oftedal
Timeflex Systemer AS
Norway
http://www.timeflex.com
http://www.timeflex.no
May 1, 2016 at 12:04 pm |
Thanks for sharing this information!
Robin
February 10, 2016 at 11:53 am |
Hi,
I noticed visual studio contains a “Sign the assembly” option on the signing tab of the project properties. Is this something new? Does it replace the post-publish, post-build and post and pre-publish command lines?
Thank you,
May 1, 2016 at 12:02 pm |
Yes. Visual Studio will now take care of signing the exe file for you. You no longer need the post-build, etc., commands.
April 11, 2016 at 1:25 pm |
Robin, just worked with MS and in VS 2015 Update 2, their is no need to worry about the post-Build option as VS now signs the \obj\xxxx.exe for us!!! Finally!!!
April 14, 2016 at 12:40 am |
@Jeff Pigott,
Could you expand a bit on VS 2015 update 2 signing? Are you saying that if you simply tick the “Sign the assembly” box (and select the pfx file) under the project Signing tab that VS is now signing the assembly?
April 18, 2016 at 10:57 am |
Fantastic! Solved a long standing problem with that costly Smartscreen warning. Thanks for the article.
June 21, 2018 at 4:55 am |
We have a unsigned click once application and is installed on user machines. Now we have decided to sign this application and we are able to do it successfully, but somehow we are able to see 2 applications in control panel, say APP and APP-1. And I am not able to track the reason behind it? Or is it the default behavior?
June 22, 2018 at 12:23 pm |
The certificate used to sign the application is part of the identity of the application. So regardless of the rest of the settings, adding a certificate gave this a different identity, and when the users go to install it, it will show up as a second app. All you can do is uninstall both applications and install the right one.
June 26, 2018 at 1:46 am |
Thanks for your reply
July 10, 2018 at 5:48 am |
one more thing related to blue screen smart filter, I have already signed the exe and I am able to see the publisher with my company in dialog, but why I am still seeing this error? Is the certificate installation also mandatory.
June 22, 2018 at 12:36 pm |
Hi Robin, been a long time! We found issues with SmartScreen clickonce with Windows 10 with versions 1803.1 and any other version up to version 1803.81 and on ClickOnce issues are resolved. Just a FYI.
June 22, 2018 at 12:44 pm |
Hi Jeff! It has been a long time. I see comments and questions come through and try to help people. I work for Microsoft now, and have tracked down the PM for ClickOnce. They’re probably quaking in their boots…
Do you mean W10 versions 1803.1 and 1803.81? But now it’s okay again? Feel free to e-mail me directly at robin dot shahan at Microsoft dot com if you have further problems.
June 22, 2018 at 12:51 pm |
yes in the first release of 1803.1 or .48 broke our clickonce deployments with new certificates from this year. after 1803.81 or 1803.83 (applying windows updates) or downloading the right KB http://www.catalog.update.microsoft.com/Search.aspx?q=KB4338548 fixed the issue.