I've got the following scenario:

I've got a CD with my product. The product has two parts:
1. Server side ASP.NET application and
2. Client side Winform app.

My customer first installs software from that CD on the web server. Setup
creates ASP.NET applications and one folder that contains ClickOnce
deployment (.exe, .dll, .manifest, .application files). The ClickOnce
deployment is used by end user to install client side part from customer's
web server.

In clickOnce deployment folder in "myapplication.application" file I've got
the following line:
<deploymentProvider
codebase="http://localhost/MyApplication/myapplication.application" />

Setup program replaces 'localhost' to server name (as this is required by
ClickOnce). After installation when user wants to install client part of my
application he gets an error 'Application manifest is improperly formatted'.
This error occurs because I didn't sign deployment manifest after
replacement of localhost. So I need to provide to customer my certification
key (.pfx file) or give him an option to specify other key and my
application setup needs to contain a mage.exe tool to sign the .application
file (I assume that customer web server doesn't have a .Net SDK). I don't
want to sign once again the deployment manifest and give user certification
key and mage on installation CD.

Is there any solution for this problem or this behavior is by design?

My goal would be to prepare all setup files before I burn CD and ship to my
customers. At the moment it seems I cannot do that as it looks like I need
to build signing logic into my main setup script and ship path of .NET SDK
to make it working which is quite cumbersome in my opinion.

My questions:
1. Do I have to sign manifest file to make ClickOnce working?
2. Do I have to update manifest file on the customer's server?
3. Do I have to resign manifest file on customer's web server?

Regards,
Grzela

Hi,

After you modify the manifest file, you need to resign the file. You
can do this programmatically from your setup application by using an
MSBuild task. You probably already use a custom action to modify the
manifest file so you can resign the file at the same place. Add a
reference to Microsoft.Build.Tasks and then use the
SecurityUtilities.SignFile(...) method. Have a look at the msdn
reference for it.

http://msdn2.microsoft.com/en-us/lib....signfile.aspx

Thanks,
Sayed Y. Hashimi
http://www.sayedhashimi.com
Shameless Book Plug: Service-Oriented Smart Clients with .NET 2.0
http://www.amazon.com/exec/obidos/tg...3/qid=11263614...