Can I pass VisualStudio Edition name through a compiler option?

Question

I am using Microsoft.QualityTools.Testing.Fakes to mock some unit tests.

But this assembly is only available to users with VisualStudio Ultimate.

Users with other editions (Professional) can't build and run this test project, and it gives an error on their environments.

So I have created a compiler directive to deal this:

#define Ultimate

#if Ultimate
using Microsoft.QualityTools.Testing.Fakes;
#endif

And my test method is:

#if Ultimate
    using (ShimsContext.Create())
    {
        ... My code
    }
#else
    Assert.Inconclusive("This test needs VS Ultimate to run");
#endif

This is working great, but a user still needs to comment/uncomment the define line.

So, is there a way to pass my VS Edition to the compiler? Or is there another approach?

Answer 1

Open the csproj in a text editor and, after the last <PropertyGroup> add:

<PropertyGroup Condition=" $(VisualStudioEdition.Contains('Ultimate')) ">
  <DefineConstants>$(DefineConstants);ULTIMATE</DefineConstants>    
</PropertyGroup>

note that I've written the constant in all upper-case, so you'll have to change your code to:

#if ULTIMATE

If you want to future-proof yourself, as suggested by @Damian:

<PropertyGroup Condition=" $(VisualStudioEdition.Contains('Ultimate')) Or $(VisualStudioEdition.Contains('Enterprise')) ">
  <DefineConstants>$(DefineConstants);ULTIMATE</DefineConstants>    
</PropertyGroup>

Note that, as written by @Uwe, these are "hacks"... manually editing csproj is living the risky life :-)

Answer 2

Whilst @xanatos' answer is what you've asked for, I'm going to suggest an alternate approach. You don't have to put all of your tests in the same assembly.

If you put your shimmed tests in a separate assembly to your normal tests then you have the option of either creating another solution (so you have one with the shimmed assembly and one without), or having team members with lower versions of Visual Studio unload the shimmed projects from their solution.

If you were to go down the unloaded project route, then the choice of project's that are unloaded are saved in the solution's ".suo" file (which you shouldn't be putting into source control). This means that the unloaded projects will continue to be unloaded even if new projects are added into the solution.

This is a transparent solution to the problem (so you don't need to worry about the team forgetting how it works in the future), that doesn't require manually editing the project file and doesn't require you to remember to wrap all of your in specific tests in #ifs. Whether or not it would work for your team depends on your overall approach to solution and project structure.