`dotnet pack --no-build` fails

[mpdelbuono]

When attempting to execute dotnet pack --no-build, the operation fails with the following error:

C:\Program Files\dotnet\sdk\8.0.404\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Sdk.targets(238,5): error NETSDK1085: The 'NoBuild' property was set to true but the 'Build' target was invoked.

I suspect this is caused by a build being triggered on the dependency, but this is not allowed. Ideally the system would respect the --no-build request. This is very important for build systems that need to perform some step in between build and package (such as signing delay-signed DLLs) where doing the build step immediately before a pack would be functionally incorrect.

[teneko]

I am slowly but steady annoyed by requests that are not related to the functionality of this package. It is curious to me why this request even does have thumbs up. Can you derive from the code where I proactively call the Build target explictly or is getting called implictly by one or the other target of mine? I cannot. Have you investigated the problem by yourself and do you think that this input you provide indicates anything to indentify the problem?

[Prunkles]

This issue is pretty easily reproducible: https://github.com/Prunkles/Tenekon.MSBuild.Packaging.ProjectBuildInPackage_NoBuildRepro . I think this is an important feature to support (at least because of the reasons mentioned above), so I don't understand why it is "not related to the functionality of this package".

By the way, when I was trying to find a solution I came across this issue and found it similar to this one, so maybe it will help to understand that is going on

[teneko]

This kind of context I needed!

It seems to me that this is a deeper problem related to the underlying infrastructure (Microsoft.NET.Sdk.targets). When looking at the source code (Microsoft.NET.Sdk.targets) the plausible reason this happens is, that for some reason the NoBuild flag is not properly propragated. Also the linked issue you mentioned indicates this, that transitive dependencies are still built reglardless of the initial set NoBuild flag. So my wild solution would be to simply noop out this target on a per-project basis or tinkering around this target to not get called or you archieve it to propagate the NoBuild flag properly which I think is more complicated.

Perhaps it helps, but I never got dotnet pack -no-build reliably to work. So I give the same advice as already given here:

This means, that dotnet pack is going to build your project but that's in conflict with your parameter --no-build.
I can remember that the program dotnet pack is more user friendly and builds your project before it actually packs it. It only builds your project only once unless you have made changes. If you really just want to "pack", then you have to call the pack target manually with dotnet msbuild -t:pack (see https://github.com/NuGet/NuGet.Client/blob/ea0bf4a379b6306fd88ff1529dc57e9b16af326a/src/NuGet.Core/NuGet.Build.Tasks.Pack/NuGet.Build.Tasks.Pack.targets#L202).

[teneko]

The trigger of the build may actually be the fact, that I depend on the ResolveReferences target and this may provoce the builds and finally leads to this problem. The problem is, that I need the ReferenceCopyLocalPaths which are set in the rabbit hole of the ResolveReferences target and their dependencies.

[teneko]

Unfortunelately I do not see an easy solution without spending a lot of time and even then the success is uncertain. Could you please check if dotnet msbuild -t:pack works, at least without error? I think It will still provoce another build try. :/

[Prunkles]

Unfortunelately I do not see an easy solution without spending a lot of time and even then the success is uncertain. Could you please check if dotnet msbuild -t:pack works, at least without error? I think It will still provoce another build try. :/

Thanks, dotnet msbuild -t:Pack (and with -p:Configuration=Release for completeness) seems to work. And it doesn't trigger a build

Edit: My bad, it actually does trigger the build, but not a restore

[teneko]

I have three options: either I find the cause of the bug in the infrastructure of dotnet pack (see previous posts), or I build a stand-alone solution to detect project build-only and pack-only-relevant assets (kinda impossible) or give the only advice to switch to a manual pack process, where you decide what files of each TFM of each transitive project are relevant to be picked up in your package to not longer have the requirement to depend on the ResolveReferences target.

[teneko]

I stumbled across dotnet/sdk#25132, which states that setting BuildProjectReferences=false fixed the NETSDK1085 (see dotnet/sdk#24943) error when using dotnet nuget pack --no-build.

Can you, @mpdelbuono, @Prunkles, @varnerknut and @MeikelLP please verify this?

@Prunkles, see Prunkles/Tenekon.MSBuild.Packaging.ProjectBuildInPackage_NoBuildRepro#1 (Pull Request)

[ViRuSTriNiTy]

@teneko For me, the suggested dotnet pack "..." --no-build /p:BuildProjectReferences does work in a way that the NETSDK1085 error is gone, but in certain scenarios the project references configured with PrivateAssets=all are not included in the NuGet package. On my side, such a scenario is the CI pipline where build and pack is configured as separate jobs. Running the suggested command locally after a dotnet build works fine as the project references are included in the resulting NuGet package.

Shortly after posting this, our DevOps guy found a cache bug in the CI pipeline. Now its also working in CI with --no-build /p:BuildProjectReferences. 👌

[teneko]

I close this issue for now. I will prominently hint on that behaviour in the README. Thanks for confirmation. If anything is not behaving as thought or assumed, just comment on this issue. 🙂