Improve "new vs. legacy" project system detection

Both the new and legacy project system’s have a file extension of csproj/vbproj. This means that when a project opened, we need to “sniff” as to whether it needs to open in the new or legacy project system. The existing detection is called out in https://github.com/dotnet/project-system/blob/master/docs/opening-with-new-project-system.md.

This has a pretty major flaw:

• If you move the <TargetFramework> or <TargetFrameworks> elements into an import, we don’t recognize it as an SDK-project and it opens in legacy, which leads to a prompt similar to below.

This prompt occurs because the project file is missing “ToolsVersion” (now optional) which makes the legacy project system think that the project comes from VS 2008 or earlier.

We should improve the detection. The detection must be extremely quick. This will run for every csproj/vbproj. This rules out doing an evaluation to figure out if the project has a <TargetFramework> property somewhere else in its graph, evaluations take anywhere from 10ms to 100ms and currently (due to architecture) it’s extremely difficult to share this evaluation with the project system that ends up opening the project.

I propose, that we change the detection as follows.

In addition to the </TargetFramework> and </TargetFrameworks> detection[1], opt any project that is marked with an SDK, either at the project node, via the <Sdk /> or <Import Sdk=""/> constructs.

This means that following 5 projects will be opt’d into the new project system:

<Project Sdk="Microsoft.Net.Sdk">
...
</Project>

<Project Sdk="Microsoft.Net.Sdk.Web">
...
</Project>

<Project Sdk="MSBuild.Sdk.Extras">
...
</Project>

<Project>
    <Sdk Name="My.Custom.Sdk" Version="1.0.0" />
...
</Project>

<Project>
    <Import Project="Sdk.props" Sdk="Microsoft.NET.Sdk" />
...
</Project>

[1] This makes sure that those that imported the SDK in an import, but left <TargetFramework> or <TargetFrameworks> element to make sure it opened in CPS still continue to open in CPS.

[Rabadash8820]

@drewnoakes I just installed VS 16.4 and can confirm that importing TargetFramework from a Directory.Build.props file is working as advertised. Thanks again!

[ghost]

Excellent, thanks for the quick reply. I can wait for GA with the TargetFramework workaround. Keep up the good work y’all!