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
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