Project-system: Task List does not populate for the Common Project System SLN Guid

[AdamDotNet]

Visual Studio Version: 16.1.1

Summary: Task List does not populate for the Common Project System SLN Guid. Developer Community Link

Steps to Reproduce:

1. Create a new .Net Core Template project, such as Asp.Net Core project, with the C# language.

2. Add a // TODO comment to a couple of files, such as Startup.cs, and Program.cs.

3. Observe that the Task List window is populating as you type them.

4. Close and reopen VS. You'll notice VS auto populates the Task List window still. This is correct behavior.

5. Open the SLN file in a text editor, observe that your project type guid is Legacy Project Type FAE04EC0-301F-11D3-BF4B-00C04F79EFBC.

6. In VS, right click -> Add -> Solution Folder, call it whatever you like, such as Solution Items

7. Close and reopen VS. You'll notice VS does not auto populate the Task List window anymore. This is wrong.

8. Open a file containing a // TODO comment. Task List will populate with just that comment, but not any other comments in any other file.

9. Leave that file open, make sure VS is set to restore open documents from previous session, and relaunch VS. You'll notice VS auto populates the Task List window now. It's seemingly only populating Task List because a file containing a // TODO comment was open at launch. This is the only workaround I know of.

10. Open the SLN file in a text editor, observe that your project type guid was changed to Common Project System 9A19103F-16F7-4668-BE54-9A1E7A4F7556.

11. Change the Guid from 9A19103F-16F7-4668-BE54-9A1E7A4F7556 to FAE04EC0-301F-11D3-BF4B-00C04F79EFBC. Reopen VS and regardless as to whether or not a file containing a // TODO comment is opened at launch, the Task List window will auto populate as expected.

Expected Behavior: Task List window auto populates when the SLN file has the Common Project System Guid instead of the Legacy Project Type Guid in it, regardless of if I have files with comments in them open at launch or not.

Actual Behavior: When no files are set to open at VS launch, Task List is not populated, the Task List window will see items as you open files with the comments in them, but never shows all of them. When there is a file containing a comment in it opens at VS launch, then the Task List window works as expected.

User Impact: Task List window helps users find what work they have temporarily set aside. That work may be forgotten if the Task List window doesn't populate, and poor or incomplete code may potentially never be addressed.

Appendix
SLN file before adding Solution Items.

Microsoft Visual Studio Solution File, Format Version 12.00
# Visual Studio Version 16
VisualStudioVersion = 16.0.28922.388
MinimumVisualStudioVersion = 10.0.40219.1
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "WebApplication2", "WebApplication2\WebApplication2.csproj", "{F579B70A-02A1-4100-8706-5592EB3B1624}"
EndProject
Global
    GlobalSection(SolutionConfigurationPlatforms) = preSolution
        Debug|Any CPU = Debug|Any CPU
        Release|Any CPU = Release|Any CPU
    EndGlobalSection
    GlobalSection(ProjectConfigurationPlatforms) = postSolution
        {F579B70A-02A1-4100-8706-5592EB3B1624}.Debug|Any CPU.ActiveCfg = Debug|Any CPU
        {F579B70A-02A1-4100-8706-5592EB3B1624}.Debug|Any CPU.Build.0 = Debug|Any CPU
        {F579B70A-02A1-4100-8706-5592EB3B1624}.Release|Any CPU.ActiveCfg = Release|Any CPU
        {F579B70A-02A1-4100-8706-5592EB3B1624}.Release|Any CPU.Build.0 = Release|Any CPU
    EndGlobalSection
    GlobalSection(SolutionProperties) = preSolution
        HideSolutionNode = FALSE
    EndGlobalSection
    GlobalSection(ExtensibilityGlobals) = postSolution
        SolutionGuid = {AA0FCE5B-CB21-4C43-8186-1DC7332943CB}
    EndGlobalSection
EndGlobal

SLN file after adding Solution Items.

Microsoft Visual Studio Solution File, Format Version 12.00
# Visual Studio Version 16
VisualStudioVersion = 16.0.28922.388
MinimumVisualStudioVersion = 10.0.40219.1
Project("{9A19103F-16F7-4668-BE54-9A1E7A4F7556}") = "WebApplication2", "WebApplication2\WebApplication2.csproj", "{F579B70A-02A1-4100-8706-5592EB3B1624}"
EndProject
Project("{2150E333-8FDC-42A3-9474-1A3956D46DE8}") = "Solution Items", "Solution Items", "{8EBC4356-9D75-4D31-A6AB-A8202863EE67}"
EndProject
Global
    GlobalSection(SolutionConfigurationPlatforms) = preSolution
        Debug|Any CPU = Debug|Any CPU
        Release|Any CPU = Release|Any CPU
    EndGlobalSection
    GlobalSection(ProjectConfigurationPlatforms) = postSolution
        {F579B70A-02A1-4100-8706-5592EB3B1624}.Debug|Any CPU.ActiveCfg = Debug|Any CPU
        {F579B70A-02A1-4100-8706-5592EB3B1624}.Debug|Any CPU.Build.0 = Debug|Any CPU
        {F579B70A-02A1-4100-8706-5592EB3B1624}.Release|Any CPU.ActiveCfg = Release|Any CPU
        {F579B70A-02A1-4100-8706-5592EB3B1624}.Release|Any CPU.Build.0 = Release|Any CPU
    EndGlobalSection
    GlobalSection(SolutionProperties) = preSolution
        HideSolutionNode = FALSE
    EndGlobalSection
    GlobalSection(ExtensibilityGlobals) = postSolution
        SolutionGuid = {AA0FCE5B-CB21-4C43-8186-1DC7332943CB}
    EndGlobalSection
EndGlobal

[davkean]

The underlying cause of this is https://github.com/dotnet/roslyn/issues/35514.

[davkean]

As a side note, @AdamDotNet thank-you for the great repro on this - I appreciate it a lot, helped me track down it was duplicate almost immediately.

[AdamDotNet]

@davkean - Happy to be helpful! If you don't mind satisfying my curiosity, do you know why the templates create an SLN with the legacy Guid instead of the CPS one, and why certain VS actions actually change that Guid over? Do things not work if the legacy Guid is in place when using the CPS csproj format?

[davkean]

The underlying issue is caused by us skipping an initialization path inside the Roslyn package.

The legacy GUID causes us to hit a path in the legacy project system in which in determines if it should load in legacy or load in the new project-system. This code lives in legacy to avoid loading additional dlls on paths that don't use the new project system. This path triggers the loading of the Roslyn package. The new GUID causes us to immediately load in the new project system, skipping the legacy path.

[davkean]

It was regressed during some performance optimizations, loading the Roslyn package caused a significant slow down in the new project system, especially given it had UI-thread dependencies. We overlap loads of projects in the new project system and they were all being blocked by this dependency on the UI thread, we removed that but missed this case where it was needed. We're taking a different approach to fix that situation.

[drewnoakes]

@davkean I think an aspect of @AdamDotNet's question is "why don't the templates use the new GUID for new csproj files?" I realise that I'm unclear on why this is and would like to know. Is there a reason against using the new project system's GUIDs?

[davkean]

Templates don't have GUIDs; VS sees the "csproj" extension and looks up legacy's GUID which goes through the "selector" and eventually over to the new project system.

The new GUID was supposed to be an implementation detail - the plan from day 0 was to take over everything that legacy did, including the "project type" (the GUID). In fact, other than persistence in the solution - the new project system pretends that it is the legacy project system via the various APIs that return this GUID.

[davkean]

This bug has been fixed and will appear in the RTM of 16.2.

[davkean]

My mistake, it appears to have missed 16.2, and will be in 16.3 Preview 2.