Visual Studio logo

How to fix a build configuration that’s not available as a build directive in Visual Studio?

This post was most recently updated on September 12th, 2021.

3 min read.

This article describes how to fix and tweak your pre-build directives in Visual Studio – just in case they refuse to work properly. Because yeah, apparently that sometimes just randomly happens. But fear not – there’s a stupid and ugly, but definitely thoughtful workaround available!

Also, sorry for the confusing title. I’m taking suggestions for a more descriptive one – but this one was kind of difficult to word clearly.

Anyway – on to the topic of the day!

Problem

Table of Contents

So you’re either trying to get a new build configuration to be visible in the dropdown in Visual Studio or perhaps one of the existing ones has disappeared. You might also not have the associated variable available for your sweet, sweet preprocessor/pre-build statements/directives – whatever they’re actually called :)

The problem is, the visibility of these configurations in the dropdown – the place from which they’re arguably accessed most often – is finicky at best. Sometimes a new configuration simply won’t be visible, no matter what you do, and which hacks you apply.

And that’s not all – additionally, the build constants might not work as expected. In the example below, “STAGING” is selected as the configuration, but instead “DEBUG” is enabled in the code.

Build directives can enable and disable certain sections of the code - but in this example, the wrong sections are getting enabled!
Build directives can enable and disable certain sections of the code – but in this example, the wrong sections are getting enabled!

And it’s not just IntelliSense, it’ll also happen during the build – and obviously then runtime.

For example, a close-up from the screenshot above. I had an integration test project configured with a couple of URLs for different environments configured like this:

Build directives enable you to make your code look like horrible duplicated spaghetti. But in this particular case, even the duplicated spaghetti doesn't quite function properly: you're supposed to have the selected build configuration highlighted - but in my case it'd always highlight DEBUG.
Build directives enable you to make your code look like horrible duplicated spaghetti. But in this particular case, even the duplicated spaghetti doesn’t quite function properly: you’re supposed to have the selected build configuration highlighted – but in my case, it had always highlight DEBUG.

But enabling any other configuration than “Release” would always result in DEBUG being true, and I never ended up with the URLs from STAGING or DEV.

This obviously needs to be fixed, somehow… But what do?

This article explains my most favorite thoughtful workarounds to the issue!

Solution

This one is going to be a combination of a couple of steps to verify things haven’t gone wrong, and if that all looks peachy, an unorthodox and stupid workaround as a final, ugly cherry on top.

I mean… I guess that applies to a lot of my articles.

Time needed: 10 minutes.

How to expose a project configuration as a build directive?

  1. (Prerequisite) Make sure you have added an additional configuration

    This guide presumes you’ve already created the configuration from the Configurations -dropdown:
    This image has an empty alt attribute; its file name is image-42.png

  2. Open the project file in edit mode

    This can be done by clicking the project file with the right mouse button, and then selecting “Edit Project File”.
    "Edit Project File" in Visual Studio Solution Explorer

  3. Make sure your configurations exist in the project file

    Should be one of the first things in the file:
    This image has an empty alt attribute; its file name is image-44.png
    If not, feel free to add them – because they really do need to be there :)

  4. Make sure your build constants exist in the project file


    This image has an empty alt attribute; its file name is image-45.png

  5. Add a redundant condition to your PropertyGroup

    Okay, so I know this sounds nonsensical from the get-go, but hear me out!

    For whatever reason, Visual Studio sometimes messes up parsing the PropertyGroup your build constants live inside unless it has a Condition set up.

    But what should that condition be?

    Well, how about… Condition=”false” ? 😁
    This image has an empty alt attribute; its file name is image-46.png

  6. Last-ditch effort: Add another constant as the last one

    Do you see the “TRACE” constant in the DefineConstants node above? That’s not a build configuration!

    This may sound ridiculous, but if even know you still either don’t have the build configuration available on the dropdown OR it doesn’t activate the right parts of your code, try adding another constant in the DefineConstants node.

    TRACE is built-in – you can even add it from Project Options > Build – but you could even just add one called NONSENSE and see if it helps.

    I mean… It did for me.

Ridiculous, right? Hey, that’s how my workarounds often end up. Give it a try and let me know how it goes!

References

mm
5 7 votes
Article Rating
Subscribe
Notify of
guest
0 Comments
Inline Feedbacks
View all comments