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

  1. Build application and store new release into Application Files Repository/Folder
  2. Get parties that should be updated (config file, database what ever)
  3. 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?

  • Seems like this would be a start to handle it on the website side. Different clients get directed to different installation (version) files in your case. codeproject.com/Articles/24519/… – JeffO Apr 25 '14 at 17:52
  • @JeffO: Regarding the fact who can download what version you are right and the codproject arcticle provides some good suggestions. But there is still the problem of generating multiple, different manifests with different update locations. The update problem is sadly not solved with the codeproject solution. But many thanks for the hint! – Dirk Beckmann Apr 28 '14 at 10:17

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 [product name].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.

| improve this answer | |

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.

| improve this answer | |
  • Dear Greg, thanks for the suggestion. The first look promising but I have to check this in more detail. – Dirk Beckmann Apr 28 '14 at 10:19

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.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.