Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

"dotnet pack" does not build #12160

Open
IvanStoychev opened this issue Jun 24, 2020 · 17 comments
Open

"dotnet pack" does not build #12160

IvanStoychev opened this issue Jun 24, 2020 · 17 comments
Assignees
@dsplaisted
Labels
untriaged Request triage from a team member
Milestone
Discussion

Comments

@IvanStoychev
Copy link

According to the documentation (https://docs.microsoft.com/en-us/dotnet/core/tools/dotnet-pack) the command dotnet pack should first build the project, unless the option --no-build is specified.

I am using Github Actions to publish my nuget project. And in my yml after setting up the environment and checking out the code I run the command dotnet pack --configuration Release -o output, which worked fine before but after my latest changes (renaming files, no changes to the yml) it fails with

##[error]/opt/hostedtoolcache/dncs/3.1.101/x64/sdk/3.1.101/Sdks/NuGet.Build.Tasks.Pack/build/NuGet.Build.Tasks.Pack.targets(198,5): error NU5026: The file '/home/runner/work/IvanStoychev.StringExtensions/IvanStoychev.StringExtensions/IvanStoychev.StringExtensions/bin/Release/netcoreapp3.0/IvanStoychev.StringExtensions.dll' to be packed was not found on disk.

If I were to place a dotnet build command before the packing - it works fine.
@marcpopMSFT marcpopMSFT added the untriaged Request triage from a team member label Jun 25, 2020
@lindexi
Copy link

lindexi commented Jul 18, 2020

I found that my project didn't build success by dotnet pack.

See:

https://github.com/dotnet-campus/dotnetCampus.CommandLineArgsViewer/runs/881667779

https://github.com/dotnet-campus/dotnetCampus.WPFType/actions/runs/173374599

https://github.com/dotnet-campus/dotnetCampus.WPFType/actions/runs/173373439

https://github.com/dotnet-campus/dotnetCampus.WPFType/actions/runs/173372612

https://github.com/dotnet-campus/dotnetCampus.CommandLineArgsViewer/runs/883890812

@petro2050
Copy link

any update on this?

@dsplaisted
Copy link
Member

Hi folks,

If this is still an issue, can someone provide more details? The following would be helpful:

  • Binary logs of the failing pack operation, as well as of the build that preceded it
  • The yml file where this is failing
  • Repro steps

@dsplaisted dsplaisted removed the untriaged Request triage from a team member label Jan 20, 2021
@dsplaisted dsplaisted removed their assignment Jan 20, 2021
@dsplaisted dsplaisted added this to the Discussion milestone Jan 20, 2021
@IvanStoychev
Copy link
Author

Hi, @dsplaisted,

I still get the same error but I've become completely disillusioned with Github Actions and will be switching to another provider, where I believe the command will "miraculously" work. So I leave it to someone else to continue the investigation.

@JonathanLydall
Copy link

Hi folks,

If this is still an issue, can someone provide more details? The following would be helpful:

  • Binary logs of the failing pack operation, as well as of the build that preceded it
  • The yml file where this is failing
  • Repro steps

Hi @dsplaisted,

I just tested this now on my local machine and it is still an issue.

Repro steps:

  • Clone and checkout https://github.com/IntentSoftware/Intent.Modules (at the time head was commit b2f6d7eca0d965c6c9c183cf42b3eff14dd11f8e)
  • cd Modules/Intent.Modules
  • dotnet pack -bl

The console showed the following output:

Microsoft (R) Build Engine version 16.8.3+39993bd9d for .NET
Copyright (C) Microsoft Corporation. All rights reserved.

C:\Program Files\dotnet\sdk\5.0.102\MSBuild.dll -bl -distributedlogger:Microsoft.DotNet.Tools.MSBuild.MSBuildLogger,C:\Program Files\dotnet\sdk\5.0.102\dotnet.dll*Microsoft.DotNet.Tools.MSBuild.MSBuildForwardingLogger,C:\Program Files\dotnet\sdk\5.0.102\dotnet.dll -maxcpucount -restore -target:pack -verbosity:m .\Intent.Modules.Common.csproj
  Determining projects to restore...
  Restored C:\Dev\Intent.Modules\Modules\Intent.Modules.Common\Intent.Modules.Common.csproj (in 147 ms).
C:\Program Files\dotnet\sdk\5.0.102\Sdks\NuGet.Build.Tasks.Pack\build\NuGet.Build.Tasks.Pack.targets(207,5): error NU5026: The file 'C:\Dev\Intent.Modules\Modules\Intent.Modules.Common\bin\Debug\netcoreapp2.1\Intent.Modules.Common.dll' to be packed was not found on disk. [C:\Dev\Intent.Modules\Modules\Intent.Modules.Common\Intent.Modules.Common.csproj]

Here is the binlog of the build:
msbuild.zip

If I go dotnet build followed immediately after by dotnet pack, then it succeeds. I set up our azure-pipelines.yml to do this.

@AraHaan
Copy link
Member

AraHaan commented Feb 7, 2021 •
edited

@JonathanLydall what .NET SDK are you using? On my machine dotnet pack builds with my .NET SDK 5.0.2 when I disable sdk roll farward on my global.json, perhaps you should try out the 5.0.2 SDK to see if it continues to fail and then try the .NET 6 preview SDK to see if any fixes was made.

@JonathanLydall
Copy link

JonathanLydall commented Feb 7, 2021 •
edited

@AraHaan:

> dotnet --info
.NET SDK (reflecting any global.json):
 Version:   5.0.102
 Commit:    71365b4d42

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.19042
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\5.0.102\

Host (useful for support):
  Version: 5.0.2
  Commit:  cb5f173b96

.NET SDKs installed:
  2.1.520 [C:\Program Files\dotnet\sdk]
  2.1.617 [C:\Program Files\dotnet\sdk]
  2.1.700 [C:\Program Files\dotnet\sdk]
  2.1.701 [C:\Program Files\dotnet\sdk]
  2.1.812 [C:\Program Files\dotnet\sdk]
  2.2.202 [C:\Program Files\dotnet\sdk]
  2.2.204 [C:\Program Files\dotnet\sdk]
  2.2.300 [C:\Program Files\dotnet\sdk]
  2.2.301 [C:\Program Files\dotnet\sdk]
  2.2.401 [C:\Program Files\dotnet\sdk]
  2.2.402 [C:\Program Files\dotnet\sdk]
  5.0.101 [C:\Program Files\dotnet\sdk]
  5.0.102 [C:\Program Files\dotnet\sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.All 2.1.11 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.1.12 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.1.13 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.1.24 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.2.3 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.2.5 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.2.6 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.2.7 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.2.8 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.App 2.1.11 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.1.12 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.1.13 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.1.24 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.2.3 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.2.5 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.2.6 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.2.7 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.2.8 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 3.1.11 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 5.0.1 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 5.0.2 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 2.1.11 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.1.12 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.1.13 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.1.24 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.2.3 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.2.5 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.2.6 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.2.7 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.2.8 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 3.1.11 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 5.0.1 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 5.0.2 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.WindowsDesktop.App 3.1.11 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 5.0.1 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 5.0.2 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

I would rather not install preview versions and deal with any potential issues resulting from doing so.

@AraHaan
Copy link
Member

AraHaan commented Feb 7, 2021 •
edited

@JonathanLydall no offense but testing the preview versions would let you know early if it still does not work and also lets the people maintaining the SDK know before release if it is still broken so it could be fixed.

Also you should cleanup those runtimes, usually only the latest ones are used anyways no matter what the TFM you target or so I think.

@JonathanLydall
Copy link

@AraHaan, with all due respect, regardless of whether or not you intended to cause offense, you nevertheless did. I politely stated my reasonable reasons for not wanting to run preview versions and I don't feel it's polite of you to presume to know my situation well enough to criticize it.

Prior to my posting, I actually already had a workaround to this issue, so I don't personally need it "fixed", but nevertheless used my time to provide requested information hopefully for the benefit of all which I feel is somewhat selfless already.

In regards to the older SDK versions, thanks, I had actually already thought the same thing when seeing my output earlier.

@dsplaisted dsplaisted self-assigned this Feb 8, 2021
@dsplaisted dsplaisted added the untriaged Request triage from a team member label Feb 8, 2021
@egeaydin
Copy link

egeaydin commented Mar 1, 2021

I know this is an older issue but if someone is still having the same issue this worked for me: https://steveellwoodnlc.medium.com/error-nu5026-the-file-to-be-packed-was-not-found-on-disk-18bfbc6be4a

Simply remove this from your csproj file if you have it:
<GeneratePackageOnBuild>true</GeneratePackageOnBuild>

@ghost
Copy link

ghost commented May 28, 2021

I know this is an older issue but if someone is still having the same issue this worked for me: https://steveellwoodnlc.medium.com/error-nu5026-the-file-to-be-packed-was-not-found-on-disk-18bfbc6be4a

Simply remove this from your csproj file if you have it:
<GeneratePackageOnBuild>true</GeneratePackageOnBuild>

Still seems to be an issue as of:

.NET SDK (reflecting any global.json):
Version: 5.0.203
Commit: 383637d

Runtime Environment:
OS Name: Windows
OS Version: 10.0.19041
OS Platform: Windows
RID: win10-x64
Base Path: C:\Program Files\dotnet\sdk\5.0.203\

Host (useful for support):
Version: 5.0.6
Commit: 478b2f8c0e

.NET SDKs installed:
3.1.111 [C:\Program Files\dotnet\sdk]
5.0.203 [C:\Program Files\dotnet\sdk]

.NET runtimes installed:
Microsoft.AspNetCore.All 2.1.28 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.App 2.1.28 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 3.1.15 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 5.0.2 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 5.0.6 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.NETCore.App 2.1.28 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 3.1.15 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 5.0.2 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 5.0.6 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.WindowsDesktop.App 3.1.15 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 5.0.6 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

Removing the GeneratePackageOnBuild tag as mentioned does indeed allow "dotnet pack" at the CLI to build the solution first.

This however seems counterintuitive to enabling that setting in the first place if one were to expect a pack as output from a build performed directly within the (VS2019) IDE.

@AntonSmolkov
Copy link

AntonSmolkov commented Jun 7, 2022 •
edited

6.0.202, the issue is still presented.
Workaround:

dotnet pack -c Release /p:GeneratePackageOnBuild=false

@AraHaan
Copy link
Member

AraHaan commented Jun 7, 2022

That is odd, does that happen when using 6.0.300?

@BryceBarbara
Copy link

Just to add some insights to this, this seems to happen when building on a linux machine. It doesn't happen when building on a Windows machine.

@emaung
Copy link

emaung commented Jun 27, 2022

I can confirm that this issue also exists on my mac running dotnet 6.0.301.
I have library projects with <GeneratePackageOnBuild>true</GeneratePackageOnBuild> set.
Setting <GeneratePackageOnBuild>false</GeneratePackageOnBuild> fixes the problem as suggested by @AntonSmolkov

Drake53 added a commit to Drake53/NuGetPush that referenced this issue Dec 9, 2022
@Drake53
Fix for dotnet/sdk#12160
b25bba6
GennadyGS added a commit to GennadyGS/DotNetUtils that referenced this issue Feb 12, 2023
@GennadyGS
Apply workaround for issue dotnet/sdk#12160
572d652
@awattar
Copy link

awattar commented Mar 24, 2023 •
edited

@dsplaisted

On my 7.0.202 dotnet it also occurs but has nothing to do with GeneratePackageOnBuild as its is not explicitly set and defaults to false.

For one of every 3 or 4 packs in a row for a clean (no bin & obj) and freshly restored (VSMac dependency restore or dotnet restore) project no matter if packed from VS or terminal command dotnet pack for some incomprehensible reason it doesn't build the project in the first place:

Very first lines of the build/pack log that does not build then project for pack:

Building Test.Library (Release)
Build started 23/03/2023 22:38:15.
Environment at start of build:
MSBUILD_EXE_PATH               = /usr/local/share/dotnet/sdk/7.0.202/MSBuild.dll
DOTNET_MSBUILD_SDK_RESOLVER_CLI_DIR = /usr/local/share/dotnet
DOTNET_HOST_PATH               = /usr/local/share/dotnet/dotnet
MSBUILDPROJECTROOTELEMENTCACHESIZE = 200
DOTNET_ROLL_FORWARD            = LatestMajor

__________________________________________________
Project "/Users/user/Test.Library.csproj" (Pack target(s)):

When it does build there is first build target and the pack target:

Building Test.Library (Release)
Build started 23/03/2023 23:51:25.
Environment at start of build:
DOTNET_ROLL_FORWARD            = LatestMajor
MSBUILDPROJECTROOTELEMENTCACHESIZE = 200
MSBUILD_EXE_PATH               = /usr/local/share/dotnet/sdk/7.0.202/MSBuild.dll
DOTNET_HOST_PATH               = /usr/local/share/dotnet/dotnet
DOTNET_MSBUILD_SDK_RESOLVER_CLI_DIR = /usr/local/share/dotnet

__________________________________________________
Project "/Users/user/Test.Library.csproj" (Build target(s)):


... (9000 lines later) ...


Build succeeded.
    0 Warning(s)
    0 Error(s)

Time Elapsed 00:00:01.67
Build started 23/03/2023 23:51:27.
Environment at start of build:
DOTNET_ROLL_FORWARD            = LatestMajor
MSBUILDPROJECTROOTELEMENTCACHESIZE = 200
MSBUILD_EXE_PATH               = /usr/local/share/dotnet/sdk/7.0.202/MSBuild.dll
DOTNET_HOST_PATH               = /usr/local/share/dotnet/dotnet
DOTNET_MSBUILD_SDK_RESOLVER_CLI_DIR = /usr/local/share/dotnet

__________________________________________________
Project "/Users/user/Test.Library.csproj" (Pack target(s)):

Although documentation states that it should and must build in these conditions - https://learn.microsoft.com/en-us/dotnet/core/tools/dotnet-pack#description

image

image

@Dancpaz
Copy link

Dancpaz commented May 2, 2023

I can confirm this was an issue for us on Windows. dotnet pack was packaging old assemblies under new version numbers, causing a lot of confusion.

Removing the GeneratePackageOnBuild element from the csproj, as suggested above, worked for us.

matklad added a commit to tigerbeetle/tigerbeetle that referenced this issue Nov 6, 2023
@matklad
dotnet: ensure native libraries are included with the release
934ee24 
See

dotnet/sdk#12160 (comment)

I don't entirely understand what's happening here, but adding this flag
indeed results into native libraries included in the archive.

This should be caught by

#1264

in the future
jahav added a commit to ClosedXML/ClosedXML.Parser that referenced this issue Jan 7, 2024
@jahav
Wrokaround for dotnet pack failure. dotnet/sdk#12160
cc9ee4a
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@dsplaisted dsplaisted

Labels
untriaged Request triage from a team member
Projects
None yet
Milestone
Discussion
Development

No branches or pull requests