GeneratePackageOnBuild should not set NoBuild.

[peterhuene]

Details about Problem

See dotnet/cli#9656 and dotnet/cli#9581 for some additional context.

We have two problems in the .NET Core SDK for 3.0:

• The first is that setting GeneratePackageOnBuild in a project file fails to publish with a simple dotnet publish if the project hasn't already been built. The root of the problem is that the publish targets also use NoBuild to support the --no-build option and expect the property to signify this. However, the pack targets are setting NoBuild to true when GeneratePackageOnBuild is also true (see this line in the pack targets). This inadvertently turns dotnet publish into dotnet publish --no-build when GeneratePackageOnBuild is true.
• The second is that the SDK fails to detect a build has occurred even though --no-build was specified (for publish in this case, but should also apply to pack). This would prevent unintentional changes to the build output files that are about to be packed or published when --no-build is specified.

We'd like to solve both issues, but doing so requires a change to both the .NET Core SDK and the pack targets.

On the SDK side, we're adding a check to see if CoreBuild gets invoked with NoBuild set to true and we error in that case. This will catch bugs that inadvertently cause a build with NoBuild set (dotnet/cli#9581). However, because NoBuild gets set when GeneratePackageOnBuild is true, we have to skip the check when GeneratePackageOnBuild is true, for now at least.

On the NuGet side, would it be possible to stop turning on NoBuild when GeneratePackageOnBuild is true and instead condition setting GenerateNuspecDependsOn based on GeneratePackageOnBuild?

That is to say remove the set of NoBuild entirely (see source link above) and condition GenerateNuspecDependsOn like this:

...
<PropertyGroup Condition="'$(NoBuild)' == 'true' or '$(GeneratePackageOnBuild)' == 'true'">
    <GenerateNuspecDependsOn>$(GenerateNuspecDependsOn)</GenerateNuspecDependsOn>
</PropertyGroup>
<PropertyGroup Condition="'$(NoBuild)' != 'true' and '$(GeneratePackageOnBuild)' != 'true'">
    <GenerateNuspecDependsOn>Build;$(GenerateNuspecDependsOn)</GenerateNuspecDependsOn>
</PropertyGroup>
...

As far as I can determine, that should be a backwards compatible change on your side, while fixing dotnet/cli#9656.

Environment information

.NET Core SDK (reflecting any global.json):
 Version:   3.0.100-preview-010000
 Commit:    e46d7b966e

Runtime Environment:
 OS Name:     Mac OS X
 OS Version:  10.14
 OS Platform: Darwin
 RID:         osx.10.14-x64
 Base Path:   /Users/peterhuene/src/sdk/.dotnet/sdk/3.0.100-preview-010000/

Host (useful for support):
  Version: 3.0.0-preview-27218-01
  Commit:  d40b87f29d

.NET Core SDKs installed:
  3.0.100-preview-010000 [/Users/peterhuene/src/sdk/.dotnet/sdk]

.NET Core runtimes installed:
  Microsoft.AspNetCore.App 3.0.0-preview-18579-0056 [/Users/peterhuene/src/sdk/.dotnet/shared/Microsoft.AspNetCore.App]

To install additional .NET Core runtimes or SDKs:
  https://aka.ms/dotnet-download

[rrelyea]

This is difficult to do in 5.0...and we are busy driving towards ZBB for that. Would love to have somebody dig into this in the next few weeks.

[nkolev92]

I hit some related issues while messing with the 3.0.0 SDK.

@peterhuene

The plan is the fix the issues for 3.0 only, correct?

We're nearing escrow for 5.1, and if this is 3.0 only then there's no need to try to argue for it in 5.1 escrow

[peterhuene]

That's correct, only 3.0 and landing in P6 would be fine.

[nkolev92]

@peterhuene The first NuGet insertion into CLI/SDK that has 5.2.0 in the version will have this change.

I'll try to remember to ping you when that happens :)
Save bet is 3 weeks down the line.