-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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.
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
dotnet pack fails when GeneratePackageOnBuild
is true
#10335
Comments
@wli3 can you take a look at this issue? |
the same issue as #3471 |
More info here #3473 (comment) |
It is not really related to target framework. It is actually due to the following logic. When GeneratePackageOnBuild=true, it will skip the build step. So there is no built dll to pack. @nkolev92 this is issue an I am thinking to no fix. See #3473 (comment), it is a set of issue that is very brittle |
GeneratePackageOnBuild
is true
But why this is a no fix? The setting says "Generate package on build", it does not say "Don't build when generating packages". |
Revert "Set RestorePackagePath" This reverts commit f69ea24ed26d600c35d2df438804a8e7f121b731. Removed GeneratePackageOnBuild This resolved a packing issue. See [here](dotnet/sdk#10335) for more information.
any update? 🙃 |
Revert "Set RestorePackagePath" This reverts commit f69ea24ed26d600c35d2df438804a8e7f121b731. Removed GeneratePackageOnBuild This resolved a packing issue. See [here](dotnet/sdk#10335) for more information.
Revert "Set RestorePackagePath" This reverts commit f69ea24ed26d600c35d2df438804a8e7f121b731. Removed GeneratePackageOnBuild This resolved a packing issue. See [here](dotnet/sdk#10335) for more information.
* Fixed BatchAccountIdentity constructor breaking change. Changed test location for CloudService test. Update changelog and version. Added more legacy constructors. Fixed constructor and test Add another 2 argument constructor for BatchAccountIdentity Mark legacy identity class and related constructor as obsolete Mark legacy identity class and related constructor as obsolete Added nuget config to fix package build order issue. Revert "Added nuget config to fix package build order issue." This reverts commit b59ade3. Updated batch version Revert "Updated batch version" This reverts commit 86a050d. Fixed changelog date Fixed changelog * Updated session recordings Session records Updated session recordings. Updated location filter value to fix scenario test. * Updated batch version Updated package version Updated version Fixed versioning Fixed version Reverted to v4.2, will address in pending DataPlane update. * Removed GeneratePackageOnBuild Revert "Set RestorePackagePath" This reverts commit f69ea24ed26d600c35d2df438804a8e7f121b731. Removed GeneratePackageOnBuild This resolved a packing issue. See [here](dotnet/sdk#10335) for more information.
I think I've hit this problem, too, in Azure Pipelines and locally. |
Fix nuget deployment Add .NET 4.7.2 example Fix package output path to reduce filesize. Use semantic-version Get rid of .NET 3.1 on build (for now?) Remove `GeneratePackageOnBuild`: dotnet/sdk#10335 Move test to it's own step Use GitHubActionsTestLogger for tests Force win target for PictSharp.drawing Try combining actions Add .net core needed for .net standard? Fix project path Fix msbuild Another fix of actions Remove msbuild path from windows build Add BuildNetCore option to prevent net472 tests running Fix readme and try fix dotnet test under linux Add Manual Build process Fix all warnings, and add XML comments MsBuild package fixes Fix up license to MIT
Until the fix is done, I'm using this workaround in my CI pipelines. I hope it helps!
|
Is there an update on this? It's been almost 2 years. |
Causes problems for me as well. I have a web API app and an nswag generated client project. I publish the webapp and run pack on the client project, but because GeneratePackageOnBuild = true it fails. Removing GeneratePackageOnBuild=true from my csproj allows the step to complete successfully. GeneratePackageOnBuild implies a package is made when the project is built, it does not imply the project has been built when the pack step is run. |
I have encountered this suddenly in my pipeline too, and it was unexpected as it worked previously with GeneratePackageOnBuild set to true in project settings - now I had to set it to false. Last time it worked was Oct 10, next time I have tried to run pipeline was today (Nov 24) - very upsetting. My pipeline consists of 2 separate stages and jobs, first stage + job is Pack:
second is publish:
lastly i wrap both stages in following yaml:
for completeness Templates/RestoreAndBuild.yml content below:
|
Using this simple repo: https://github.com/daniefer/dotnetcliissue
When the
<GeneratePackageOnBuild>true</GeneratePackageOnBuild>
project attribute is specified and the project has not been built withdotnet build
before hand, the build will target netcoreapp2.2 instead of the target framework specified with the<TargetFramework>netstandard2.0</TargetFramework>
attribute. When this happens runningdotnet pack
will build the project into thebin/Debug/netcoreapp2.2
folder instead ofbin/Debug/netstandard2.0
and the pack command will fail with the below error:Steps to reproduce
Clone https://github.com/daniefer/dotnetcliissue
Ensure bin/Debug is empty
Run
dotnet pack
from project directory or by providing path the*.csproj
Expected behavior
Should pack project.
Actual behavior
dotnet pack fails with below error:
Environment data
global.json file (location - C:\Repos):
dotnet --info
output:The text was updated successfully, but these errors were encountered: