I’m struggling with release management of a piece of software. First some general information:
- It is a ClickOnce application
- I follow the release often practice
- There are about 30 parties served with this software
- I need full control which update will be delivered to which party
- Not each party is allowed to get the latest update/release
- Each party has multiple clients that are all allowed to get the latest update, served for the specific party
So that’s what my requirements are in a rough description. So let me explain what I was thinking about how to solve this.
- I would like to create a “deployment” website (asp.net) that will handle all the requests
- There are two endpoints one for download the client and one where the client checks for updates
- So each party has a separate endpoint like DeploymentSite/party1 and another for DeploymentSite/party2
- The Application Files should still be stored centralized
So I thought it would be manageable with mage.exe with the following steps
- Build application and store new release into Application Files Repository/Folder
- Get parties that should be updated (config file, database what ever)
- Run mage.exe to create a new application and deployment manifest for each party in the update list with new Application File Location (1.0.2)
Actually I’m really struggling with this mage.exe staff. I can’t create the appropriate files with the needed codebase.
How to handle thes requirements?
2
What you want is possible, but not quite in the way you mention.
A published ClickOnce package is controlled by two manifest files – the application manifest called .application housed in the root folder of the published deployment, and the version manifest called [application name].exe.manifest, which of course resides in the codebase folders for the specific versions.
To to cut a long story short, you can publish as many versions as you like – in fact that is the easy bit – but you will then need a copy of the application manifest for each ‘party’ that you have. You can then update them independently by updating their application manifest, once you have done that any client machine will auto update – this is part of the functionality of ClickOnce (the installed ClickOnce application checks the application manifest for updates every time you run it (or at the period you specify as part of the publish)).
All you need to do is control which application manifest any particular party originally installs from, you can do this simply by checking their credentials then redirecting them to the appropriate application manifest (which will then launch the install prompt).
You don’t need to be messing round with Mage to achieve this – you can accomplish this using the publish functionality built into Visual Studio – you can publish to a neutral location then copy the generated neutral application manifest over top of the appropriate party specific application manifests.
Note that party specific application manifests are necessary because ClickOnce is an installation framework, it knows nothing about authentication and authorisation, so you have to take care of that bit. Technically you could house the application manifest files all in the same folder if you name them individually – but this does require a knowledge of Mage and isn’t a simple task. Additionally you could automate some of this with Release Management and one or two custom tasks.
The web site sounds like the right approach for the application deployment and checking for updates. You could investigate a C# MVC site for this approach.
I thought I could help more with the building of all the manifest files. My company creates a piece of software called ClickOnceMore which is designed to help integrate ClickOnce into a build cycle. I think it would be perfect for your scenario to help with the multiple clients.
ClickOnceMore has a concept of macros. To implement your different parties, you would create a single ClickOnceMore package with all of the files needed for the application and then add a macro set for each client. For the config files you can reference a different one for each client using a macro value, you can also reference a different output location for each client. When you build from the command line you can specify which macro set to use.
I hope this helps. There is a free trial of ClickOnceMore available from our website.
1
I have a similar situation and my plan is to use Octopus deploy and slowcheetah for app.config transforms to create a package which then has multiple deployment targets for each unique customer.