Editor doesn't handle conditional compilation symbol with netstandard or .net core

[natidea]

From VSFeedback | 484140

Create either a Netstandard or Net Core project and put this code in the class:

#if DEBUG
public static int I = 5;
#else
public static int I = 6;
#endif

Second statement (#else) will be correctly grayed out.
Change configuration to Release.

Expected: first statement is grayed out.

Actual: second is still grayed out.

Note: Sometimes it picks the change but then gets stuck again to that. Compiler works properly.

In general these changes are not reflected in the editor until you reload the project.

[EPinci]

Guy, this is a serious nightmare to work on with for everybody who's relying on compilation symbols.
It probably won't warrant a QFE for 15.3 but can you, please, reconsider it and bump it up to 15.4? Thank you.

[matiii]

In 15.4 still doesn't work

[MihaMarkic]

Milestone 15.6? Seriously? :(

[andreujuanc]

This should have gotten bigger priority. Unloading and Reloading a project just to change what compilation symbols are picked up is, as @EPinci said, a nightmare.

[ericbrunner]

Just added my own debug symbols DEV, STAGE and PROD. What is that f..... automatically added DEBUG_* and RELEASE_* and how to turn that off? Thanks in advance.

<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug|AnyCPU'">
    <DefineConstants>TRACE;DEBUG;DEV;NETSTANDARD1_4</DefineConstants>
  </PropertyGroup>

  <PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug-PROD|AnyCPU'">
    <DefineConstants>TRACE;PROD;DEBUG_PROD;NETSTANDARD1_4</DefineConstants>
  </PropertyGroup>

  <PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug-STAGE|AnyCPU'">
    <DefineConstants>TRACE;STAGE;DEBUG_STAGE;NETSTANDARD1_4</DefineConstants>
  </PropertyGroup>

  <PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Release-DEV|AnyCPU'">
    <DefineConstants>TRACE;DEV;RELEASE_DEV;NETSTANDARD1_4</DefineConstants>
  </PropertyGroup>

  <PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug-DEV|AnyCPU'">
    <DefineConstants>TRACE;DEV;DEBUG_DEV;NETSTANDARD1_4</DefineConstants>
  </PropertyGroup>

  <PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Release|AnyCPU'">
    <DefineConstants>TRACE;PROD;RELEASE;NETSTANDARD1_4</DefineConstants>
  </PropertyGroup>

  <PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Release-STAGE|AnyCPU'">
    <DefineConstants>TRACE;STAGE;RELEASE_STAGE;NETSTANDARD1_4</DefineConstants>
  </PropertyGroup>

[rollsch]

I stopped using netcore literally because of how annoying this is.

[MihaMarkic]

Guys, please don't pollute this topic, rather open a new one (@ericbrunner)
Update: changed typo guts to guys.

[rollsch]

Why would we open a new one? We are discussing how his issue seems to have been ignored despite it being something we have to manually correct every day.

[ericbrunner]

@MihaMarkic All I mentioned is all regarding that issue. So what's the problem? I refrenced the related issue (#2720)

[MihaMarkic]

@ericbrunner I didn't mean no offence, calm down. Original issue is about syntax coloring not changing when condition changes. Yours, at least to me, is a different issue. But perhaps I'm wrong.

[MihaMarkic]

Oh, and sorry, I meant "guys", not "guts", mobile autocorrect did change it :(

[ericbrunner]

@MihaMarkic Ok.

[davkean]

This issue is around the language service not handling the switch from debug -> release. This is a large work item that is being worked on as we speak; #3020, #3032 and #3060 are all parts of the building blocks to enable this. Once these are in, we can start consuming them from the language service host and handle this case.

The duplicate condition constants issue is being tracked by #2720.

[Pilchie]

Unfortunately due to the size and risk of these changes, they are not going to make 15.6, though we hope to land them in an early 15.7 change so that we have time to vet them.

[OmegaPrimeZ3]

So the IDE is not updating the greying out visually when changing build configs. My question is whether it is getting respected during compile time. Is this a visual only issue or visual and it will not correctly compile?

[jmarolf]

@OmegaPrimeZ3 the option will be respected at compile time. This is about passing all the correct data through to the IDE so that it is updated.

[hvaughan3]

For us the options are not respected at run time.

…

On Fri, Jan 26, 2018 at 7:26 PM, Jonathon Marolf ***@***.***> wrote: @OmegaPrimeZ3 <https://github.com/omegaprimez3> the option will be respected at compile time. This is about passing all the correct data through to the IDE so that it is updated. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#2733 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGKtPFs_6PbU_bzAKJKEwhg8KFBDmYlQks5tOnstgaJpZM4PCFSJ> .

[MihaMarkic]

@hvaughan3 Are you sure? That'd be really terrible.

[davkean]

This occurs with the new project system targeting any framework. The legacy project does not suffer from this problem.

[raffaeler]

@davkean are you going to provide the fix for VS2017 right?
I have a large customer who will not be able to jump on VS2019 before a very long time and this issue risk to block him (since it is now migrating on the new project system).

[AdamDotNet]

@raffaeler

It's not something we turn on without a lot of risk mitigation, regression and performance testing, something we didn't feel confident we could land in a minor update.

I interpret that as nope, will never work in 15.x, because VS 2017 will always be 15.x, and a minor update won't change this behavior, as @davkean said. I'm sure he'll correct me if I'm wrong though.

It's encouraging to see this fix soon be merged into master. The ReadMe.md seems to suggest the master branch = preview 2 though, so a tad more waiting to go than just the first preview. However, the light at the end of the tunnel is there! Thank you.

[raffaeler]

@AdamDotNet they will get vnext in 2 years and get some external tool to fix that. Bad but that's the way it works in many industries.

[MihaMarkic]

Well, VS 2019 should be in 1Q 2019 I guess, not in two years. However, this fix has targeted 15.9 (the latest tag, before that was 15.8, 15.7, etc.). If it really targets VS2019 that means at least another half year or so, which is a long time. But hey, we've been waiting for, what, 14 months now?

[raffaeler]

@MihaMarkic Two years is the latency for corps in adopting the major releases tools. While I don't like it, there are good reasons for that.

[MihaMarkic]

@raffaeler Ah, that. Yep, it can be even longer timespan.

[Haplois]

Milestone changed, again... I wonder when this will be fixed.

[smokja]

Is there really no better way than reloading the project? This really annoys me

[scottieslg]

@davkean, glad you're working on this! It has been such an irritation for a long time! Good work!

[ghost]

I was surprised that the problem was not solved in Visual Studio 2017 15.9.11 (ASP.NET Core 2.2).
It is an important feature.

[MihaMarkic]

@Garfie2016
Look at the original report date and be happy that at least it seems solved in VS2019 though. I might have seen improperly colored syntax in VS2019 once so far though.

[kuklei]

I have a solution in VS 2017 15.9.38 and the issue still appears. It affects not only the editor but also the compiler which is ignoring the '#if' compiler directive. Any solution

[jerhewet]

I don't know why this is closed, since conditional compilation still isn't working in .Net Core. I'm running Visual Studio 2022 17.3.6, building against .NET 6, and no matter what I try with configurations the #if / #endif defines still do nothing at all.

Even explicitly defining the constants using PropertyGroup and DefineConstants in the project file does nothing.

[drewnoakes]

@jerhewet this issue is about the display of conditional compilation in the IDE rather than what happens at compile time. You would have to provide more information for us to help you. Please open a new issue. Thanks.