Project-system: VS2017 pops the migration dialog when TargetFramework is inherited from props

[am11]

Steps to repro:

• Create a new .NET Standard Library project in VS2017

• Modify the csproj file as below:

  <Project Sdk="Microsoft.NET.Sdk">
  
  +  <Import Project=".\MyProps.props" Condition="Exists('.\MyProps.props')" />
  -  <PropertyGroup>
  -    <TargetFramework>netstandard1.4</TargetFramework>
  -  </PropertyGroup>
  
  </Project>
  

• Create a file called MyProps.props in the same directory as csproj with the following content:

  <Project>
  
  <PropertyGroup>
    <TargetFramework>netstandard1.4</TargetFramework>
  </PropertyGroup>
  
  </Project>
  

• Reload the solution

Expected behavior

Nothing pops up

Actual behavior

It flags the csproj for migration:

Other notes

Running

dotnet build

:: or

"%ProgramFiles(x86)%\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin\MSBuild"

in CMD from solution directory builds the solution just fine (0 errors, 0 warnings).

[tannergooding]

This is very similar to https://github.com/dotnet/roslyn-project-system/issues/1358. @srivatsn commented

Currently, we require the TargetFramework property to be defined in the project to know to load with cps instead of old project system. So your final project is being loaded with the old project system. If you add the TF property to the project this should work fine.

[tannergooding]

Also listed in the bug is a 'workaround', which is to manually set the project type in the solution.

This won't work for loading just a singular project and it will stop working if you remove and then re-add the project to the solution.

[am11]

Thanks @tannergooding, your GUID workaround is neat (despite redoing the process after remove->readd project caveat)! 😎
Can the CpsOrNot scan be enhanced in a way that it first tries to locate the TargetFramework(s) property in the current project, if not found then walk the import graph and short-circuit on the first discovery?

[am11]

Shall we close this issue as a duplicate? (Shamelessly) this one has simpler steps to repro. 😸

[davkean]

This work is being tracked by https://github.com/dotnet/roslyn-project-system/issues/547.

[skarllot]

One work-around is adding a dummy TargetFrameworks tag to CSPROJ file:

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFrameworks>$(TargetFrameworks)</TargetFrameworks>
  </PropertyGroup>

</Project>

[davkean]

Alternatively, change the GUIDs in the solution: https://github.com/dotnet/project-system/blob/master/docs/opening-with-new-project-system.md#project-type-guids.

[mikeparker]

We are seeing this behaviour (Visual Studio popping up a migration dialog when removing/re-adding a project) when referencing the TargetFramework from Directory.Build.props still but https://github.com/dotnet/project-system/issues/547 is closed as fixed - can you confirm if we need the workarounds i.e. define the target framework in every project file, change the guid manually etc? Is it wont fix? Or is the Directory.Build.props a separate issue?

[davkean]

@mikeparker Good point, that bug was underneath really tracking the work to make our configuration-system logic see <TargetFrameworks/> in an import. Unfortunately due to performance reasons, we can't change our detection logic to read <TargetFramework/>/<TargetFrameworks/> in an import (it will slow every project load by 10ms - 200ms), but I've filed https://github.com/dotnet/project-system/issues/4314 to track improving the detection logic to so that you can move <TargetFramework/> or avoid updating the GUID in the solution.