Using a ProjectReference which requires AssetTargetFallback to succeed, should warn.

[nguerrera]

Microsoft Visual Studio Enterprise 2017 Int Preview (Dogfood)
Version 15.8.0 Preview 5.0 [27913.3.d15.8]
VisualStudio.15.IntPreview/15.8.0-pre.5.0+27913.3.d15.8
Microsoft .NET Framework
Version 4.7.03056

Repro steps

• Add project reference from .NET Core project to .NET Framework 4.6.1 project
• Restore / Build

Expected

Very similar warning to this for the PackageReference case

Warning NU1701 Package 'XAct.Wintellect.PowerCollections 0.0.1' was restored using '.NETFramework,Version=v4.6.1' instead of the project target framework '.NETCoreApp,Version=v2.1'. This package may not be fully compatible with your project. ConsoleApp30 C:\Users\nicholg\source\repos\ConsoleApp30\ConsoleApp30\ConsoleApp30.csproj 1

Actual

No warning

This defeats the rationale for why it was deemed OK to make the net461 asset target fallback a default.

cc @rrelyea @mishra14 @rainersigwald @dsplaisted @terrajobst

[mishra14]

@nguerrera currently, msbuild passes us a project tfm and a set of tfms to check compatibility and we return a bool indicating success or failure. We will need to work with @rrainersigwald to change that if needed.

@rrelyea had scenarios (wpf + uwp) where such P2P references make sense without the need for warnings.

[nguerrera]

You could log a warning from the task. We spent a lot of time talking about this for package refs and the warning was a big part of pulling the trigger on the AssetTargetFallback default. I don't see how it could be any different for projects, but I'm listening.

[nguerrera]

I would like this to be considered for 15.8 because I don't want to end up in a situation where we decide not to make a "breaking change" to add the warning that should always have been there.

[nguerrera]

cc @DamianEdwards

[terrajobst]

I'm surprised to learn this actually works as I was under the impression that this will fail. We must at the very least issue a warning as @nguerrera suggests.

However, I believe our original design asked for this to be an error. The rationale being that the NuGet case is for references outside your control while P2Ps are expected to be under your control and we want to force developers to convert/modernize from the bottom up. However, I understand that making this an error now would be breaking change. But I don't think silent success here is acceptable behavior.

[nguerrera]

However, I understand that making this an error now would be breaking change.

This is new in 15.8 so technically hasn't shipped. I think there should be a way to do this with project references, I just don't think it should happen without any diagnostics.

[terrajobst]

This is new in 15.8 so technically hasn't shipped. I think there should be a way to do this with project references, I just don't think it should happen without any diagnostics.

That's fair. Not sure I wholeheartedly agree, but I could live with a warning, consistent with the NuGet experience. But silence is bad.

[mishra14]

tagging @rrelyea for 4.8 visibility.