Deploying ClickOnce-applications in different environments without modifying the assembly identity
The following describes a method that is viable for ClickOnce deployment using "Online Only" mode.
One of the aspects I recently pondered about is code identity. In other words : Auditors ask me how I ensure that the software tested and accepted by the departments is exactly and with no alternations the assembly we deploy for productive use and not some tinkered-with version.
"That's easy", I say, "I can't!". Because some config-variables are set between approval and release, the ClickOnce hashes differ and thus does the whole thing.
The image depicts the requirement rather roughly, but I think more detail is not required: An application should be stateless and not compiled to fit it's environment.
The first thing coming to my mind to sail around this kind of trouble is keeping the App.config (or any other file of my personal gusto) a part of the deployment, but removing it from the hash. That would be easy, fast and a little dirty.
First and foremost, and that should suffice as a counter argument, it would annihilate the ability to sign the ClickOnce manifest, which is really a nuisance. Not being able to add an issuer certificate would result in user frustration, as they would have to confirm their trust in me every time I publish an update of the software.
After some research I tried using the ApplicationDeployment class, and here's a snippet I created that does the job:
One of the aspects I recently pondered about is code identity. In other words : Auditors ask me how I ensure that the software tested and accepted by the departments is exactly and with no alternations the assembly we deploy for productive use and not some tinkered-with version.
"That's easy", I say, "I can't!". Because some config-variables are set between approval and release, the ClickOnce hashes differ and thus does the whole thing.
The image depicts the requirement rather roughly, but I think more detail is not required: An application should be stateless and not compiled to fit it's environment.
The first thing coming to my mind to sail around this kind of trouble is keeping the App.config (or any other file of my personal gusto) a part of the deployment, but removing it from the hash. That would be easy, fast and a little dirty.
First and foremost, and that should suffice as a counter argument, it would annihilate the ability to sign the ClickOnce manifest, which is really a nuisance. Not being able to add an issuer certificate would result in user frustration, as they would have to confirm their trust in me every time I publish an update of the software.
After some research I tried using the ApplicationDeployment class, and here's a snippet I created that does the job:
private static void GetDeploymentEnvironment()
{
if (ApplicationDeployment.IsNetworkDeployed)
{
ApplicationDeployment dep = ApplicationDeployment.CurrentDeployment;
FileInfo f = new FileInfo(dep.UpdateLocation.AbsolutePath + ".env");
if (f.Exists)
{
/// read file content and apply settings
}
}
}
Kommentare
Kommentar veröffentlichen