38

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.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Brett Ryan
  • 26,937
  • 30
  • 128
  • 163
  • 1
    In response to your second question on clickonce application identity, it's not about the assembly guid, it's about the key (pfx file) that your publish is signed with – Rob Fonseca-Ensor Nov 18 '09 at 15:47
  • 1
    @Rob That's interesting, so if I have multiple applications signed with the same key, this will cause windows to think that they are the same application? That seems like a serious flaw to me. – Brett Ryan Nov 19 '09 at 01:23
  • 1
    No, it's not a problem. I have 7 applications installed that are signed with the same key, and it's not a problem. – RobinDotNet Apr 01 '11 at 08:32

8 Answers8

29

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.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Rob Fonseca-Ensor
  • 15,510
  • 44
  • 57
  • 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 Nov 18 '09 at 08:28
  • 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 Nov 18 '09 at 09:11
  • This might help with that: http://stackoverflow.com/questions/132885/best-way-to-switch-configuration-between-developmentuatprod-environments-in-asp#132934 – Rob Fonseca-Ensor Nov 18 '09 at 14:19
  • 1
    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. – codeConcussion Nov 18 '09 at 15:00
  • 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. – Der Jan 09 '19 at 17:59
7

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.

KyleMit
  • 30,350
  • 66
  • 462
  • 664
LongZheng
  • 1,873
  • 17
  • 18
  • When I try this the PropertyGroup ClickOnce conditions actually overwritten. – kbeal2k Aug 31 '12 at 18:08
  • 1
    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. – LongZheng Sep 04 '12 at 02:12
  • 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. – Steven Pena Apr 15 '14 at 21:05
  • @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" – Chris W. Jun 29 '15 at 08:54
  • 1
    @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. – Steven Pena Jul 22 '15 at 19:50
2

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

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
dgp
  • 185
  • 1
  • 9
  • 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 Jul 04 '18 at 12:51
1

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

jaywalker
  • 19
  • 1
  • 3
    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. – Brett Ryan Apr 21 '11 at 07:11
0

I do that all the time. I even have a screen in my application that changes which version a specific user will get. And I'm not doing anything tricky on the app side, all the magic is on the web server hosting the ClickOnce files.

Take a look at the article my buddy wrote, Fine Grained Versioning with ClickOnce . It explains how we did it.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Jonathan Allen
  • 68,373
  • 70
  • 259
  • 447
  • 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. – Brett Ryan Nov 18 '09 at 09:51
  • On another server... yea, it sounds like you have to play with MageUI. – Jonathan Allen Nov 19 '09 at 04:28
  • Would that work on Linux (say, Apache on a web hotel)? Or even with IIS on a web hotel? – Peter Mortensen May 08 '16 at 16:15
  • 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. – Jonathan Allen May 09 '16 at 04:50
0

A variation on Peter Mortensen's two project scenario. I wanted dev, customer test, and customer release. In my case I wanted the customer test providing some visual clues that it was test, not live (e.g. 'TEST' in the title and a different visual theme).

I found it simplest to have two solutions as well as two stub projects. Each project in its own directory, with its own stub program.cs, app.config and assemblyinfo.cs.

In the dev/test solution, the debug configuration was for dev, the release config was for customer test. I used SlowCheetah to transform the app.config for the latter.

In the customer release solution I needed only a release config.

Merlinz
  • 1
  • 1
0

You have to edit your csproj manually, after having at least once configured your project to publish a Click Once application.

Move some of Click Once related properties from the <PropertyGroup> to the <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' "> property group and duplicate them under the <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' "> property group.

The properties to duplicate are ApplicationRevision (only if you want separate revision counters), PublishUrl, ProductName and SuiteName (the last two are required to be able to differentiate the configurations on the target machines). You also will have to override the AssemblyName property (without removing it from the first group).

If you want to be able to debug your project under any configuration, you also will have to add the StartAction and StartProgram properties in each group where you overrode the AssemblyName property.

After having given these properties adequate (i.e. different) values, you will be able to publish both configurations, without having to modify your project, just by selecting the desired configuration. Note however you will have to unload your project between publishes for different configurations, or Visual Studio will mess up your parameters.

After that, you also will be able to install both versions on the same target machine.

Yet Another Code Maker
  • 1,625
  • 1
  • 10
  • 5
0

It is possible to deploy 2 versions of the same application without changing the AssemblyName, here is how it's done...

  1. Create a clickonce deployment
  2. Open the .application file and make the following edit:

enter image description here 3. Run the setup and MyApp will be installed. Depending on previous attempts you may need to clear the application cache with mage -cc

  1. Edit the .application file again replacing MyApp with MyApp2

  2. Run setup and MyApp2 will be installed

Nigel Findlater
  • 1,684
  • 14
  • 34