How do I deploy two ClickOnce versions simultaneously?

c# .net deployment clickonce

19,763

Solution 1

It might sound kind of lame, but the easiest way to do this is to have two EXE projects in your solution. The Main method of each of these will just call the Main method in your original EXE project (which you'll have just switched over to being a DLL file).

This means that each EXE project can have its own ClickOnce publishing settings, as well as its own app.config file. This means you have different connection strings for the production and the test version.

Your other option (the one that might seem to make the most sense) is to use MageUI.exe to manually build the ClickOnce files, which would let you choose a different configuration file and publish location each time you ran the tool. There's also a command line version (Mage.exe) so you could in theory automate this.

However, we found that the solution with two "runner" projects was far far simpler. I'd recommend you try that first.

Solution 2

ClickOnce: Concurrent versions explains how to do this.

Solution 3

I manually edited the .csproj to specify a different ProductName for debug/release.

<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
    ...
    <PublishUrl>publishbeta\</PublishUrl>
    <InstallUrl>http://www.softwareabc.com/download/beta/</InstallUrl>
    <ProductName>Software ABC Test</ProductName>
    <AssemblyName>SoftABCTest</AssemblyName>
    <ApplicationIcon>Resources\Test.ico</ApplicationIcon>
  </PropertyGroup>
  <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">
    ...
    <PublishUrl>publish\</PublishUrl>
    <InstallUrl>http://www.softwareabc.com/download/</InstallUrl>
    <ProductName>Software ABC</ProductName>
    <AssemblyName>SoftABC</AssemblyName>
    <ApplicationIcon>Resources\Application.ico</ApplicationIcon>
</PropertyGroup>

One caveat is that Visual Studio 2010 doesn't update this if you switch between debug/release. It only takes effect when it loads the solution so make sure to switch debug/release then close and reopen the solution.

Solution 4

See the succinct video on concurrent versioning: ClickOnce: Concurrent versions.

Solution 5

Try changing the Assembly Name in the Application tab in the properties window.

View more solutions

19,763

Author by

Brett Ryan

I am an application developer with a responsibilities in Java/J2EE web, C#, Linux, jQuery, Objective-C, Progress Software (OpenEdge). I work mostly with rich clients, the NetBeans Platform and HTML environments.

Updated on June 12, 2022

Comments

Brett Ryan almost 2 years
I would like the ability to have a test ClickOnce server for my applications where users can run both the production version and the test version in parallel. Is this possible?

I first tried using the following in AssemblyInfo.cs and also changing the name in the ClickOnce deployment though all this achieved was overwriting the users' production version with the test version. Likewise, it did the same when they went back to the production server.
```
#if DEBUG
[assembly: AssemblyTitle("Product Name - Test")]
#else
[assembly: AssemblyTitle("Product Name")]
#endif
```
I thought I should also clarify that the two deployment locations are different from one another and on different servers.

UPDATE

I've also tried setting the GUID for the manifest depending on the debug mode, but again it does not work (dummy GUID's used below).
```
#if DEBUG
[assembly: Guid("AAAAAAAA-AAAA-AAAA-AAAA-AAAAAAAAAAAA")]
#else
[assembly: Guid("BBBBBBBB-BBBB-BBBB-BBBB-BBBBBBBBBBBB")]
#endif
```
How are the two distinguished? It seems that the installer sees them as two separate programs as I get a confirmation of installation for each. Though, when I install the second one, "Add/Remove Programs" only sees the latter, though the former is still on disk, as when I go to reinstall it later, it just simply runs, but then the add/remove programs switches back to the former name.
Brett Ryan over 14 years

I can see the simplicity in the two stub exe's though I can also see it as a burden with maintaining two sets of configs etc. I'll see how I go with mage first and then try the latter. I could see maintaining user-settings a real pain with the two stub exe's.
Brett Ryan over 14 years

I think you're right with the two stubs idea, it doesn't sound logical but does prove to be less messy than with mage, however as mentioned earlier I fear I'm going to find my team coming unstuck with config differences, we may need to manage this some how by merging app.configs from each of the projects through the build process, ick!
Brett Ryan over 14 years

I'm actually trying to allow two click-once installs of the same application though different versions, one the production tree version and another on another update server which is the test tree.
Rob Fonseca-Ensor over 14 years

This might help with that: stackoverflow.com/questions/132885/…
codeConcussion over 14 years

One note on using the command line version of mage to automate deployments. It works fine but is a subset of mageui. There are a lot of things you just can't do with the command line mage, like setting your application icon.
Jonathan Allen over 14 years

On another server... yea, it sounds like you have to play with MageUI.
Brett Ryan about 13 years

Thanks Robin, seems like a fairly simple approach though there's a few things to remember to change/change back, is there a simple way to do this, maybe an MSBuild file that could do this for me that would quite simply import the existing csproj file but set the AssemblyName etc? I've found you can't change these in property groups and they get ignored if you try.
Brett Ryan about 13 years

Unfortunately this only solves part of the problem, the client still thinks it's the same app with a different name, so the data storage for any ApplicationSettingsBase objects all get shared, the test version ends up corrupting the production version.
RobinDotNet almost 13 years

There are only 3 things you have to change. The deployment urls, the assembly name, and the product name. We use source control, so I shelve a set of just these changes, and unshelve them when I need them.
kbeal2k over 11 years

When I try this the PropertyGroup ClickOnce conditions actually overwritten.
LongZheng over 11 years

I've never seen it overwritten but definitely do NOT change any of the build settings via the project GUI inside Visual Studio which may override it.
Metro Smurf about 11 years

@RobinDotNet Whilst this may theoretically answer the question, it would be preferable to include the essential parts of the answer here, and provide the link for reference.
Steven Pena about 10 years

If you publish using one configuration, switch to the other and close the solution - VS will ask if you wish to save the project (because it has indeed overwritten those properties). Choose "No", and re-open the solution. Your properties won't be overwritten in this case. Obviously because of this, it's a brittle solution, but does work if you are careful.
Chris W. almost 9 years

@StevenPena - yes, but this is what you're trying to avoid by automation of the deployment - the need to check the publish, install and update urls before each publish. And how can you guarantee that one of the devs won't save the project properties tab at some point even by mistake? There must be more reliable solution to it. The app.config issue is quite easy to work around - you just add a .config file for each environment, like app.config.devtest, app.config.uat, app.config.prod and a pre-build command: xcopy /y "$(ProjectDir)app.config.$(ConfigurationName)" "$(ProjectDir)app.config"
Steven Pena almost 9 years

@ChrisW. Yes. It's not an automated approach. I was clarifying the proposed answer here, which was a manual approach - but one that does propose a solution to the question nonetheless (there is nothing regarding automation in the original question). The questions you are raising are different questions, not the one posed and answered here. I would suggest you create a different question more specific to automation.
Peter Mortensen almost 8 years

Would that work on Linux (say, Apache on a web hotel)? Or even with IIS on a web hotel?
Jonathan Allen almost 8 years

I don't see why not. At the end of the day, ClickOnce is just downloading a file or two. It doesn't know or care what you are using to host the file.
David Savage almost 6 years

Based on that vlog 1. Create a source control branch for the 'Test' version, with 'Live' on master 2. In Visual Studio 2017 (VS) under 'Publish... Application' add "Test" postfix to the 'Assembly name' 3. In VS under 'Publish... Publish' add "Test" postfix to the 'Publishing Folder Location' and the 'Installation Folder URL' 4. In VS under 'Publish... Publish... Options...' add "Test" postfix to the 'Product name' 5. Change any files or resources used by the application (i.e. log files) 6. Publish 7. Once the testing is complete merge the 'Test' branch to 'master' and reverse the steps.
David Savage almost 6 years

Based on that vlog 1. Create a source control branch for the 'Test' version, with 'Live' on master 2. In Visual Studio 2017 (VS) under 'Publish... Application' add "Test" postfix to the 'Assembly name' 3. In VS under 'Publish... Publish' add "Test" postfix to the 'Publishing Folder Location' and the 'Installation Folder URL' 4. In VS under 'Publish... Publish... Options...' add "Test" postfix to the 'Product name' 5. Change any files or resources used by the application (i.e. log files) 6. Publish 7. Once the testing is complete merge the 'Test' branch to 'master' and reverse the steps.
Der over 5 years

To solve the duplication in user settings, I created a second settings file in my original project which contains the settings that need to be overwritten in the other projects. After changing the file's Access Modifier to Public, you can create an app.config file in your other projects to override the settings.