I've been writing a Winforms app (Dot Net 2.0, VB, VS2005) and I've been doing ClickOnce deployment to a server for over a year now on this one. Frankly the deployment is not that sophisticated. We're on an intranet with no exposure to the outside so security is at a minimum and most of my settings are defaults. Also I'm using a temporary key (pfx). I do not pretend to be a security expert.

A few days ago I added an msScripting control to the project (AxMSScriptControl.AxScriptControl). Now I'm getting frequent failures at deployment, all complaining about hashes. It's an extremely long message but the main problem seems to be "+ File, AxInterop.MSScriptControl.dll, has a different computed hash than specified in manifest."

The only sure cure for this appears to be to delete the old pfx, add a new one, and re-publish the app twice.

(Or possibly wiping out the entire bin\release folder and rebuilding from scratch. Still not sure about that.)

Suggestions? (Haven't found any exact fixes on the net yet.)

Test certificates are fine; be aware that they only last a year when created with Visual Studio, which will cause you some problems in a year because you are targeting .Net 2.0.

If you want to read more about that, check out this article:

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

About the scriptcontrol issue. I bing-ed that, and found hardly any information about that control. Just out of curiosity, what are you using it for?

If you have this problem again, I would try registering the control in the user's GAC and removing it from the project. It might just be that it doesn't generally work when deployed locally, and it has to run in the GAC. You can deploy it as a prerequisite if that is the case, by creating a setup & deployment project that puts it in the GAC and registers it, then use the Bootstrapper Manifest Generator to create the prerequisite package and add to VIsual Studio so you can push it as a prerequisite.

That's my best guess.

RobinDotNet

---

Click here to visit my ClickOnce blog!

The computed hash error usually happens when something in the deployment gets modified somehow without the application being redeployed.

You say you added that control to the project. Have you changed it since then? Or did you just add it and redeploy the application? Did you increment the version number?

Is your deployment signed? If you go to the Signing tab, do you have it set to sign the manifest? I assume this is where you created the test certificate.

How are you deploying your application? Are you using Visual Studio or msbuild or mage/mageui?

If the user having the problem uninstalls and reinstalls the application, does the problem go away?

Another reported reason for this problem is if your web server (IIS) has HTTP compression turned on -- can you find out if that is true?

RobinDotNet

---

Click here to visit my ClickOnce blog!

Actually the problem seems to have gone away for now anyway, and there have been at least a half dozen new versions since the last problem.

You say you added that control to the project. Have you changed it since then? Or did you just add it and redeploy the application? Did you increment the version number?

Is your deployment signed? If you go to the Signing tab, do you have it set to sign the manifest? I assume this is where you created the test certificate. Actually I've been using a temporary certificate. I'm really not sure where we're going with this. I don't have any real experience with certificates and this is a rather informal environment.

How are you deploying your application? Are you using Visual Studio or msbuild or mage/mageui? I only publish with Visual Studio.

If the user having the problem uninstalls and reinstalls the application, does the problem go away? Not sure.

Another reported reason for this problem is if your web server (IIS) has HTTP compression turned on -- can you find out if that is true? I'll look into that.

Thanks.

Test certificates are fine; be aware that they only last a year when created with Visual Studio, which will cause you some problems in a year because you are targeting .Net 2.0.

If you want to read more about that, check out this article:

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

About the scriptcontrol issue. I bing-ed that, and found hardly any information about that control. Just out of curiosity, what are you using it for?

If you have this problem again, I would try registering the control in the user's GAC and removing it from the project. It might just be that it doesn't generally work when deployed locally, and it has to run in the GAC. You can deploy it as a prerequisite if that is the case, by creating a setup & deployment project that puts it in the GAC and registers it, then use the Bootstrapper Manifest Generator to create the prerequisite package and add to VIsual Studio so you can push it as a prerequisite.

That's my best guess.

RobinDotNet

---

Click here to visit my ClickOnce blog!