The target "GetCopyToPublishDirectoryItems" does not exist in the project when publishing multitargeted sln

[Best-Practice0]

Adding a ProjectSection(ProjectDependencies) = postProject to a solution will cause an error when publishing from the CLI if the project has <TargetFrameworks> instead of <TargetFramework>. This can be done in Visual Studio by right-clicking a project->Build Dependencies->Project Dependencies... and checking a project that isn't a dependency.

This feature is nice to build dynamically loaded assemblies that aren't direct build dependencies in a solution.

Here is a simple solution that demonstrates the problem:
https://github.com/Best-Practice0/DotnetPublishProblem/tree/master

[Best-Practice0]

Hm. Did I do this wrong? I thought the sample project would get someone smart in this stuff to post most specifics... What should I have done to get someone to look at this?

[KalleOlaviNiemitalo]

That seems like a bug to me, but see dotnet/msbuild#3843 for an alternative solution.

[Best-Practice0]

I tried adding

<ProjectReference Include="..\NotDirectReference\NotDirectReference.csproj" ReferenceOutputAssembly="false" SkipGetTargetFrameworkProperties="true" />

to my main project, but now NotDirectReference.dll doesn't show up in the publish location. This isn't my desired behavior.

I decided to single target my projects to <TargetFramework>net5.0</> with <LangVersion>7.3</> and enforce dual compatibility in my pipeline. This worked for a few weeks until I had buy-off to single target the newest version.

I also thought about taking a direct reference to the NotDirectReference project and using DependencyValidation to verify my project didn't create any code references.

Bottom line: I got around this and I doubt many will be tripped up by it, but this is still a bug when publishing dual targeted solutions.

[marcpopMSFT]

Old bug triage: Sounds like you found a solution and this is an area we are not currently investing in so closing for now.