Skip to content

Ellery Yang

I write about products and the PM role.

Menu
  • Home
  • About me
Menu

Separating release and dev builds in Visual Studio

Posted on July 24, 2015April 25, 2020 by Ellery

 

In my internship project at Microsoft, I needed to set up different build environments for release and dev purposes, so when the developers mess around with back-end code, users out of Microsoft office don’t get affected. Without touching details of the product, I will talk about how did I set up different build configurations in Visual Studio.

When a project is created in Visual Studio, by default it contains “Debug” and “Release” configurations. The simplest practice when setting up a new configuration is to use Copy from Debug/Release option, depending on whether you are configuring for users or devs.

1. Create a new configuration, by selecting “Configuration Manager” under Build menu on menu bar. Name your new configuration, such as AlphaRelease.

2. Copy settings from Debug/Release. In this example, we want a release version of our software for alpha testing, so we copy from Release. This will ensure your application has a release signature and don’t get rejected by stores.

3. Edit variables specific to new configuration. Usually a new build configuration comes with different back-end URI, connection strings and even UI texts. Be sure to define all of build-specific variables for the new configuration. Open Solution Explorer, right click on a project and click Properties. Find “conditional compilation symbols” in Build tab, and you will see a comma (sometimes space) separated list. Add a unique name for your configuration, like ALPHA_BUILD, so you can apply it in preprocessors such as

#if ALPHA_BUILD

key = “alpha password”;

#else

key = “dev password”;

#endif

4. Exclude manifest changes in Git. If you are making a Windows Store app, you will likely need a different Azure App Service (or other cloud service platforms) instance to support new configuration because, as I said, the whole point is to allow devs to mess around with a dev back-end service while users are connected to a stable one. When you associate your project to a new Windows Store app name, Package.appmanifest and Package.storeassociation.xml will change, and you need to exclude them from in Git when checking out to a different branch.

git rm –cached Package.appmanifest

git rm –cached Package.storeassociation.xml

 

Then you should be able to easily switching between two build configurations by using git checkout!

PM Blog (2017 - present)

  • April 2024
  • November 2023
  • September 2023
  • March 2023
  • January 2023
  • September 2022
  • July 2022
  • February 2022
  • September 2021
  • August 2021
  • April 2021
  • January 2021
  • December 2020
  • November 2020
  • October 2020
  • September 2020
  • August 2020
  • July 2020
  • June 2020
  • May 2020
  • April 2020
  • February 2020
  • January 2020
  • December 2019
  • October 2019
  • July 2019
  • June 2019
  • April 2019
  • March 2019
  • December 2018
  • October 2018
  • May 2018
  • March 2018
  • December 2017

A Student's Blog (2015 - 2017)

  • July 2017
  • June 2017
  • August 2016
  • July 2016
  • April 2016
  • March 2016
  • February 2016
  • December 2015
  • October 2015
  • September 2015
  • August 2015
  • July 2015
© 2025 Ellery Yang | Powered by Minimalist Blog WordPress Theme