!!!HELP!!! Publishing a Clickonce application after certificate renewal.
I recently renewed my certificate through thawte and found out after signing our clickonce application that clickonce does not play well with the renewed certificate. The problem seems to be that during the process of renewal, thawte and apparently others require a new private key to be generated for the renewed certificate. So it seems there is a critical flaw in the ClickOnce architecture if it requires your code to be signed but can't handle the industry standard of renewed certificates. The only other option is to be your own certification authority but that requires distributing your CA certificate before clients install your application.
If we have to have our clients uninstall our software and reinstall it because of this, then this is a complete disaster and ClickOnce is useless...
Is there anyway on Earth to solve this problem without resorting to dumping ClickOnce all together?
Thanks,
-Jim Cline
I entered a bug on this in the MS Connections Feedback system. However, I need something I can take to thawte to try to convince them to use our previous key.
Is there anyone that has any answers even if it is to confirm what I have said?
I have not been able to find any solution to this problem. I have seen that others have ran into this problem as well. Has anyone any information about this or is the only course of action to continue with an expired certificate or having our clients uninstall/reinstall?
Good luck. If you have to do an uninstall you best hope the half ... uninstall works that comes with ClickOnce. From what I see it only remove the entry in control panel and start menu. But leaves the program in the Local Setting/app folder and many registry entries. Otherwise you will need to manually remove all references from the HD and Registry.
IMHOP MS has gone overboard on security which is not bad it is a very good thing. But those of us who are trying to do legitimate stuff have our hands tied. All changes are treated as a hacker intrusion and change certificates, signing, etc. There is no documentation on what is going on in the background during an install or how to remove the application completely.
I did something as simple as an upgrade and one client would not because it was looking for some older version. Or there was some hash code mismatch. The only fix was to completely remove (HD/Regedit) and make sure there where no references to an older version to compare certificates, hash codes, or versions. Also did a direct link to the application file and bypass the web page in case of cache issues? BTW is there any real world documentation or Use Case results: How to change ClickOnce certificate? How to resign code with change strong naming certificate? Or have these use cases never being done in the real world until now? What if my third party objects change along with signing
We have experienced uninstalls not completely removing all files as well as corrupted ClickOnce app stores which required all ClickOnce applications to be removed and reinstalled. ClickOnce has become a disturbing burden for our support team. IMHO, ClickOnce is not ready for real world use. We invested two quarters of development to use ClickOnce to deploy our Enterprise level application and now are *more* than seriously considering writing our own deployment technology.
Major problems with ClickOnce after having suffered with since before VS 2005 Release...
- Too intolerant of connection problems
- Not enough isolation from other ClickOnce applications in the App store
- Insufficient API's to allow robust customization of deplyoments
- Manifests do not allow robust organization of optional file groups (e.g. same file belongs to many groups)
- Performance is slow with a large number of assemblies
- Too many corruptions in the app store which causes re-install of all ClickOnce apps.
Not to mention the very obvious reason for this thread. I am very unhappy that our customers are going to affected by this certificate issue.
The concept is great but I feel like ClickOnce in its current form is nothing more than a way to deliver throw away utilities. Using it to deploy real world applications that will need long term updates is not an option it seems.
I am recommending to our managment team that we begin developing our own deployment technology and dumping ClickOnce. I have learned a lot about deploying apps and now know what not to do...
Jim
. . . and what not to do!
It is not to say that MS won't get it right but man how much real world testing was done? I'm just some small computer guy with about 5 users and ran into many problem hate to have hundreds of users. Both large scale application and mid range applications, with many types of updates from coding change to certificate changes. With as many as hundreds of user with many types of clients (including Terminal Service and Citrix). I mean to run into so many issues that are so easy to cause and with so many of them I don't see how they got this out the door other than to work with Hello World apps and only update one to two clients.
ClickOnce is like walking through a land mine and if you make it to the other side what an accomplished (but now there are 99 other clients to go). But if what you are doing does not follow the correct guide lines (if there are any documented) than kabooom. Uninstall manually and start all over.
BTW are these complaints the norm or the exception? Is there any success story where someone has done many of these changes with out problems and deployment into the hundreds if not thousands of users?
If so I will stop.
na I'll stop anyway I got bigger fish to fry like a deployment strategy that works or go back to a gui with little or no user experience aka web applications.
Well, my company fits into the worst case situation you just described 
We have a few hundred end users that have our application installed, deployed from several deployment servers with possible multiple version of the same software needing to run on the machine at once....
Probably worst case scenario for this technology....but if you look at it in a narrow scope, our application on a typical user's machine should not be any different than a hello world application, just a very large one...I suspect that the troubles we have with corrupted App stores is mainly due to ClickOnce not being very tolerant of slow connections...
....
-Jim
Well what ever the problem is... if there is a problem that is the problem no matter what it is. Why, becuase trying to solve an issue relating to the App store and/or clients not being able to get an update for what ever reason. Then to only find out an unistall is not what it is supposed to be.
Then to get MS to respond either way with any of the questions I have posted or you have post go unanswer?
Which to me is even more scary because this is now going out into the real world all messed up for some customers. We have problems to which there are no solutions, no document but brutte force hacking. These problems also seem to stem from average day to day task that screw something up and might have been seen during testing? And yet no support answers or comments from the creators of the great technology. So if you step back and look at it as a whole the question becomes clear as to what the real problem is? And your solution of creating your own might be the best solution yet a big undertaking.
At there bare minimal fix the unistall so that we can reinstall with out hacking registry or file/folders.
I'm just glad I used this to deploy a simple app to only a few people.
Jim, sorry to know your experience with ClickOnce. Answering your question, you are right changing public key token would mean the revised and resigned application will be treated as a completely new deployment, not an update to the old one. As far as I know only way out is to keep public key token same between versions. y2k4life, I would argue your comment on uninstall may not be true, unless when you uninstalled the application was still running. ClickOnce removes all the files and reg keys once an application is uninstalled and no other application references any of its components.
 Munirul Abedin wrote: |
| y2k4life, I would argue your comment on uninstall may not be true, unless when you uninstalled the application was still running. ClickOnce removes all the files and reg keys once an application is uninstalled and no other application references any of its components. |
|
Actually, I can confirm this behavior. I have also seen it not fully uninstall the app. Sometimes when you try to uninstall from Add/Remove programs, it uninstalls instantly, removes the entry in the Add/Remove list and the start menu icon but leaves the entire application in the app store.
| Munirul Abedin wrote: |
| Jim, sorry to know your experience with ClickOnce. Answering your question, you are right changing public key token would mean the revised and resigned application will be treated as a completely new deployment, not an update to the old one. As far as I know only way out is to keep public key token same between versions. |
|
Would you agree that this requirement is counter to industry standards for renewing certificates thru companies like Verisign and Thawte?
