How do I deploy two ClickOnce versions simultaneou

问题:

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.

回答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.

回答2:

ClickOnce: Concurrent versions explains how to do this.

回答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.

回答4:

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

回答5:

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

回答6:

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.

回答7:

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.