Project-system: Adding a new source file to a Mutli-TF project doesn't correctly populate the editor context navigation bar

[mavasani]

1. Create a C# .net core project
2. Change TF -> TFs and add netstandard1.5 to the list, i.e. change it to <TargetFrameworks>netcoreapp1.0;netstandard1.5<TargetFrameworks>.
3. Open Program.cs and verify both netstandard and netcoreapp show up in the editor context navigation bar
4. Now right click the project in the solution explorer and add a new source file

Expected: New source file also has both netstandard and netcoreapp in the editor context navigation bar

Actual: New source file only has both netcoreapp in the editor context navigation bar

I have a strong feeling this is due to CPS only triggering design time builds only for the active project config.

[mavasani]

I debugged further into this and it seems CPS is indeed triggering design time builds and evaluations for both the configured projects, and we are correctly passing down the newly added source file for both the Roslyn workspace project contexts, but the navigation bar still shows only one project for the new source file.

[mavasani]

Investigated this further, and my previous comment is not fully correct. CPS does trigger an evaluation with newly added source file for both the configured projects, but the PublishTreeAsync invocation here never returns for non-active configured project (netstandard1.5), and hence we never add the newly added source file to the Roslyn Workspace. I believe the fix is to invoke PublishTreeAsync API only if we are dealing with active project context.

[srivatsn]

Let's retarget this to master for now and wait for more feedback about this.

[mavasani]

@srivatsn How about the Roslyn pull requests for #1613 and #1013? Do we want to also retarget them to master?

[srivatsn]

Yes

[fubar-coder]

Really for 15.3 instead of 15.1? This means that .NET Core development in VS will be unusable until update 3. 🙁

[DazFahy]

@fubar-coder There is a way to trick it into working, what you need to do is put a semicolon after the final target so

netcoreapp1.0;netstandard1.5

becomes
netcoreapp1.0;netstandard1.5;

However this causes another issue in that when you add a new class it will only be available for one of the targets. So to get it back for both edit the csproj in visual studio and swap the target framework order around and save it, this will cause it to then apear for all the target frameworks.

[fubar-coder]

This is really not a practical solution, especially when VS suddenly gets the idea that it wants to revert your changes to the csproj (which happens quite often)

[DazFahy]

@fubar-coder It may not be the best solution but it is a workaround, we have been using this since we installed VS 2017 on the 8th March and have had no issues with the change we made to csproj being reverted.

I agree with you in that this should be fixed sooner than the 15.3 milestone as it is an absolute pain, especially when you forget and spend 10 minutes trying to figure out why your code will not compile.

[fubar-coder]

@DazFahy I tested this workaround and it doesn't work. It's the same behaviour as before: After adding a certain amount of class files, I get the Miscellaneous Files instead of the target framework moniker in the editor window and the intellisense doesn't see the new class. Unloading and reloading is the only way to (almost) reliably make the new class available.

IOW: This fix needs to be published ASAP. Otherwise, VS2017 isn't really recommended for library developers targeting multiple frameworks.

EDIT: Saving the newly added class file doesn't fix the problem too.

[mavasani]

Tagging @davkean