_From @tmat on October 8, 2018 23:44_
It is sometimes necessary to build project A before project B without project B referencing the assembly that A generates. In such cases one can use ProjectReference with ReferenceOutputAssembly="false".
This however is not sufficient in all scenarios, especially when these projects target different, incompatible frameworks and/or multi-target.
Turns out 3 properties need to be set to make this work:
<ProjectReference Include="B.csproj"
ReferenceOutputAssembly="false"
SkipGetTargetFrameworkProperties="true"
GlobalPropertiesToRemove="TargetFramework" />
This is much more complex than it should be.
Proposal: introduce a new item that can be use to express that this project depends on building another project, but has no implication on references. Such item could be called e.g. ProjectBuildOrderDependency, DependsOnProject, etc.
<DependsOnProject Include="B.csproj" />
_Copied from original issue: dotnet/sdk#2574_
_From @nguerrera on October 8, 2018 23:45_
cc @rainersigwald
Any change here would need to live on the MSBuild side of the fence, because you can have dependencies to SDK projects from non-SDK projects.
I don't think adding a new item type is the right way to fix this, because ProjectReference is semantically meaningful to VS and other consumers.
I wish we had made ReferenceOutputAssembly="false" have this behavior, but because we shipped the way we did, we can't fix that now -- see https://github.com/Microsoft/msbuild/issues/2661 (and why the fix for it got backed out). This might actually just be a duplicate of that bug.
We could potentially just add a BuildOrderingOnly="true" or something, and recommend using that always over ReferenceOutputAssembly.
I agree with everything you wrote. There are actually two workarounds here vs. the desire of just saying ReferenceOutputAssembly="false"
Since it doesn't seem we can compatibly make ReferenceOutputAssembly="false" the master switch, I vote +1 on BuildOderingOnly="true" or some other new metadata.
Most helpful comment
I don't think adding a new item type is the right way to fix this, because
ProjectReferenceis semantically meaningful to VS and other consumers.I wish we had made
ReferenceOutputAssembly="false"have this behavior, but because we shipped the way we did, we can't fix that now -- see https://github.com/Microsoft/msbuild/issues/2661 (and why the fix for it got backed out). This might actually just be a duplicate of that bug.We could potentially just add a
BuildOrderingOnly="true"or something, and recommend using that always overReferenceOutputAssembly.