Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
natidea opened this issue Aug 25, 2017 · 99 comments

Comments

Projects
@natidea
Copy link
Contributor

commented Aug 25, 2017

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.

@natidea natidea added the Bug label Aug 25, 2017

@davkean davkean self-assigned this Sep 4, 2017

@davkean davkean added this to the 15.5 milestone Sep 4, 2017

@EPinci

This comment has been minimized.

Copy link

commented Sep 15, 2017

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

This comment has been minimized.

Copy link

commented Oct 14, 2017

In 15.4 still doesn't work

@Pilchie Pilchie modified the milestones: 15.5, 15.6 Oct 17, 2017

@MihaMarkic

This comment has been minimized.

Copy link

commented Oct 20, 2017

Milestone 15.6? Seriously? :(

@andreujuanc

This comment has been minimized.

Copy link

commented Dec 3, 2017

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

This comment has been minimized.

Copy link

commented Dec 17, 2017

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>
@rolandh

This comment has been minimized.

Copy link

commented Dec 17, 2017

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

@MihaMarkic

This comment has been minimized.

Copy link

commented Dec 18, 2017

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

@rolandh

This comment has been minimized.

Copy link

commented Dec 18, 2017

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

This comment has been minimized.

Copy link

commented Dec 18, 2017

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

@MihaMarkic

This comment has been minimized.

Copy link

commented Dec 18, 2017

@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

This comment has been minimized.

Copy link

commented Dec 18, 2017

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

@ericbrunner

This comment has been minimized.

Copy link

commented Dec 18, 2017

@davkean

This comment has been minimized.

Copy link
Member

commented Dec 18, 2017

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

This comment has been minimized.

Copy link
Member

commented Jan 10, 2018

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

This comment has been minimized.

Copy link

commented Jan 26, 2018

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

This comment has been minimized.

Copy link
Member

commented Jan 27, 2018

@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

This comment has been minimized.

Copy link

commented Jan 27, 2018

@MihaMarkic

This comment has been minimized.

Copy link

commented Jan 27, 2018

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

@davkean

This comment has been minimized.

Copy link
Member

commented Nov 14, 2018

Just to show that I was serious when I said this was being actively worked on, here's a quick demo of some private bits I have from the LanguageServices branch:

configswitch

@MihaMarkic

This comment has been minimized.

Copy link

commented Nov 14, 2018

@davkean How do we know that's .NET Core code :-P
Fun aside, personally I don't doubt you are working on it, it's just that this issues is dragging for more than a year. And it will still take time...

@davkean

This comment has been minimized.

Copy link
Member

commented Nov 14, 2018

Lol. Two ways; look at the template and look at the play button in the toolbar. Legacy uses "Start".

@raffaeler

This comment has been minimized.

Copy link

commented Nov 14, 2018

@davkean off topic, but I really would like a start button next to the project name in the solution explorer. That would be really helpful imho.
Sent the wish several times, but bumped.

@andersforsgren

This comment has been minimized.

Copy link

commented Nov 14, 2018

@davkean is the title correct for this issue? A quick test showed it to be an issue with any framework, not just core/standard.

@davkean

This comment has been minimized.

Copy link
Member

commented Nov 14, 2018

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

@raffaeler

This comment has been minimized.

Copy link

commented Nov 14, 2018

@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

This comment has been minimized.

Copy link

commented Nov 14, 2018

@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

This comment has been minimized.

Copy link

commented Nov 14, 2018

@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

This comment has been minimized.

Copy link

commented Nov 14, 2018

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

This comment has been minimized.

Copy link

commented Nov 14, 2018

@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

This comment has been minimized.

Copy link

commented Nov 14, 2018

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

@Pilchie Pilchie modified the milestones: 15.9, 16.0 Nov 15, 2018

@Haplois

This comment has been minimized.

Copy link

commented Nov 15, 2018

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

@smokja

This comment has been minimized.

Copy link

commented Nov 19, 2018

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

@scottieslg

This comment has been minimized.

Copy link

commented Nov 24, 2018

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

@Garfie2016

This comment has been minimized.

Copy link

commented Apr 5, 2019

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

This comment has been minimized.

Copy link

commented Apr 5, 2019

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.