Ensure Build target isn't invoked when NoBuild is set.

[peterhuene]

For dotnet pack --nobuild and dotnet publish --nobuild, if a target
inadvertently triggers the Build target, the build proceeds despite the user
explicitly requesting no build takes place.

This commit ensures the SDK errors if the Build target gets invoked when
NoBuild is true.

Fixes dotnet/cli#9581.

[nguerrera]

I think it would be good to look at https://github.com/dotnet/cli/issues/9656 together with/soon after this to make sure we're on solid footing with NoBuild.

[peterhuene]

It would obviously be a breaking change to have a NoBuildForPublish and NoBuild (implying for pack). I was aware of the request, but didn't want to make that call yet.

I'd be happy to include that fix with this PR if we feel that's wise.

[nguerrera]

I meant we should try to find a way to fix the issue without giving up on NoBuild everywhere. I just meant we should look at that while we’re looking at this. May require coordinated changes with NuGet.

[nguerrera]

We should test this with GeneratePackageOnBuild

[peterhuene]

Good catch. It fails with GeneratePackageOnBuild.

It seems wrong for GeneratePackageOnBuild to set NoBuild just to control GenerateNuspecDependsOn.

Now I remember why I had the PackAsTool check; it was the wrong granularity as I thought it was somehow setting NoBuild, but it was actually the tool pack tests setting GeneratePackageOnBuild.

I'll have to replace the PackAsTool check with a GeneratePackageOnBuild check and if a pack --nobuild accidentally triggers a build with GeneratePackageOnBuild set to true, then we won't catch it.

[peterhuene]

I meant we should try to find a way to fix the issue without giving up on NoBuild everywhere.

What do you mean by giving up on NoBuild?

Ah, I think you mean fixing it without having an additional property in the publish targets?

[peterhuene]

I think I get what you're saying.

How about this: we keep this commit, change the PackAsTool check to a GeneratePackageOnBuild check. File a bug against NuGet to stop setting NoBuild on GeneratePackageOnBuild by adding an additional condition to setting GenerateNuspecDependsOn based on GeneratePackageOnBuild.

I'll add a TODO comment linked to the issue with these changes. With both fixes in place (and a follow-up change from us to remove the GeneratePackageOnBuild check here), we should fix this and dotnet/cli#9656.

[nguerrera]

Let me step back:

1. We have the linked issue when publish with NoBuild is combined with GeneratePackageOnBuild.

2. One proposal on the issue was to use something other than NoBuild for publish (to avoid collision with pack). I have consistently pushed back against this breaking change with poorer usability. Taking this approach, which I do not want to do, is what I meant by “giving up on NoBuild everywhere”.

But we still need to fix (1) somehow and I’m saying that we should look at this while we’re adding more NoBuild functionality.

[nguerrera]

Typed that without seeing recent replies. Thumbs up on plan above.

[peterhuene]

I've filed NuGet/Home#7801 and amended the commit as stated.