Release Management (RM) for Visual Studio 2013–Work around for running Multiple Clients

One of the things that we added with TFS 2013 was support for release management.  Release management is what I like to call the “last mile’ of application lifecycle management (ALM) and it is the process of managing software releases from the development stage to final production software release. 

You can download Release Management (RM) for Visual Studio 2013 from either your MSDN subscription or here:  https://www.microsoft.com/en-us/download/details.aspx?id=42671.  The Release Management for Visual Studio 2013 Installation guide and the Release Management for Visual Studio 2013 User Guide can help you get things set up and going.  There is also lots of information on MSDN: https://msdn.microsoft.com/en-us/library/dn217874.aspx. and in other blogs: https://nakedalm.com/category/install-and-configuration/.

What I wanted to cover is based on a usage scenario that one of my clients has when using RM.  They developed a sophisticated release process for deploying changes into their development teams’ environments.  They did these changes through RM and they treated the development teams’ environments as “Production”.  To build out the release pipeline and vet changes to their release process, they constructed a “Development” environment configured with its own RM server instance.

RM uses a client application to manage and construct the release pipeline, server connections, other administrative settings, etc.  Below is an example.

The problem that my client had (as currently configured by the installation process) was the inability to bring up two RM clients at the same time that pointed to the different Production and Development RM servers and compare setting across them.  Ideally, there should be some import/export mechanism to move release pipelines and other configuration across servers and this is in user voice: https://visualstudio.uservoice.com/forums/121579-visual-studio/category/66944-release-management.

In the meantime, there is a work around to allow this behavior.  First, the client is not particular about where it executes from since it does not rely on any assemblies being deployed to the GAC.  If you copy an installed client elsewhere on the same machine, it will still run.  You can then configure the two clients instance to point to different RM servers.  That will work great, but as you attempt to bring them both up at the same time, you will find that the last instance executed always wins by closing the other.

The way to bring up multiple clients is just a simple configuration change in the ReleaseManagementConsole.exe.config file located in C:\Program Files (x86)\Microsoft Visual Studio 12.0\Release Management\bin.  In the configuration file, you will see the following applicationSettings section:

<!-- Application Settings Configuration -->
  <applicationSettings>
    <Microsoft.VisualStudio.Release.Console.Properties.Settings>
      <setting name="AllowMultipleInstances" serializeAs="String">
        <value>False</value>
      </setting>
      <setting name="DisableSplashScreen" serializeAs="String">
        <value>False</value>
      </setting>
      <setting name="UseCustomCulture" serializeAs="String">
        <value>False</value>
      </setting>
      <setting name="CustomCulture" serializeAs="String">
        <value>en-US</value>
      </setting>
    </Microsoft.VisualStudio.Release.Console.Pro

The key here is the AllowMultipleInstances setting which is False by default.  Changing the setting to True in both of the  client instances will allow for each to be brought up at the same time and then you can dock them side by side and compare/verify/change settings as required. 

Hopefully this helps someone else with the same need.  Let me know if you have any questions…