msbuild: P2Ps should be allowed when ReferenceOutputAssembly=false even given TFM incompatibilities
From @AArnott on March 3, 2017 18:40
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.
Copied from original issue: dotnet/sdk#939
About this issue
- Original URL
- State: open
- Created 7 years ago
- Reactions: 8
- Comments: 30 (25 by maintainers)
Commits related to this issue
- Skip tf-compat checks for solution dependencies Explicitly opts synthetic project references injected by solution dependencies out of the TargetFramework-compatibility/find-best-match dance institute... — committed to rainersigwald/msbuild by rainersigwald 6 years ago
- No tfcompat check if ReferenceOutputAssembly=false It is confusing to explicitly specify that you _don't_ want the output of another project referenced in this project and then be told that the outpu... — committed to rainersigwald/msbuild by rainersigwald 6 years ago
- No tfcompat check if ReferenceOutputAssembly=false It is confusing to explicitly specify that you _don't_ want the output of another project referenced in this project and then be told that the outpu... — committed to rainersigwald/msbuild by rainersigwald 6 years ago
- No tfcompat check if ReferenceOutputAssembly=false (#2867) It is confusing to explicitly specify that you _don't_ want the output of another project referenced in this project and then be told that ... — committed to dotnet/msbuild by rainersigwald 6 years ago
- No tfcompat check if ReferenceOutputAssembly=false (#2867) It is confusing to explicitly specify that you _don't_ want the output of another project referenced in this project and then be told that ... — committed to radical/msbuild by rainersigwald 6 years ago
- Revert "No tfcompat check if ReferenceOutputAssembly=false (#2867)" This reverts commit 91c86a746b312fce1aba31f8fb8540e949c11a01. Fixes #2922 but undoes the fix for #2661. — committed to rainersigwald/msbuild by rainersigwald 6 years ago
- Revert "No tfcompat check if ReferenceOutputAssembly=false (#2867)" (#2935) This reverts commit 91c86a746b312fce1aba31f8fb8540e949c11a01. Fixes #2922 but undoes the fix for #2661. — committed to dotnet/msbuild by rainersigwald 6 years ago
- [Build] Workaround for solution dependencies with incomptable frameworks: https://github.com/Microsoft/msbuild/issues/2661#issuecomment-338808156 # Original commit: '0a018e90ad3bf68c273597d3c76802f2... — committed to SiliconStudio/xenko by xen2 6 years ago
- Skip tf-compat checks for solution dependencies Explicitly opts synthetic project references injected by solution dependencies out of the TargetFramework-compatibility/find-best-match dance institute... — committed to rainersigwald/msbuild by rainersigwald 6 years ago
- Use solution dependencies instead Workaround for https://github.com/Microsoft/msbuild/issues/2661 — committed to Particular/NServiceBus by bording 6 years ago
- Skip tf-compat checks for solution dependencies (#3315) Explicitly opts synthetic project references injected by solution dependencies out of the TargetFramework-compatibility/find-best-match dance... — committed to dotnet/msbuild by rainersigwald 6 years ago
- Work around https://github.com/microsoft/msbuild/issues/2661 — committed to Faithlife/NestEmbedder by StephenCleary 4 years ago
@rainersigwald What’s the plan for getting this fixed?
If I’m hitting this now, how am I supposed to work around it? I see https://github.com/Microsoft/msbuild/issues/2661#issuecomment-338808156, but how exactly am I supposed to be using that? Does that only work if I’m using solution-level dependencies, or is there a way to use a
ProjectReferenceas well?I’m asking because I’ve been able to get it working with a solution-level dependency, but because of other, unrelated problems, I can’t use solution-level dependencies right now. Is there a way to use a ProjectReference and still have my solution build with MSBuild?
Also running into this. I’m trying to build a
netcoreapp3.1exe and include it in a NuGet package under/tools, e.g.:This works fine but ideally I’d like to have a reference so that
Faithlife.AssemblyEmbedderis always built before my NuGet package csproj. I have a dependency in the sln file butdotnet packignores that.Currently my workaround is to just do a separate
dotnet buildbefore thedotnet packto ensure the project is built before it’s included.@rainersigwald any comments on the above question?
FYI something in 15.5 seems to have broken my workaround while not resolving the original bug.
Fortunately setting
AddSyntheticProjectReferencesForSolutionDependenciesto True in the dependent project seems to work.I would think SkipGetTargetFrameworkProperties=true metadata on ProjectReference would work now and that we should set this automatically when ReferenceOutputAssembly=false.
From @rainersigwald on August 23, 2017 18:47
Workaround
Set
in the project that has the
ProjectReferenceto the incompatible project. This prevents the elevation of solution build dependencies toProjectReferencesinAssignProjectConfiguration.(Was poking around near this target for another reason and saw this.)