none
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

    Tuesday, September 09, 2008 5:12 AM

Answers

  •  

    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}", pkIdea);

     

    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

    Thursday, October 16, 2008 5:25 PM

All replies

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

     

    Wednesday, September 10, 2008 4:25 PM
  •  

    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

     

     

     

     

     

    Wednesday, September 10, 2008 11:23 PM
  • 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

     

    Monday, September 15, 2008 11:24 AM
  • 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

    Tuesday, September 16, 2008 7:41 AM
  • 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.

    Tuesday, September 16, 2008 4:28 PM
  • Yes, I would be more than happy to do that. Saurabh has my e-mail information.

     

    RobinS.

    GoldMail.com

     

    Tuesday, September 16, 2008 4:42 PM
  •  

    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.
    Wednesday, October 15, 2008 5:54 PM
  •  

    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}", pkIdea);

     

    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

    Thursday, October 16, 2008 5:25 PM
  • 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.

    Thursday, October 23, 2008 5:44 PM
  •  

    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

     

    Friday, October 31, 2008 3:46 AM
  • 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?
    Friday, May 29, 2009 8:25 PM
  • 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....

    • Edited by Lavagin Monday, June 01, 2009 6:36 PM
    Monday, June 01, 2009 5:50 PM
  • 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

    Wednesday, June 10, 2009 4:11 PM
  • 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.
    Tuesday, June 16, 2009 4:39 PM
  • 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!
    Saturday, June 20, 2009 10:48 PM
  • 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!
    Saturday, June 20, 2009 10:51 PM
  • 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 :).
    Sunday, June 21, 2009 6:39 AM
  • 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.

    Monday, June 22, 2009 1:00 AM
  • 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!
    Thursday, July 09, 2009 2:10 AM
  • 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!
    Thursday, July 09, 2009 2:17 AM
  • I have encountered this issue with VS2008 and .Net 3.5.  When this first happened I created a new certificate, created a CD deployment and tried to update an existing Vista installation.  The installation did not update, instead a new installation was created.  What could I have done wrong?
    Monday, May 10, 2010 4:32 PM
  • Does your application target .NET 3.5 SP-1 or .NET 3.5?

    RobinDotNet


    Click here to visit my ClickOnce blog!
    Microsoft MVP, Client App Dev
    Tuesday, May 11, 2010 12:14 AM
  • .Net 3.5
    Tuesday, May 11, 2010 1:19 PM
  • Changing the target to .Net 3.5 SP-1 does not work either.  I still get a new installation i.e., myprogram - 1
    Tuesday, May 11, 2010 1:29 PM
  • This happens when it sees the second installation as a separate application. My guess is it has something to do with being deployed from a CD and the deployment url. What is the publishing path, and if you are deploying from CD, has the drive letter of the CD drive changed?

    RobinDotNet


    Click here to visit my ClickOnce blog!
    Microsoft MVP, Client App Dev
    • Proposed as answer by randywheeler Thursday, May 13, 2010 1:40 PM
    Thursday, May 13, 2010 7:43 AM
  • You are correct.  I was afraid to publish with the new certificate not knowing what to expect.  Once I took the chance everything worked fine.  Thank you for your time.
    Thursday, May 13, 2010 1:42 PM
  • Great. Glad it worked for you!

    RobinDotNet


    Click here to visit my ClickOnce blog!
    Microsoft MVP, Client App Dev
    Thursday, May 13, 2010 5:22 PM
  • Hi All,

    Where would I find out exactly what changed in .Net 3.5 SP1 to make this work?  Has the logic to verify the ClickOnce identity changed?  What is the actual logic ClickOnce is using to determine the deployment manifest is still the same one, even though I've signed it with a new certificate?

    What further fixes are there exactly in .Net 4 in relation to this certificate expiration issue?

    I've searched for a while online but couldn't find anything that details exactly how to fix in 3.5 SP1 works, any pointers?  If I can just resign with any certificate, wouldn't it make it venureable for somebody with a DNS spoof to point the client to update to a different application?

     

    Thanks.

     

    Tuesday, April 26, 2011 10:28 PM
  • There are several fields that make up the identity of an application, one being the deployment provider URL. If your application is currently a running application and you run it, and it checks for updates at the deployment provider URL and finds one that agrees on the other fields as well, it doesn't count a changed certificate against you.

    For .NET 4, they fixed the problem in the case of VSTO applications and when doing programmatic updates.

    It probably would make it vulnerable. I'll ask the C/O guys at MSFT for a response on that question.

    RobinDotNet


    Click here to visit my ClickOnce blog!
    Microsoft MVP, Client App Dev
    Thursday, May 05, 2011 6:15 AM