i was struggling to make a process for ClickOnce deploment with Octopus. Because i have to modify the config files and resign the application. That was quite easy but this is not enough. Because the ClickOnce application identities are the same for all the environments you cannot install multiple version on one computer. So the users can use or the Production or the UAT version of the app. So i write some script to modify the application identity of the ClickOnce app. Everything works fine.
But i have an other problem i would like to do this ClickOnce repack on the Octopus server. Right now it happens on the target machines, but i have to copy the mage.exe and our codesign certificate to deployment targets and i don’t really like that. So my plan is to repack the ClickOnce application on Octopus server and deploy the repacked package.
I was trying to publish a new package to Octopus nuget during the deployment process (with a different name, which contains the environment name) and delete this package after deployment. The problem with this solution is that Octopus tries to download all the packages az once. So when i deploy the ClickOnce nuget to Octopus server to repack the Octopus wants to download the environment specific nuget to the deployment target but that nuget package does not exsist at that time.
Can i configure Octopus to download the nuget packages separatelly just before each Deploy nuget step? Do you have any other idea how to solve this ClickOnce repack problem?
Thanks for getting in touch! I have read through this a few times with a team mate and we are a little confused, as we are having trouble trying to figure out what you need and want.
Could you give me a step by step of what you would like/need to achieve, and I can then help you figure out where and how Octopus can assist.
Or if you want to show me what you tried to do via screenshots of your process and a deployment log I can also try to help. I believe I understand what is not working, but I think if we approach this from a ‘what you would like to happen’ perspective we can come up with a solution for you.
We have a ClickOnce application and we would like to deploy it to different environment with Octopus. It is important that our testers can install multiple application from different environments. So the ClickOnce assembly identity should differ in each environment, in this case the .NET environemnt will consider each app as a different application. I saw two options:
Simple option: Our TFS build server publishes nuget packages to Octopus deploy. The TFS should build and publish multiple nuget packages which contains different ClickOnce application per environment. (eg. App_Dev.nupkg, App_Test.nupkg, …) All packages will contain different configurations and different assembly identity. We should configure octopus deploy steps to use different package in different environment.
Better option: Our TFS build server publishes only one package with configuration files which contain Octopus variables (#{VAR}) and a default identity. The octopus should repack the ClickOnce application and create the concrete application during the installation process. (substitute variables, change identity, update manifest file, sign manifest, update .application file, sign application file)
I managed to achieve the second option. (I will put ClickOnce steps to octopus library) We have only one problem with this solution. My first plan was to repack the ClickOnce application on Octopus server because during the repack we need the code sign certificate and password and i don’t want to copy it to all target machince. To do this i add a step to the process so the Octopus create a new nuget package from the repacked CilckOnce application. And then it publishes this temporary package to Octopus nuget. The next step is to deploy this temporary package to target machine. After the deploy step the Octopus will remove the temporary package from Octopus nuget.
So the process template looks like this:
Deploy original ClickOnce to Octopus server
Repack the original ClickOnce project for one environment (eg. Dev) (subsitute variables and update identity)
This process template won’t work because the Octopus tries to download all nuget packages at the first deploy step. In our case the first step is to download the original ClickOnce package to Octopus server to do the repack. That’s why Octopus tries to download all other packages to Target machines and at this time Octopus won’t find the temporary nuget package. It would be great if we can configure Octopus to download only the deployed nuget during each deploy step. So during the 1. step it only download the original ClickOnce nuget. And it will download the repacked, temporary nuget during the 5. step.
If is not an option i will have to write my own deploy script (which is not so difficult) to download and unpack package from Octopus nuget by hand. Right now we do the repack on the target machin and it works great.
I hope i can explain it clean. I didn’t really find detailed article on deploying ClickOnce application with Octopus. I can publish my scripts and write down my experiences if it is useful for the community.
yeah it is almost the same but do not solve two of my problems.
If you don’t change your application id, you can’t install apps from different environment on one computer. So your testers can’t test the UAT and Staging environment at once. I think this is a common use case and it is a big problem with that solution.
The other problem which i can’t manage yet that you need mage.exe and code sign certificate on all you build computer. This can be a security risk and you need extra effort (install mage.exe, copy certificate…) to populate a new build target.
So that article shows a quite good solution but that is not production compliant IMHO.
I am very sorry! We have two buttons, one is reply to a ticket and the other is ‘this ticket doesn’t need a response’ and I thought I clicked the second, but apparently I clicked the first
FYI, I’ve gone ahead and built an extension to OctoPack that takes care of ClickOnce issues (different config files / publish locations / product names).
