Disable NuGet pack for NoTargets projects

[MattKotsenas]

Scenario

I have a large solution / traversal project that includes projects that create NuGet packages, and also NoTargets projects to hold other targets. As part of my CI/CD pipeline I want to run dotnet pack on the top-level project to create all NuGet packages.

Note that I use the .csproj extension for NoTargets projects to avoid the issues mentioned in #155 .

The problem

NoTargets projects fail with the following error message:

C:\Program Files\dotnet\sdk\7.0.400\Sdks\NuGet.Build.Tasks.Pack\build\NuGet.Build.Tasks.Pack.targets(221,5):
error NU5017: Cannot create a package that has no dependencies nor content.
[/path/to/my/NoTargets.csproj]

Workarounds

Adding <IsPackable>false</IsPackable> to every NoTargets project

The fix

Update the NoTargets SDK to set IsPackable to false by default, and add unit tests to validate behavior.

[jeffkl]

@MattKotsenas This would be a breaking change for users that are packing NoTargets projects today. For your repository, could you place something like this in your Directory.Build.targets:

<Project>
  <PropertyGroup>
    <IsPackable Condition="'$(UsingMicrosoftNoTargetsSdk)' == 'true'">false</IsPackable>
  </PropertyGroup>
</Project>

I would be fine with a new property that you could set in your Directory.Build.props:

<Project>
  <PropertyGroup>
    <NoTargetsIsPackable>false</NoTargetsIsPackable>
  </PropertyGroup>
</Project>

So if NoTargetsIsPackable was set to false, then the NoTargets build logic would set IsPackable to false for you. But I think making it not packable by default is going to break people.

[MattKotsenas]

Thanks @jeffkl!

So to be explicit, it sounds like there are three options:

1. Accept this as a breaking change
2. Add a new property like NoTargetsIsPackable
3. Abandon this PR and do nothing

I think I'd be against option 2. It adds complexity to the SDK, when the "workaround" as you mentioned is basically a single line.

That leaves options 1 and 3.

I was operating under the assumption that given that NoTargets don't produce their own assembly (per the README) by extension they also wouldn't be producing a NuGet package. However, after searching across GitHub it doesn't take much to find several projects that are relying on the packaging targets without also setting IsPackable.

Thus probably the best course is to abandon and leave things as-is. If you disagree, or if we discover new info, happy to reactivate.

Thanks for clarifying my bad assumptions!

[jeffkl]

@MattKotsenas thanks anyway for the contribution. I think in this case avoiding a breaking change is the top priority, we both found instances where people are using NoTargets to create packages. At least with an entry in your Directory.Build.targets you can disable the functionality for a whole repository. I'd be fine with the new property that disables it as well.