VS2008 SP-1 change certificate, user can't pick up update

Question

I have been testing the update of our signing certificate.

 

I deployed the application with the current certificate (not yet expired).

I had a handful of users install it. They do not have any prior versions installed.

I changed the application to be signed with the new certificate (Signing tab) and redeployed it. That is all I changed.

The handful of users ran the application to pick up the new version.

Two of the users had the error below and were unable to upgrade.

They can successfully remove the prior version and install the new version.

 

We are using VS2008 SP-1, deploying via http. The user below is running Windows Vista. This is going to be a huge problem for us if we have to have all of our users uninstall and reinstall the application.

 

Error Log:

 

PLATFORM VERSION INFO
 Windows    : 6.0.6000.0 (Win32NT)
 Common Language Runtime  : 2.0.50727.312
 System.Deployment.dll   : 2.0.50727.312 (rtmLHS.050727-3100)
 mscorwks.dll    : 2.0.50727.312 (rtmLHS.050727-3100)
 dfdll.dll    : 2.0.50727.312 (rtmLHS.050727-3100)
 dfshim.dll    : 2.0.50727.312 (rtmLHS.050727-3100)

SOURCES
 Deployment url   : file:///C:/Users/Kathryn%20Leuenberger/AppData/Roaming/Microsoft/Windows/Start%20Menu/Programs/GoldMail,%20Inc/GoldMail.appref-ms
      Server  : Microsoft-IIS/6.0
      X-Powered-By : ASP.NET
 Deployment Provider url  : http://web01.gldmail.com/gmstudio/GMStudio.application

ERROR SUMMARY
 Below is a summary of the errors, details of these errors are listed later in the log.
 * Activation of C:\Users\Kathryn Leuenberger\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\GoldMail, Inc\GoldMail.appref-ms resulted in exception. Following failure messages were detected:
  + The deployment identity does not match the subscription.

COMPONENT STORE TRANSACTION FAILURE SUMMARY
 No transaction error was detected.

WARNINGS
 There were no warnings during this operation.

OPERATION PROGRESS STATUS
 * [8/29/2008 3:52:03 PM] : Activation of C:\Users\Kathryn Leuenberger\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\GoldMail, Inc\GoldMail.appref-ms has started.
 * [8/29/2008 3:52:03 PM] : Performing necessary update check as specified by the deployment.

ERROR DETAILS
 Following errors were detected during this operation.
 * [8/29/2008 3:52:03 PM] System.Deployment.Application.DeploymentException (SubscriptionState)
  - The deployment identity does not match the subscription.
  - Source: System.Deployment
  - Stack trace:
   at System.Deployment.Application.SubscriptionStore.CheckUpdateInManifest(SubscriptionState subState, AssemblyManifest deployment, Version currentVersion)
   at System.Deployment.Application.ApplicationActivator.PerformDeploymentUpdate(SubscriptionState subState)
   at System.Deployment.Application.ApplicationActivator.ProcessOrFollowShortcut(String shortcutFile, TempFile& deployFile)
   at System.Deployment.Application.ApplicationActivator.PerformDeploymentActivation(Uri activationUri, Boolean isShortcut)
   at System.Deployment.Application.ApplicationActivator.ActivateDeploymentWorker(Object state)

COMPONENT STORE TRANSACTION DETAILS
 No transaction information is available.

 

I thought they fixed this problem with VS2008. If anyone has any ideas on what I can do to troubleshoot or fix this problem, I would greatly appreciate it.

 

RobinDotNet

GoldMail.com

Answer 1

hi Robin,

 

i hope Beth was able to point you in the right direction.  i'll summarize the information here, so that other users can access it later.

 

the ClickOnce expiration problem was fixed in .NET FX 2.0 SP1 and .NET FX 3.5.  your development computer has VS2008 and .NET FX 3.5, so the ClickOnce certificate problem wouldn't appear there.  however, if end user computers have an older version of the .NET FX, they would have to uninstall and reinstall your app.

 

unfortunately, ClickOnce updates don't bootstrap the .NET Framework.  the .NET Framework would need to be installed via Windows Update, pushed out via SMS, or some other method.  there are some guidelines about .NET Framework deployment at .NET Framework 3.5 Deployment Guide for Application Developers and .NET Framework 3.5 Deployment Guide for Administrators.

 

m.

 

Answer 2

 

Actually, this isn't exactly right. So after moderating in this forum for the last few months, and continuously telling people that using VS2008 fixes the certificate problem, let me be exactly specific about what it fixes, because that is incorrect.

 

If you are doing manual updates (programmatic), your users will have to deinstall and reinstall. Period.

 

If your users have .Net 2.0.50727.1434 or higher installed, they will have no problem when you update the certificate. To be running this version, they are running XP with .Net 2.0 SP-1 installed, OR they are running Windows Vista with .Net 3.5 installed.

 

If your users are running Windows Vista without .Net 3.5 installed, your users will most likely have to uninstall and reinstall your application when you change the certificate.

 

The reason for this is that Windows Vista ships with a version of .Net 2.0 that is prior to .Net 2.0 SP-1 being released, or at least, that's what I presume, since none of the Windows Vista machines I am looking at have .Net 2.0 SP-1 installed. I also built a new Vista virtual machine to verify this.

 

They imbedded .Net 2.0 SP-1 in the .Net 3.5 installation. This is why users running .Net 3.5 have no problem.

 

Therefore, a computer running Windows Vista that does not have the .Net 3.5 Framework installed will have the original version of .Net 2.0 on it (version number 2.0.50727.312), and the update won't work when the certificate is changed.

 

The only way to get that update to work is to push .Net 3.5 as a prerequisite. However, if you change the prerequisite, your user has to uninstall and reinstall anyway to pick up the new prerequisite, so the whole certificate problem is a non-issue.

 

Note: I found the version number by going to C:\Windows\Microsoft.Net\Framework\v2.0.50727\mscorlib.dll and checking the property to get the version.

 

For my company, suddenly changing to push .Net 3.5 as a prerequisite it a non-starter. All of our users have .Net 2.0, which is what we target. Our preliminary testing shows it takes 30 minutes or more to install .Net 3.5, and as has been noted in this forum, the progress bar doesn't move for quite a long time during that. The performance of that is unacceptable, especially when doing it just to fix a certificate problem.

 

I have to say, this is very disappointing, as I thought this issue had been resolved. Oh, and in case you're wondering why we don't just install .Net 2.0 SP-1 on our Vista machines -- you can't. The download for that specifically does not work for Windows Vista. It's 3.5 or nothing.

 

I hope this information helps someone else, and clarifies the problem with the certificates.

 

RobinDotNet

GoldMail.com

 

 

 

 

 

Answer 3

Hi RobinDotNet

 

First, I think I can understand what you are feeling now for this problem. I’m sorry for that.

 

Second, I really appreciate that you post this problem and precious information here for discussion.

 

However, to be honestly speaking, I think many people here in ClickOnce & Deployment Forum have not as much experience as you, and probably cannot provide professional ideas for this problem. So, maybe you can consider reporting this problem in Microsoft Connect for Visual Studio, see what engineers say there. You know what Microsoft Connect is used for, right?

 

Based on my experience, I think we can change this thread into comment, can we?

But if you do not think so, please do not hesitate to change it back to question, and we’ll try our best to follow it.

 

Again, really thank for your information for this issue.

Thanks.

 

Best wishes

Jun Wang

 

Answer 4

I am actually working with someone on the ClickOnce team to see if we can come up with another solution. I am also still trying to come up with a workaround. If I find anything that could help someone else in the same predicament, I will post it.

 

Putting it in Connect is a good idea; I will post it there as well, and put the link back in here. Feel free to change this to Comment, I will flip it back if I get a resolution. I have also made this thread sticky, because this question comes up A LOT in this forum, and this is a definitive answer.

 

Thanks,
RobinS.

GoldMail.com

Answer 5

hi Robin,

 

i'm the current writer for the ClickOnce documentation, so i work with Saurabh on getting the correct information in the MSDN Library.  right now, it looks like you have more information than me.  if you don't mind, i'd like to include you in the doc review to make sure that this information is clear and discoverable.

 

m.

Answer 6

Yes, I would be more than happy to do that. Saurabh has my e-mail information.

 

RobinS.

GoldMail.com

 

Answer 7

 

Also note that uninstall-reinstall will result in data loss as opposed to updating through url (URL to deployment manifest). So the best workaround would be to direct users to the deployment on the server in order to get the update.

Answer 8

 

It depends on how you handle your data in the ClickOnce world. We don't keep it in the same folders as the ClickOnce deployment. We create a folder under the LocalApplicationData (it's a SpecialFolder) and keep it there. Thus, when the users uninstall and reinstall, the cached data is still available.Sure, it also leaves it behind if they deinstall and stop using our product, but that's a small price to pay for retaining it when we need to.

 

Also, here is my solution to this whole issue. There was no way to get around the uninstall/reinstall, unless we have all of our users install the .Net 3.5 (SP1) framework, and we were not willing to do that, because it's so huge. Plus, you know you'll have one guy who won't do it, and the application will fail on him, and he'll be the most important customer. And if you have to push .Net 3.5 as a prerequisite, then you're having them reinstall anyway, so what's the point?

 

1) Deploy the new version of the application to a new URL with the new certificate.

 

2) Create a test certificate with the same key as the (expired) Verisign certificate. I used renewcert -- not the one in MSDN, because it doesn't work, but the one here: http://may.be/renewcert

 

This worked fine on one of my machines. On the other, it gave some error in the application event log about some C++ thing missing, so although I have VS2008 installed, I pulled the C++ redistributable from Microsoft.com and installed it, and it seemed to fix the problem.

 

3) Change the old version of the application to do this at startup:

 

    a) Show a dialog box telling the user what is about to happen.

    b) Uninstall itself.

    c) Fire off a process to install the new version.

    d) Exit the application.

 

The uninstall code example came from here: http://www.jamesharte.com/blog/?p=11

 

One thing to note. In the comments at the bottom, there is a bug fix:

 

Tthe format string for getting the PublicKeyToken has a bug if there’s a 0 in the token.

It will drop the 0 if it’s the first part of the byte. This code will fix it:

 

Code Snippet

 String.Format("{0:x2}", pk);

 

which means this line of code in the GetPublicKeyToken method:

       

Code Snippet

pkt.Append(String.Format("{0:x}", pk[i]));

 

should be this:

 

Code Snippet

pkt.Append(String.Format("{0:x2}", pk[i]));

 

 

4) Sign the old version with the test certificate you created with the same key using RenewCert and deploy it. This must be a required update (set minimum version).

 

So what happens is the user runs the application, it picks up the update, it uninstalls itself, and invokes the installation of the new version.

 

This worked great for us. The uninstall code includes code to click the OK button programmatically. The update that does the uninstall must be a forced update so the uninstall dialog only comes up with "do you want to uninstall this" rather than giving the user the option to roll back a version.

 

Our dialog box advised the user not to hit the OK button (it stops the app, and doesn't fire the install).

 

I hope this helps someone else. Post back if you have any questions or problems, and I'll try to help you.

 

RobinS.

GoldMail.com

Answer 9

Please allow me to attempt to clarify this statement: "If you are doing manual updates (programmatic), your users will have to deinstall and reinstall. Period."

 

I got burned by an expired certificate last year using VS2005, ClickOnce, and the 2.0 Framework. I had to have several hundred users uninstall and reinstall my application in order for it to work again.

 

To avoid this issue in the future, I upgraded the application to the 3.5 framework and started developing in VS2008 thinking all my issues would be gone.

 

30 days before my certificate was scheduled to expire, I got a new certificate. When I re-signed my code with the new certificate and published it to the usual location, the existing clients did not recognize that an update was available.

 

In VS2005, you could not even go to the original deployment URL and reinstall. You needed to uninstall and reinstall.

 

In VS2008, however, you can go to original deployment URL and install without error.

 

That is an improvement but the failure for ClickOnce to recognize the availability of the update is just as problematic. I now need to notify all of my customers that they need to reinstall the application from the URL.

 

I would love to be proven wrong on this so if anyone has any insight, I'd appreciate it greatly.

Answer 10

 

In my testing for this issue, I did not find this to be true. If your users have .Net 3.5 installed and you are using VS2008, you should be able to change the certificate and they should pick up the update. You are changing the version number, right?

 

They should not need to go back to the url to install. It should look for updates when they run the application.

 

RobinS.

GoldMail.com

 

Answer 11

I am having this problem.  My development machine is a Vista Ultimate machine with 3.5 SP1 and I am using VS 2008.  I am having the exact same problems people were having 3 years ago.  I thought they had this fixed in 2008?

Answer 12

I am still having alot of problems with this.  My development machine is Vista and I am using VS 2008 with 3.5 SP1.  I tried the above suggestions on how to fix this and it still won't work.  I even created a totally new project and placed the source code in it from the old source code and tried to redeploy it like that and I still get that certificate message from my users and on also on my development machine.

Why wasn't I able to redeploy it when I made new solution?????

When I push the button  Create A New Test Certificate and put a password in it....does the password still need to be the same as with the original project?  How would it know?



Nevermind...I figured it out.  But talk about a pain in the neck....

Answer 13

This is a JOKE!!  Right?!  The ENTIRE purpose of ClickOnce applications is for "EASY" centralized deployment with "SEAMLESS" updating!!!! 

I too got the (under VS 2008 SP1 and .NET 3.5 SP1):

Error 20 An error occurred while signing: Failed to sign bin\Debug\app.publish\\setup.exe. SignTool Error: ISignedCode::Sign returned error: 0x80880253

 The signer's certificate is not valid for signing.

SignTool Error: An error occurred while attempting to sign: bin\Debug\app.publish\\setup.exe DOMICO Reports Manager

So I look at the certificate and sure enough it expired about 5/30/09.  So if I use "Create Test Certificate..." this will allow me to publish my ClickOnce app, but will basically screw all my existing customers/clients and generate a TON of support calls to help them "resolve" this MAJOR problem with ClickOnce and certificates!!!

This isn't even funny any more.  I'm disgusted with Microsoft.  I'm serious disgusted -- this is beyond incompetence.

Rob

Answer 14

Robin,

I tried this, and it was working fine.  but my problem is i had to push .net framework 3.5 along with this release as prerequisites, but when my applicaiton uninstalls and points to the new application.application  url it gives an error saying it needs windowsbase 3.0.0.0 installed in GAC, this is caused because of  yourapp.application file doesnt execute the setup.exe even though its a new installation. but when we call the setup.exe URL it prompts for the the .net framework installation too.

isnt there any solution for this, may be check the .net framework in the client machine, and then decide the URL whether its pointing to setup.exe or the application manifest.

Answer 15

You sound really frustrated; apparently you did not read closely enough. I explain in my posts above how to create an extension of a current certificate in order to keep the ability to perform application updates. This is also explained in my blog, and the source code and article are available as a download here:

http://robindotnet.wordpress.com/2009/03/30/clickonce-and-expiring-certificates/

However, if you are deploying an application using VS2008 and targeting .Net 3.5, you don't even have to do this. All you have to do is replace the certificate with a new one and redeploy. Your clients will have no problem at all. This is also explained in my posts up above.

So you're basically complaining about something you don't have to do, since you say you are targeting .Net 3.5 and using VS2008. All you have to do is create a new certificate, re-sign the deployment, and you're golden. What do you expect Microsoft to do when a certificate expires? If you have deployed your application with a Verisign certificate, for example, do you expect them to let you deploy a new version and sign it with an expired certificate? That removes the security that a certificate provides to the users to let them know that it is a valid deployment.

RobinDotNet

---

Click here to visit my ClickOnce blog!

Answer 16

If you are changing the Framework you are deploying, you can have your users run your setup.exe again to install the new framework before picking up the update. Or you can use the code described above to programmatically uninstall the user's application and reinstall it, invoking the setup.exe to install the new version of the .Net Framework if needed.

You could have your application update the .Net Framework, but you can't know when all of your users are running the new version so you know you can change the target of your application to the new version.

RobinDotNet

---

Click here to visit my ClickOnce blog!

Answer 17

If you are changing the Framework you are deploying, you can have your users run your setup.exe again to install the new framework before picking up the update. Or you can use the code described above to programmatically uninstall the user's application and reinstall it, invoking the setup.exe to install the new version of the .Net Framework if needed.

You could have your application update the .Net Framework, but you can't know when all of your users are running the new version so you know you can change the target of your application to the new version.

RobinDotNet

---

Click here to visit my ClickOnce blog!

Robin,

Thanks for your reply. i cannot tell the users to run the setup.exe,as you know  most of them are not aware of how things work. so all i did is , used the above method u mentioned to uninstall and re install the applicaiton.

just a small update on the Deploymentutils class in the getUninstallString() method , i had to do the following changes:

if(uninstallString.Contains(searchString)) break; 

 

to this:

if(uninstallString.Contains(searchString)
               && uninstallString.Contains("yourApp.application"))
                    break;

1.  
   1.  

       

       

because we use a single certificate to sign all our applications, and if we just check only for uninstall string, it might detect and uninstall another application with same public token key. and thanks again for the great work :).

Answer 18

Robin,

Couple issues and hence why Microsoft still "don't get it".

A certificate is nothing more than paying someone else to validate my company - it does NOT guarantee my company is "safe", it does NOT guarantee my company will not legally screw unsuspecting users, it does not guarantee a company is going to fill your Hard drive with useless advertisements, -- a certificate is no more than a Mafia run outfit (sanctioned by yet another Mafia run governing body) where company A says pay me $1200/yr and I'll say your a "good guy" and get you on the good guy list.  But ONLY Microsoft could introduce a very lame, unregulated, and inefficient system such as certificates to both developers and end users (most of whomd don't care, and don't know WTF a certificate is nor why they need to know).

Assuming every company/developer is bad or going to be quilty of wrong doing is a road that leads to paranoia -- this is not a good thing.  It's like Microsoft are just not believing the real world and continue on in some lala land/world of their own -- a world that is slowly coming apart as Microsoft are being hit financially and their products and OS is being rejected.  Anyway, that's a topic for another day.

So, now we have Microsoft Click Once Applications, default settings of Microsoft Browser to warn people that applications are "deemed" unsafe because they have not paid the Mafia fees (errr, some organization who does nothing to really validate a good vs. bad company) -- wooohooo, just think of all the jobs this must be creating while further reducing the public (end user) popluation - the very ones they need to survive.

Anyway, the only way to fix this problem was to have the end user install SP1 for .NET 3.5 OR uninstall existing app and re-install, pay $1200/yr for a coding certificate, republish clickonce solution.  My original application was .NET 2.0 based -- I upgraded my application it to .NET 3.5 and tried to publish it.  So yes, this IS very much a BIG problem for my company and defeats the entire purpose of what ClickOnce deployment is supposed to be about.  Great job Microsoft!!

Rob.

Answer 19

Thanks. I have written an article and placed it on my blog; I'll update it with this information. :-)

RobinDotNet

---

Click here to visit my ClickOnce blog!

Answer 20

Hi, Rob,

I understand your frustration. I feel that there is so much spam and identity theft and malicious viruses out there that having a certificate to assure your user that the application comes from you is worth the price.

If you don't want to pay for a certificate, if you work in a corporate environment, the network support people who support the web servers can create an enterprise certificate that will accomplish the same purpose.

Another option is to install your created certificate (and my article above explains how to make one that lasts 10 years, so have a field day) on the user's computer. If you do that, it will recognize you as the publisher, and won't mark you as unknown.

I agree that this problem with changing certificates is a huge problem with ClickOnce, and it could have been alleviated by Microsoft issuing a Windows Update that installed SP-1 for .Net 2.0 on Windows Vista. I must admit that I feel they don't always understand that not everybody can update to the newest version of everything just because it's available (an 80MB  download!?). However, they are not pushing .Net 3.5 SP-1 as a critical Windows Update to every machine that has any version of .Net on it, which takes care of this problem, assuming the user is installing Windows Updates.

RobinDotNet

---

Click here to visit my ClickOnce blog!