Up until now our app has been published using ClickOnce via the Visual Studio "Publish" wizard. This has been rather painful, and we've automated the process using msbuild/mage.
Unfortunately, the new deployment does not appear to be compatible with the old one, giving the "The deployment identity does not match the subscription" error when the (test) users update.
Now there are plenty of differences between the files generated using "Publish" and our Mage script, but we can't eliminate them all. For example, "Publisher" doesn't seem to be respected by GenerateDeploymentManifest
, while Mage -New Deployment
can't set UpdateMode to Foreground. There are other similar cases.
Has anyone ever successfully moved away from the "Publish" wizard without requiring the entire user base to reinstall the app? What was your approach?
P.S. VisualStudio 2008; all users are on .NET Framework 3.5 SP1.
In Solution Explorer, right-click the application project and click Properties. The Project Designer appears. Click the Publish tab to open the Publish page in the Project Designer, and click the Publish Wizard button. The Publish Wizard appears.
ClickOnce is a new application deployment technology that makes deploying a Windows Forms based application as easy as deploying a web application. ClickOnce applications can be deployed via web servers, file servers or CDs.
Use the Publish Wizard to copy solution files to a specified location, create the manifest files, and create a Setup program. To access this wizard, on the Build menu, choose Publish SolutionName. You can also access the Publish Wizard from Solution Explorer.
The trick was to match the so-called assembly identity.
Hint #1: do not use Mage to generate the deployment manifest (the *.application file). Use GenerateDeploymentManifest
instead. The Mage tool lacks two crucial options:
Hint #2: DO use Mage to add publisher and sign the deployment certificate. This is because GenerateDeploymentManifest
seems to ignore Publisher (in 3.5 SP1 at least), and similarly SignFile
is unable to use a .pfx file as the key. Whoops.
<Exec Command='"c:\path\to\mage.exe" -Update "$(MyOutputPath)\MyApp.application" -Publisher MyCompany.com -CertFile path\to\MyAppKey.pfx'/>
Hint #3: to supply the correct relative path for the "codebase" field in the deployment XML, use the following snippet:
<CreateItem Include="$(MyDeploymentPath)\v$(Version)\MyApp.exe.manifest" AdditionalMetadata="TargetPath=v$(Version)\MyApp.exe.manifest">
<Output TaskParameter="Include" ItemName="EntryPoint"/>
</CreateItem>
and then pass EntryPoint="@(EntryPoint)"
to GenerateDeploymentManifest
. The key bit is the "TargetPath" metadata. Yuck!
Hint #4: patience, a supply of old working manifests, and a good comfy diff tool.
Is this complicated and painful? Yes! But is it better than the Publish wizard? OH YES!
Edit: I've posted a working example of how one might invoke Mage from MSBuild - however working doesn't mean you can just plug it in, since there are lots of settings involved that you may want to change, and you still need to understand ClickOnce to some extent. But hopefully it can provide a useful starting point.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With