Roslyn: The project context navigation bar doesn't cause classification to update.

Created on 18 Sep 2015  Â·  16Comments  Â·  Source: dotnet/roslyn

Short project setup (internal only):

  1. Copy the Closed\Test\Files\SharedProjectCS directory from our internal sources to another location (e.g., Desktop.)
  2. Open TestProj.sln.
  3. Open Class2.cs from the shared project.

Long project setup (manual):

  1. Create a new Windows app.
  2. Add a new WindowsPhone app to the solution.
  3. Add a shared project to the solution that both Windows and WindowsPhone apps reference.
  4. Add a file to the shared project with the body:

C# namespace TestNamespace { public class TestClass { #if WINDOWS_PHONE_APP public void PhoneMethod(bool b) { } #elif WINDOWS_APP public void WinMethod(int i) { } #endif } }

Rest of the repro steps:

  1. With the shared file open, verify that changing the project context navigation bar causes the classification inside the #if/#elif/#endif block to change.
  2. Close the shared file.
  3. Re-open the shared file.
  4. Change the project context navigation bar.

Result:
The classification no longer changes.

_(This failure is visible in the internal-only CSharpSharedProjects integration test.)_

Area-IDE Bug Disabled Test Urgency-Soon

Most helpful comment

Echoing Oren here, in getting this every day and it's extremely annoying. It turns Visual Studio into notepad for the #ifdef sections that it bugs on. Please give this bug the severity of the impact it has.

All 16 comments

This used to work. Did your recent tagger changes lose the event that fires this here.

I don't think this shouldn't be related to anything I did. First, the syntactic classifier is its own little tagger microcosm. It's all hand written and doesn't use any of the normal tagger infrastructure. Second, the semantic classifier still listens for OnDocumentActiveContextChanged (which I presume is the event that tells you when the project context changes).

I'll have to investigate to figure out what's going on here.

It looks like our test is using old constants and needs to be updated to use WINDOWS_UWP instead of WINDOWS_APP and I can work on that, but there's still the issue where after re-opening the shared file, switching the context dropdown doesn't cause the #regions to be updated until the file is closed and re-opened.

We've been looking at this a bit, and think that David has more context

I aready created a fix and test FYI :)

A bunch of things aren't getting cleaned up when a shared file is closed, including the Workspace's _bufferToDocumentInCurrentContextMap. A quickly thrown together _bufferToDocumentInCurrentContextMap cleaning mechanism does make this repro work correctly. The known HierarchyEventSink proliferation problem is also involved here in a way that causes multiple workspace events when the context is triggered, but just fixing _bufferToDocumentInCurrentContextMap makes sure those repeated events fire with the right Document. We'll need to fix both issues soon, but the _bufferToDocumentInCurrentContextMap is more urgent as it has obvious customer impact.

Please note that CSharpSharedProjects is currently disabled because of this.

From internal bug 194709:

Here’s a repro in VS 2015 Update 1:

  1. Open a solution that has a shared project used by two platforms
  2. Open a shared file, select “platform A” at the top of the editor window
  3. Close that editor window
  4. Build the solution in a way that the compilation output window has error in a shared file, for the platform that was not selected at step 2 (Platform B)
  5. Open the shared file by double clicking the line in the output window
  6. The editor window should open by default in “Platform A”
  7. Try changing to “platform B”, then click in the editor’s text zone
  8. Notice that the platform selector reverts back to “Platform A”

Note: This also affects cross targeting CPS projects- we need to fix this for RC.2. @srivatsn

Moving to 2.1 as we still haven't heard feedback about this.

The internal bug 194709 is also from external feedback.

I see that this bug is pretty old. I realize it's too late for 2017 RTM but please don't keep pushing it back, please see if you can get it into the first update.

It makes it really hard to work with multi-targeted projects when the context is missing.

Echoing Oren here, in getting this every day and it's extremely annoying. It turns Visual Studio into notepad for the #ifdef sections that it bugs on. Please give this bug the severity of the impact it has.

Marking as Urgency soon, we have got large number of feedback requests about this.

@dpoeschl I investigated this further and have a working fix. I am going to grab this bug from you and request a PR review from you :)

Was this page helpful?
0 / 5 - 0 ratings

Related issues

MgSam picture MgSam  Â·  152Comments

gafter picture gafter  Â·  147Comments

gafter picture gafter  Â·  279Comments

MadsTorgersen picture MadsTorgersen  Â·  120Comments

Pilchie picture Pilchie  Â·  113Comments