Sdk: P2Ps should be allowed when ReferenceOutputAssembly=false even given TFM incompatibilities

[AArnott]

With VS2015 projects, I can have a P2P from a portable library to a net46 library by setting metadata on the project reference:

<ProjectReference Include="..\SomeNet46Lib\lib.csproj">
  <ReferenceOutputAssembly>false</ReferenceOutputAssembly>
</ProjectReference>

But with the .NET SDK projects, even with this metadata the build fails:

C:\Program Files (x86)\Microsoft Visual Studio\2017\d15rel\MSBuild\Sdks\Microsoft.NET.Sdk\build\Microsoft.NET.Sdk.Common.targets(73,5): error : Project 'C:\git\pinvoke\src\CodeGeneration\CodeGeneration.csproj'
targets '.NETFramework,Version=v4.6'. It cannot be referenced by a project that targets '.NETPortable,Version=v0.0,Profile=Profile92'. [C:\git\pinvoke\src\CodeGeneration\CodeGeneration.csproj]

This blocks scenarios where a P2P exists merely for the sake of ensuring build ordering but without the assembly reference. In my particular scenario, the referenced project provides a binary that the build of the portable library picks up for code generation purposes.

[nguerrera]

Workaround: Try also adding SkipGetTargetFrameworkProperties=true metadata to the reference.

[AArnott]

Thanks @nguerrera. But that doesn't work either. That causes a referencing project A to build the referenced project B per A's TargetFramework value instead of B's TargetFramework.

[nguerrera]

Ah, I believe this would only happen if A is multi targeted. Is it?

Try adding UndefineProperties="TargetFramework" metadata as well.

[AArnott]

Yes, A is multi-targeted.
And that additional metadata did the trick. Thanks.

Should we leave the issue active for making this scenario simpler, and/or work the way it used to?

[nguerrera]

Should we leave the issue active for making this scenario simpler, and/or work the way it used to?

Yes, this should work without the extra metadata.

[AArnott]

This is badly broken. The workaround causes nuget restore to fail in VS (command line is fine) and also is related to a build failure that only occurs on some non-Windows machines including Travis CI Ubuntu.

I tried replacing this with a "project dependency" encoded in the solution file, and that fixed most of the symptoms, until I tried msbuild.exe my.sln when I learned that msbuild translates that solution dependency into a project reference during the build (@andygerlicher when did this feature get added?), with ReferenceOutputAssembly=false set (just as I wanted to do with my original ProjectReference item) and that of course repeats the original problem and the build fails because a net40 project can't depend on a netstandard1.5 project.

This inability to influence build ordering is really causing some pain here. Please fix soon!

[Sumo-MBryant]

Has anyone found a workaround that is close to successful?

For a minimal netstandard1.X project reference to a netcoreapp1.X project:

SkipGetTargetFrameworkProperties fails in GenerateDepsFile (https://github.com/dotnet/sdk/issues/1020)

Interestingly enough when I restore and build from MSBuild directly the project.assets.json file is missing the project reference and builds successfully. When building from Visual Studio, the project.assets.json contains the reference with a broken framework "framework": "Unsupported,Version=v0.0" and fails to build.

[AArnott]

No. I finally gave up and checked the binary into git so I didn't need a project reference. I tried for days but never found a way that got dotnet build, msbuild, and VS to all work correctly at once. 😦

[rainersigwald]

This can be worked around by adding an outside-the-norm order dependency in MSBuild, by way of a custom call to the MSBuild task.

<Target Name="WorkaroundSdk939" BeforeTargets="ResolveProjectReferences">
  <MSBuild Project="..\..\the\other.csproj" />
</Target>

Note that depending on your specific needs, you might need to be careful to preserve configuration and other normally-handled-for-you properties, or call a specific target.

@AArnott

msbuild translates that solution dependency into a project reference during the build (@AndyGerlicher when did this feature get added?)

This appears to have been added to MSBuild in the dev11 timeframe. @cdmihai went into detail on the process in https://github.com/Microsoft/msbuild/issues/2274#issuecomment-314850707. The current team doesn't know why it's necessary.

[AArnott]

Note that depending on your specific needs, you might need to be careful to preserve configuration and other normally-handled-for-you properties, or call a specific target.

Ya, that's what kills your proposed workaround in virtually all my scenarios. That would build the default configuration of the project, which could mean building all the target frameworks in debug mode, which is almost never what I would expect or need. Also, it would cause over-build, compiling twice etc. which can at least slow down the build, but also lead to symbols and DLLs not always matching up. It's a non-starter for me.
I've tried being very particular about passing in the right global properties to this call, but I guess there's a reason the ResolveProjectReferences target and its predecessors are so complicated. It's very hard to mimic.

[rainersigwald]

@mhutch came up with an interesting workaround in https://github.com/Microsoft/msbuild/issues/2399#issuecomment-320470235:

<!-- workaround for https://github.com/Microsoft/msbuild/issues/2399 -->
<Target Name="WorkaroundMSBuildIssue2399" BeforeTargets="GetTargetFrameworkProperties">
  <PropertyGroup>
    <ReferringTargetFramework>$(TargetFramework)</ReferringTargetFramework>
  </PropertyGroup>
</Target>

In the referenced project.

That essentially disables the target-framework compatibility check for the referenced project, which could be somewhat dangerous (depending on the nature of other references to the project) but avoids this problem.

[rainersigwald]

Workaround

Set

<AddSyntheticProjectReferencesForSolutionDependencies>false</AddSyntheticProjectReferencesForSolutionDependencies>

in the project that has the ProjectReference to the incompatible project. This prevents the elevation of solution build dependencies to ProjectReferences in AssignProjectConfiguration.

(Was poking around near this target for another reason and saw this.)

[nguerrera]

Moving to msbuild because after the double-evaluation fix, this compatibility check happens there in the context of the caller.

[nguerrera]

This issue was moved to Microsoft/msbuild#2661