When publishing packages with the same version to ProGet free v5.1.22 using the CLI comand nuget push with the parameter -SkipDuplicate I get exit code 1 and the result code is 403 (Package Already Exists).
I'm using nuget v5.4.0.
I tried publishing to nuget.org and it works as expected, i.e., I get a message stating the package already exists, but the exit code is 0, which allows my CI build to proceed.
Why is SkipDuplicate not working as expected in ProGet?
Maybe it is because the nuget only ignores 409 (Conflict) return code when this options is set, regarding the dotnet core documentation (see https://learn.microsoft.com/en-us/dotnet/core/tools/dotnet-nuget-push)
This information is not available on nuget.exe CLI doc page (https://learn.microsoft.com/en-us/nuget/reference/cli-reference/cli-ref-push).
I am about to raise a ticket to Inedo about this compatibility issue.
Related
So I started seeing this error when I was working with dotnet tools:
/usr/local/share/dotnet/sdk/6.0.100/NuGet.targets(130,5): warning : Your request could not be authenticated by the GitHub Packages service. Please ensure your access token is valid and has the appropriate scopes configured.
The resources I saw on this were generally pointing to pipeline issues, but that wasn't the case for me.
Not sure what triggered this or why this resolves it for me, but if I disable and reenable my nuget source it works for me.
dotnet nuget list source
should return something like this:
Registered Sources:
1. nuget.org [Enabled]
https://api.nuget.org/v3/index.json
then you want to disable and reenable it:
dotnet nuget disable source nuget.org
dotnet nuget enable source nuget.org
Due to the usage of Babel, that require us to host ourself the package manager on a private repository, we are using Azure Devop as a source of our packages.
But now when we look for any package that is not yet somewhere in the solution, we end up with a "No packages found":
Here we were looking for "roslynator"
If I do this same request in a brand new project. No issues at all, I find the packages.
but we have nuget.org correctly specified in the upstream sources:
And the whole team is listed as contributor. I cannot find any error anywhere when we are fetching the packages. I tried to execute the command Install-package Roslynator. The commands succeed, and then I'm able to see the package in the GUI of visual studio(and in the web console of visual studio).
Seems to be an issue on Visual studio level, but I cannot understand what is causing it?
According to the steps in the Consume NuGet packages in Visual Studio document:
If you're using upstream sources, any packages from upstream sources that haven't been saved to your feed yet (by using them at least once) won't appear in the Package Manager search result. To install those packages:
Copy the Install-Package command from the public registry (NuGet.org).
Select Tools then NuGet Package Manager to open the NuGet package
manager.
Paste the command into the Package Manager Console and select run.
So this is the expected behavior and your steps are correct.
Update:
If you want to find all packages in nuget.org, you need to choose nuget.org as source and search packages instead of using your Azure DevOps sources:
According to this document:The nuget.org upstream source allows you to merge the contents of nuget.org into your feed such that the NuGet client can install packages from both locations without making multiple search queries. Enabling upstream sources also automatically enables saving of packages you use from the upstream source.
If you dislike this behavior (and who wouldn't) you can up-vote this Visual Studio Developer Community issue: Allow search upstream sources on Azure Artifacts
And I can confirm as of 12/28/2022 this is still an issue. :-(
For debugging I need to push my NuGet packages including Symboles to our self-hosted Azure Devops Server.
Therefore I use the dotnet pack task with the flags --include-symbols and --include-source in my build pipeline. As output I get two files package.1.0.0.nupkg and package.1.0.0.symbols.nupkg.
When I try to push the package.1.0.0.symbols.nupkg package in my release pipeline, I get the feedback:
409 (Conflict - The feed already contains "package.1.0.0".
(DevOps activity ID: 766B8BC7-9AE6-4998-A246-47397236122F)).
I found Publish *.snupkg symbol package to private feed in VSTS on stack. The feedback is that the Azure DevOps Server do not support NuGet Symbols and they suggest to use a symbol server.
Is it a possible workaround to simply rename the package.1.0.0.symbols.nupkg to package.1.0.0.nupkg and push this package to the feed? Is Visual Studio with able to open the debugger inside the sources of these kind of package?
Is there another way to provide NuGet Symbols for debugging on a Azure DevOps Server?
There are multiple questions in your post, let us try to solve them one by one.
Is it a possible workaround to simply rename the
package.1.0.0.symbols.nupkg to package.1.0.0.nupkg and push this
package to the feed?
The answer is no. The error 409 (Conflict - The feed already contains "package.1.0.0" means that you already have one package package.1.0.0.nupkg or package.1.0.0.symbols.nupkg with version 1.0.0 in your feed. So you could not push another package with same version in that feed. Package version in the feed is unique. In order to protect the package from stepping on each other because of the same version of the package.
So, to resolve that error, you need to update the package version, like 1.0.1 (Deleting the old version of the package from the feed will not solve this error).
Is Visual Studio with able to open the debugger inside the sources of
these kind of package?
The short answer is yes. The details will be explained in the next question.
Is there another way to provide NuGet Symbols for debugging on a Azure
DevOps Server?
The answer is yes, we need to configure Visual Studio to enable debugging remote packages. You could refer below Official document and detailed blog:
Debug with symbols in Visual Studio
ASP.NET Core Debugging Nuget Packages with AzureDevOps | VSTS Symbol Server
But when I use nuget install package then only the package.dll is part
of the content which get downloaded from the Azure DevOps Artifacts.
Why is that?
This is expected behavior for installing the package. Because most of the time when we install and use the nuget package, we do not need the debug package, so the installation package will only add the dll we need to the project and will not configure the Symbols package. If we want to debug the package, we have to configure the Symbols package like above links.
The feedback is that the Azure DevOps Server do not support NuGet
Symbols and they suggest to use a symbol server.
The feedback you mentioned in the question is for *.snupkg symbol package not the symbols package. Azure DevOps Server should support publish NuGet Symbols packages, not debug packages, we have to manually configure Visual studio to use the Azure DevOps Server.
BTW, since there are many questions in your post and they are more general, my answer is not very specific. If you have any questions about any specific questions, you are welcome to open a new post with detailed questions.
It seems my team mates have turned off their nuget server and gone on holidays.
I need a temporary work around so that my Azure Dev Ops build does not fail when restoring the nuget packages.
I have a local copy of the package at
C:\Users\kirst.nuget\packages\mypackagetemp
Which I want to publish to a temporary feed.
I read the instructions on publishing a package from the command line but am confused about step 6
Surely I dont need to set up the Project and restore packages as I already have the .nupkg
I tried the command
c:\nuget\nuget.exe push -Source "TempFeed" -ApiKey az mypackagetemp.nupkg
but got an error
unable to load the service index for source
https://pkgs.dev.azure.com/mycompany/myproject/_packageing/TempFeed/nuget/v3/index.json
When I repeat the command I get a request for credentials
When I put in the credentials I connect to Azure Dev Ops with they do not work.
[Update]
I was prompted for credentials.. reading up on it... so confusing.
[Update]
I upgraded nuget.exe from 5.1.0.6013 to the latest version 5.4.0.6315 This time I got a UI to log in and the message
Your package was pushed
However when the devops pipeline build runs I het a message
unable to load the service index for source
https://pkgs.dev.azure.com/mycompany/myproject/_packageing/TempFeed/nuget/v3/index.json
I guess I need to create an index.json file somehow.
My project is using a mynuget.config that has the following in the packagesources
<add key="TempPackage" value="https://pkgs.dev.azure.com/mycompany/_packaging/myfeed/nuget" />
[Update]
I changed mynuget.config to have
<add key="TempPackage" value="https://pkgs.dev.azure.com/mycompany/_packaging/myfeed/nuget/v3/index.json" />
Now the dev ops build shows the message
Failed to retrieve information about 'Serilog.Enrichers.Thread'
from remote source
'https://pkgs.dev.azure.com/mycompany/_packaging/myfeed/nuget/FindPackagesById()?id="Serilog.Enrichers.Thread'',
response status code does not indicate success: 404 (Not Found).)
My solution does use Serilog. I don't think the 3rd party package uses it.
[Update]
The next time I built I got a different error looking for WindowsAzure.Storage
I seem to get a different file causing the error each time I build the pipeline.
My project artifacts does have 2 feeds. The needed files are in the unselected feed.
[Update]
I tried editing mynuget.config to use index.json however I get a build error
The nuget command failed with exit code(1) and error(Unable to load
the service index for source
https://pkgs.dev.azure.com/mycompany/_packaging/myfeed/nuget/v3/index.json.
Response status code does not indicate success: 404 (Not Found - The
feed with ID 'MyFeed' doesn't exist
[Update]
Because the new feed was project based I edited mynuget.config to have
<add key="TempPackage" value="https://pkgs.dev.azure.com/mycompany/myproject/_packaging/myfeed/nuget/v3/index.json" />
Now it works!
In Azure Devops web portal, for your current project, go Artifacts tab and make sure your packages like mypackagetemp.nupkg are available there.
For me, I have custom LibraryCore.nupkg pushed there. Now let's click the Connect to feed settings, choose nuget.exe and you can see:
Copy exactly same content to your own mynuget.config file. Then your build pipeline can access your published mypackagetemp.nupkg.
Failed to retrieve information about 'Serilog.Enrichers.Thread' from
remote source
'https://pkgs.dev.azure.com/mycompany/_packaging/myfeed/nuget/FindPackagesById()?id="Serilog.Enrichers.Thread'',
response status code does not indicate success: 404 (Not Found).)
The next time I built I got a different error looking for
WindowsAzure.Storage
These packages(Serilog.Enrichers.Thread,WindowsAzure.Storage and ...) are all available in nuget.org, so you should also make sure you've add nuget.org as package source in your config file:
In addition:
According to your description, you only need to use your custom devops feed and other packages from nuget.org, apart from using your mynuget.config, you could configure your nuget restore task like this:
Choose devops feed directly(second red line) by Feeds I select here instead of Feeds in my Nuget.config. And check the Use packages from nuget.org checkbox. Then you can access the packages in custom feed and nuget.org during build.
I want to set up continuous integration and deployment for an XAP Mobile app in Azure Devops.
In order to get CI/CD I need to set up the Azure Pipeline to install the right packages.
There is some information in the docs on Hosting your own NuGet feeds
and Get started with NuGet packages in Azure DevOps
Dev Express explained that they do not currently provide a Nuget feed for XAF, but I can make my own Delegate's DCNugetPackageBuilder
Using DXNugetPackageBuilder to make Nuget packages
As per the instructions I downloaded the .pdb files extracted them to c:\tmp\symbols
I also downloaded DXNugetPackageBuilder and edited buildPackages.bat according to instructions.
Next I ran build.ps1 in elevated Powershell
This created the .nupkg files at C:\tmp\Nuget
By default this uses the files located at
C:\Program Files (x86)\DevExpress 18.1\Components\Bin\Framework
and the .pdb files located at
c:\tmp\symbols
Using Nuget.Exe and the Credential Provider to push the packages to the feed
The Connect To Feed screen mentions I need to download Nuget.exe and the credential provider
Here are the docs on the Credentials Provider
I unzipped the VSTS CredentialProviders Nuget.Exe is included.
The next step is to follow the instructions given by the "add this feed" section of the Connect To Feed screen.
For example
nuget.exe push -Source "SBDDevExpress" -ApiKey VSTS c:\tmp\Nuget\DevExpress.Data.18.1.6.0.nupkg
I ran into an access denied issue that got solved here
then I was able to push all the packages I wanted.
Set the Nuget Package Source
In VS2017 with my solution open I used Tools -> Nuget Package Manager -> Package Manager Settings
I added package settings with the Azure endpoint set up as a package source.
Errors building
When I run the build pipeline I get errors like
The type or namespace DevExpress could not be found are you missing a directive or assembly reference?
From studying Updater.cs and Module.cs
It seems I am missing the following namespaces from the Nuget feed.
DevExpress.ExpressApp.DC;
DevExpress.ExpressApp.Updating;
DevExpress.Persistent.BaseImpl.PermissionPolicy;
[Update]
DevExpress suggested I compare the dlls generated in the bin folder with my package feed.
I found several missing files and pushed their packages.
I now have
XafMobile.Module\Properties\licenses.licx(1.0): Error LC0003: Unable to resolve type 'DevExpress.ExpressApp.ModuleBase"
I can see from the source code that ModuleBase is a public class in DevExpress.ExpressApp
I am wondering if this is something to do with reflection.
There is some mention of it at Dev Express support
[Update]
I tried removing the licence files and syncing the project.
Now the errors show as missing assembly references
Also When I rebuild my solution the license files are missing from the properties folders
I wonder if this helps explain it
[Update]
Manuel Grunder [DevExpress MVP] and DXNugetPackageBuilder author explained that
"
When working with nuget.packages you need to reference them via nuget as well
as he explains here
"
As is explained here
"When working with nuget.packages you need to reference them via nuget as well. Thats the reason why it did not work in the first place."