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?

(Prerequisite) Make sure you have added an additional configuration
This guide presumes you’ve already created the configuration from the Configurations -dropdown:
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”.
Make sure your configurations exist in the project file
Should be one of the first things in the file:

If not, feel free to add them – because they really do need to be there :)
Make sure your build constants exist in the project file
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” ? 😁
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

Microsoft’s documentation that doesn’t really help you here although it probably should:
- https://docs.microsoft.com/en-us/visualstudio/ide/how-to-create-and-edit-configurations?view=vs-2019

Author
Recent Posts

Antti K. Koskela

Developer / Speaker / Consultant at Koskila / Precio Fishbone / Norppandalotti Software Co / Alter - Experience Ideas Ltd

Antti Koskela is a proud digital native nomadic millennial full stack developer (is that enough funny buzzwords? That's definitely enough funny buzzwords!), who works as Solutions Architect for Precio Fishbone, building delightful Digital Workplaces.

He's been a developer from 2004 (starting with PHP and Java), and he's been working on .NET projects, Azure, Office 365, SharePoint and a lot of other stuff. He's also Microsoft MVP for Azure.

This is his personal professional (e.g. professional, but definitely personal) blog.

Latest posts by Antti K. Koskela (see all)