We are using Azure DevOps pipelines. We have a step that publishes the our private nuget package to the Azure Artifacts. However, the build breaks at other steps because the nuget package (that was published on previous steps) is not found. The strange thing is that after the package is published, I can see it in the package-manager console or on Visual Studio and even in the Artifacts in Azure DevOps. But for some reason, the pipeline doesn't find the package. After 30-50min, I re-run the pipeline and then it finds the package.
What could be happening to take so long time for the pipeline to find the my package?
Edit 1:
This is my yaml for the step with error
- script: |
pwd && ls -la
dotnet restore "$(solution_path)" $(nuget_args)
dotnet publish -c Release -o $(System.DefaultWorkingDirectory)/bin "$(main_project_path)"
mkdir artifact
cp -r $(System.DefaultWorkingDirectory)/bin artifact/bin
displayName: Build Application
The error is:
/data/vstsagent/user/389/s/src/MyProject.csproj
: error NU1102: Unable to find package MyPackage with
version (>= 2.1.0) [/data/vstsagent/user/389/s/src/MySolution.sln]
/data/vstsagent/user/389/s/src/MyProject.csproj
: error NU1102: - Found 28 version(s) in MyPrivateRepository [ Nearest
version: 2.1.0-preview.6 ]
[/data/vstsagent/user/389/s/src/MySolution.sln]
It is not clear what feed is used by dotnet restore command.
Confirm that you have configured your custom nuget feed in nuget.config and using it.
Try adding "--verbose" switch in dotnet restore command and check if your feed is used for restoring packages.
Use the --no-cache option so dotnet restore doesn't use the local cache.
Related
I have a private feed from GitHub that I added to Nuget.config file:
<add key="github" value="https://nuget.pkg.github.com/..." />
I can confirm it works by using dotnet nuget list source (see screenshot below).
However when running dotnet add package -s github PackageName, it fails with "There are no versions available for the package" error. Removing the -s github works (and it installs from the Private feed if it is on the top).
Although I can manually run it for myself (removing -s), I am writing a script to install it for other developers. I need to reliably install it from the private feed even if it's not on the top of the list. There may be packages in nuget.org with the same name in our private feed.
Why does specifying package source with -s not work? How do I fix it?
The Microsoft docs are saying:
-s|--source <SOURCE>
The URI of the NuGet package source to use during the restore operation.
So I'd expect the command to be like this:
dotnet add package -s https://nuget.pkg.github.com/... PackageName
When I trying to add Nuget Packages by Nuget gallery extension from VS Code. It doesn't install the NuGet package.
Executing task: dotnet add /home/[user]/Public/Projects/yogihosting.com/Identity/Identity/Identity.csproj package Microsoft.AspNetCore.Identity.EntityFrameworkCore -v 5.0.6 -s https://api.nuget.org/v3/index.json <
Determining projects to restore...
Writing /tmp/tmpIIHQRz.tmp
info : Adding PackageReference for package 'Microsoft.AspNetCore.Identity.EntityFrameworkCore' into project '/home/[user]/Public/Projects/yogihosting.com/Identity/Identity/Identity.csproj'.
info : Restoring packages for /home/[user]/Public/Projects/yogihosting.com/Identity/Identity/Identity.csproj...
error: Unable to load the service index for source https://api.nuget.org/v3/index.json.
error: The SSL connection could not be established, see inner exception.
error: The remote certificate is invalid because of errors in the certificate chain: UntrustedRoot
Usage: NuGet.CommandLine.XPlat.dll package add [options]
Options:
-h|--help Show help information
--force-english-output Forces the application to run using an invariant, English-based culture.
--package Id of the package to be added.
--version Version of the package to be added.
-d|--dg-file Path to the dependency graph file to be used to restore preview and compatibility check.
-p|--project Path to the project file.
-f|--framework Frameworks for which the package reference should be added.
-n|--no-restore Do not perform restore preview and compatibility check. The added package reference will be unconditional.
-s|--source Specifies NuGet package sources to use during the restore.
--package-directory Directory to restore packages in.
--interactive Allow the command to block and require manual action for operations like authentication.
--prerelease Allows prerelease packages to be installed.
The terminal process "/bin/bash '-c', 'dotnet add /home/[user]/Public/Projects/yogihosting.com/Identity/Identity/Identity.csproj package Microsoft.AspNetCore.Identity.EntityFrameworkCore -v 5.0.6 -s https://api.nuget.org/v3/index.json'" terminated with exit code: 1.
Terminal will be reused by tasks, press any key to close it.
How can I get rid of this problem?
https://api.nuget.org/v3/index.json shows:#
Note: I'm using Ubuntu.
We may solve this issue by one of following process.
copy project to another folder or create new project to another destination.
It may cause, our file or folder is corrupted.
Reinstalling our software(s) like IDE or dotnet or both.
It may cause not to be installed correctly.
The final is so funny. Re-install your OS and then other softwares.
I am unable to publish my .net function app. I am using the below configuration and settings:
.net 5 SDK Version: 5.0.300
Microsoft.Azure.Functions.Worker 1.2.0
Microsoft.Azure.Functions.Worker.Core 1.1.0
Getting below error:
Metadata generation failed. Exit code: '-532462766' Error: 'Error generating extension metadata: System.IO.DirectoryNotFoundException: The path PATH\bin\Release\net5.0\publish\bin does not exist. Unable to generate Azure Functions extensions metadata file.
The problem lies with the .targets file of Microsoft.Azure.WebJobs.Script.ExtensionsMetadataGenerator, it sets the _FunctionsExtensionsDir to the publish target directory + 'bin'
So if you publish to project-path\bin\release\net5.0\publish, it's looking for published output in project-path\bin\release\net5.0\publish\bin - you can prove this by doing a replace all in the .targets file replacing ')bin' with ')' and watching it run as expected.
A quick and dirty solution is to build with the -o flag set to where the metadata generator will expect the output to be, e.g.
dotnet build yourproject.csproj --framework net5.0 -c release -o c:/temp/output/bin -v d
dotnet publish yourproject.csproj --framework net5.0 -c release -o c:/temp/output -v d
I'm currently looking into a less hacky way of achieving this, and will post if/when I figure it out.
This looks like a bug in Visual Studio 2019.
Suggestion:
Record your current version, you can raise a support ticket to confirm with the official.
Upgrade your vs2019 to the latest version and try to publish again.
At the moment I have a visual studio project and I use the docfx.console nuget package to build the documentation, and everything works fine and as expected... on windows. The point is now I want to make a docker image based on mcr.microsoft.com/dotnet/core/sdk:3.1 which is based on a linux image. And compiling in this docker image running the command:
dotnet publish -c Release -o out
Gives the following error
> [build 9/9] RUN dotnet publish -c Release -o out:
#22 1.080 Microsoft (R) Build Engine version 16.0.450+ga8dc7f1d34 for .NET Core
#22 1.080 Copyright (C) Microsoft Corporation. All rights reserved.
#22 1.080
#22 2.852 Restore completed in 215.94 ms for /app/Documentation/Documentation.csproj.
#22 6.299 Documentation -> /app/Documentation/bin/Release/netcoreapp2.1/Documentation.dll
#22 6.402 /bin/sh: 2: /tmp/tmpbd72ebbe5e6b49c1b3244f1f50c8b57a.exec.cmd: /root/.nuget/packages/docfx.console/2.48.1/build/../tools/docfx.exe: Exec format error
#22 6.407 /root/.nuget/packages/docfx.console/2.48.1/build/docfx.console.targets(57,5): error MSB3073: The command ""/root/.nuget/packages/docfx.console/2.48.1/build/../tools/docfx.exe" "/app/Documentation/docfx.json" -o "" -l "log.txt" --logLevel "Verbose"" exited with code 2. [/app/Documentation/Documentation.csproj]
I already did some prodding around and I believe I have the issue mostly solved. Running file on console.exe shows that this is a PE32 executable (console) Intel 80386 Mono/.Net assembly, for MS Windows. And these kind of files should not be executed on linux using sh but with mono. And indeed running:
mono docfx.exe "/app/Documentation/docfx.json" -o "" -l "log.txt" --logLevel "Verbose"
builds the documentation just fine as expected. At this point of course I have a bunch of workarounds to get the documentation building correctly, just remove docfx.console form the csproj and build it manualy from the command line using a docker command.
But the question is, can I also use the nuget package on linux by changing how the docfx.exe command is run by the nuget package? Or is this only possible by actually fixing this in docfx.console?
p.s. in case it matters, the version of docfx.console that I am using is the most recent one available at the time of writing, namely 2.48.1
But the question is, can I also use the nuget package on linux by changing how the docfx.exe command is run by the nuget package? Or is this only possible by actually fixing this in docfx.console?
Create script docfx that runs docfx.exe using Mono, e.g., like this (assuming docfx.exe is located in /opt/docfx/docfx.exe):
echo '#!/bin/bash\nmono /opt/docfx/docfx.exe $#' > /usr/bin/docfx && chmod +x /usr/bin/docfx
Then, pass MSBuild parameter BuildDocToolPath with path to that script, e.g., like this:
dotnet publish -c Release -o out -p:BuildDocToolPath=/usr/bin/docfx
docfx.console will than use this path to execute DocFX. I think the property BuildDocToolPath isn't documented anywhere, but you can see it in source code.
I got a build in VSTS that are triggered on every commit in the repository. Everything works great with one exception.
We do not release a new version of the nuget package on every commit. So our nuget push build step fails with http status code 409. I've configured that step so that it can continue anyway.
Due to the error the build is just "partially successful". I'm using the a build badge which also states the same (without context).
How can I tell VSTS to ignore 409 or just replace the existing package (on nuget.org)?
You can’t ignore 409 error in VSTS build and can’t replace the existing package in server.
I recommend that you can push the package in the release and fail the release if package is existing.
Another way is that, you can check the package in server before push package (e.g. PowerShell, REST API) during the build and set the condition for push package task (Custom Condition).
For example:
Add a variable to build definition (e.g. hasPackage true)
Check packages (PowerShell, Rest API etc…)
If the package is existing, set the variable to false ("##vso[task.setvariable variable=hasPackage;]false")
Set Custom condition for push package task (e.g. eq(variables['hasPackage'],'false'))
Update:
Allow duplicates to be skipped is supported in NuGet Push Task now! (Just check Allow duplicates to be skipped option in NuGet Push task.
Use -SkipDuplicate flag (available since NuGet 5.1):
(5.1+) If a package and version already exists, skip it and continue with the next package in the push, if any.
Source: https://learn.microsoft.com/en-us/nuget/reference/cli-reference/cli-ref-push#options
We had the same problem with duplicated packages on Azure Pipelines.
Solution proposed by starian chen-MSFT is cool but it requires some scripting.
We came to solution which requires less efforts. You can create command line step and invoke dotnet nuget push with the following parameters:
dotnet nuget push $(Build.ArtifactStagingDirectory)/*.nupkg --skip-duplicate --api-key $(Config.NuGetApiKey) --source https://api.nuget.org/v3/index.json
The key is parameter --skip-duplicate which just skips the packages if they already exist.
In variable $(Config.NuGetApiKey) define your API key for NuGet.org. You should make it secret variable, so that it does not appear anywhere in the logs.
Here is the YAML for this command:
steps:
- script: |
dotnet nuget push $(Build.ArtifactStagingDirectory)/*.nupkg --skip-duplicate --api-key $(Config.NuGetApiKey) --source https://api.nuget.org/v3/index.json
failOnStderr: true
displayName: 'Publish NuGet Package'
I have had zero luck with dotnet push - and here's my context:
My dotnet pack is set to include symbols and source
and always generating a unique preRelease semVer.. (here's yaml version of above dotnet pack)
steps:
- task: DotNetCoreCLI#2
displayName: 'dotnet pack'
inputs:
command: pack
nobuild: true
includesymbols: true
includesource: true
versioningScheme: byPrereleaseNumber
majorVersion: '$(AssemblyInfo.AssemblyInformationalVersion.Major)'
minorVersion: '$(AssemblyInfo.AssemblyInformationalVersion.Minor)'
patchVersion: '$(AssemblyInfo.AssemblyInformationalVersion.Patch)'
... and yet I get 409 responses with my freshly generated semVer!!
** BLAH!! **
My Solution: just use NuGet Push instead!
- task: NuGetCommand#2
displayName: 'NuGet push'
inputs:
command: push
publishVstsFeed: 'b64b1c9a-18fc-4e6f-aae7-3726c813f034'
continueOnError: true
Now my debug build-configuration CI pipeline builds full-source-and-symbol-accompanied NuGet packages in pre-release mode without failing the pipeline or putting caution symbols on it. YAY
I use a separate near identical CI pipeline to build in 'release' mode and create 'release' style semVer's.