beta and production versions of a winforms release co-existing?

I am wondering if it is possible to have one solution with different deployment paths for the same application. What I would like to be able to do is have a 'production' version and a 'debug/beta' version of a winforms application. Ideally I would like to be able to have this done with the minimum amount of 'manual effort' required.

what I mean is that I would like to be able to configure my winform solution so that if I build a beta version of the application it will appear as a sibling to the 'release' version in the start menu... something like this:

Start Menu-->CompanyName-->ProductName-->AppName Start Menu-->CompanyName-->ProductName-->AppName(beta)

What is a good practice to configure such a thing?

Currently it seems like this is the approach we need to take:

1. change the Assembly name for the Application, in the "Application" tab, to "AppNameBeta", we cannot use the same Assembly name, otherwise it will overwrite AppName or AppName will overwrite AppNameBeta.
2. change the product name in the Publish\Options, to "AppNameBeta", so that the shortcut name开发者_C百科s are different.
3. change any assembly name references in the Resources.xml file(s), from AppName to AppNameBeta (whatever assembly name is changed in Step #1).

Am I misunderstanding this or is there a simpler/more elegant way to deploy a beta version?

Thanks for your support.

---

I think your answer is to set up configurations. Up in your toolbar, you'll see a drop-down with either Debug or Release specified; drop it down and you'll see a "Configuration Manager..." option. Select that. Under "Active solution configuration:" at the top left of the new dialog will be another drop-down that will have a "New..." option. Select this, enter "Beta" as your config name, and copy settings from "Release" (which I assume you have configured for your actual product releases). Make sure "Create new project configurations" is checked. This will allow you to create a new set of deployment settings for your projects and the overall solution.

Now, you can choose the Beta configuration or the Release config, and when doing so you can specify different projects to include; for instance, you could put two installer projects in your solution, one configured for a beta install and the other for a release. You can also alter deployment and publishing paths.

There are some things that this will not allow you to do:

• You cannot have different assembly names, versions or GUIDS. That means that any assembly that is registered in the GAC, or that is placed in a shared directory, will be overwritten by the most recently-installed file, or by the latest version (probably the beta). You really cannot get around this without renaming your projects or having a completely different project that uses shortcuts to link its code files.
• Because the install projects will be different, the applications they install will be treated as different apps by Windows. However, the installers MUST specify different default locations for installed files, user data, etc. or else the installers will overwrite each other, causing not only a loss of your production environment but a major mess in the install/uninstall logs.