Server deployment of ClickOnce? Isn't ClickOnce client deployment? Yes, it is. However, you will have to deploy the ClickOnce files to a server, right? I feel this is a poorly documented step and I thought I share some of my experience around this.
So what's the problem? The main issue is the deployment manifest file. If you've worked with ClickOnce you know about this file, if not here's a (very) short description. The deployment manifest includes information about where the ClickOnce application is located (e.g. http://myServer/myWD/myApp.application) as showed in the following snippet:
...
<deployment install="true" mapFileExtensions="true" trustURLParameters="true">
<subscription>
<update>
<beforeApplicationStartup />
</update>
</subscription>
<deploymentProvider codebase="http://myServer/myWD/myApp.application" />
</deployment>
...
This file needs to be signed with a certificate to be valid, which means that any changes to this file makes it invalid and you'll have to resign it. This is a good thing for security, but it causes some problems regarding deployment. The url specified in this file must be changed when deployed at a server. Unless you want to get all information needed from your customer and create the deployment package before sending it to them or force them to set up a server named myServer ;-). I don't think that solution is very likely to be used in production systems. So what you need to do, is make the installation (e.g. msi) change the manifest file and resign it during installation.
Microsoft has provided us with a tool to do exactly this. However, you're not allowed to redistribute it. Another issue is that you need to have a certificate for signing and you don't want to have your corporate certificate laying around in your msi. The most common solution around this problem is to prompt the user during installation for a certificate (like suggested here). But then your app is signed by someone else's certificate, which is probably not what you want.
I will now suggest a different solution to this problem. In the System.Build.Tasks.dll you'll find much of the functionality needed to do the same thing as Microsoft's Mage.exe is doing. The nice thing about this dll is that it's a part of the default .Net Framework installation. Here's a short description of the classes needed:
DeployManifest
An object model for the manifest file. Gives you direct access to specific parts of the manifest and makes it really easy to make changes.
ManifestReader
Have a static method (ReadManifest) which let you read and return the manifest you are going to work with.
ManifestWriter
Use the static method WriteManifest to write your changes back to the manifest file.
X509Certificate2
Your certificate to sign the manifest file with.
SecurityUtiities
Has the static method called SignFile which let you sign your manifest.
By using the classes described above it should be quite easy to achieve the same as with the Microsoft utility. Here's an example:
using System;
using System.IO;
using System.Reflection;
using System.Security.Cryptography.X509Certificates;
using Microsoft.Build.Tasks.Deployment.ManifestUtilities;
...
string manifestPath = @"C:\Temp\myApp.application";
string deploymentUrl = "http://myServer/myWD/myApp.application";
DeployManifest manifest = (DeployManifest)ManifestReader.ReadManifest("DeployManifest", manifestPath, false);
manifest.DeploymentUrl = deploymentUrl;
ManifestWriter.WriteManifest(manifest);
X509Certificate2 certificate = new X509Certificate2(GetCertificateFile(), "password");
SecurityUtilities.SignFile(certificate, null, manifestPath);
There is one important step we need to solve. How do we protect the certificate we need to sign the manifest file. For this I suggest you incorporate this into your tool (either a command line tool or a .Net library) by using Build Action = Embedded Resource. This will make your certificate inaccessible for most people. If you want to secure it even more, you can crypt it in however way you want. I leave this up to you ;-) In my code above I've done this in the GetcertificateFile() method:
X509Certificate2 certificate = new X509Certificate2(GetCertificateFile(), "password");
There is of course one other issue which you'll have to consider. What if someone uses your custom tool to sign their ClickOnce app? So you need to protect this as well with a password or some other mechanism. If you have a good suggestion to this, please let me know.