In artifacts I have created a feed,and all seems good. It publishes my packages to the feed.Good
If I understood it correctly it can work like a " private Nuget server" if you like and have all the packages that your team should be using.
I need to push several public packages to my feed.
EG How can I push "Newtonsoft" version 11.2 to my feed on azure devops?
Is this a manual step?
Can be automated?
many thanks
You don't need to do anything. Configure your feed to use NuGet.org as an upstream package source and any packages that are available on NuGet will be automatically cached when restored.
Related
I have a NuGet feed for another source of packages for my project that I'd like to add to the Azure Dev Ops artifacts section as an upstream source, joining the standard NuGet feed. However, despite what the documentation says (https://learn.microsoft.com/en-us/azure/devops/artifacts/how-to/set-up-upstream-sources?view=azure-devops), the only custom option I see is for "custom NPN registry" with a note saying npm is the only package type that supports custom public upstream sources.
I added my feed anyway but it's not findable in Visual Studio's package manager, though I was able to add something from the standard NuGet feed. Is there a setting I'm missing to enable custom NuGet feeds to be added in, or are the docs incorrect here?
I believe you are misreading the documentation.
Custom public upstream sources are only supported with npm registries.
Ref: https://learn.microsoft.com/en-us/azure/devops/artifacts/how-to/set-up-upstream-sources?view=azure-devops#enable-upstream-sources-in-an-existing-feed
If you want to use a single feed for everything, you'll have to implement a bit of a hacky workaround.
The workaround, as unfortunate as it may be, would be to use a scheduled pipeline to synchronize the external feed with your Azure DevOps feed.
I have an Azure Pipelines job setup to authenticate to a private NuGet feed in Azure Artifacts, and then build my .NET project that relies on a NuGet package in the feed. However, my private package is a pretty common name. How can I ensure that it only installs that specific package from my private feed, and doesn't try to fallback to the NuGet general gallery? I do not want it to pull in an incorrect package that has the same name and version name as my private package.
Once you configure multiple sources/feeds, NuGet will look for a package in all these sources together with no guarantee of where the package will be downloaded from. However, you could make the AzDo artifacts feed as the only configured feed and then upstream other sources from it. This way NuGet will get all packages from the configured AzDo artifacts source and AzDo artifacts will source other packages not available with it from the upstreamed sources in the order defined. More info can be found here: https://learn.microsoft.com/en-us/azure/devops/artifacts/concepts/upstream-sources?view=azure-devops
I am looking for practical options to develop and test private nuget packages.
We have a set of "core" code that is delivered securely through an Azure Artifact Feed. We have various "consuming" applications that use the core nuget packages.
As a small-medium team, one person may be developing the core nuget as well as consuming it.
Today we check-in / merge the code for the nuget package. Make sure the Pull request is approved / passes. Then the build updates the Azure Artifact feed.
Then we come back to the "consuming" app and can update the package. Works great if you fix / add the feature the first time. However, slows down productivity when treating this as an iterative development approach.
Looking for simple options for a small team. Random thoughts on options:
Push nuget "alpha" package straight from developer's machine to Azure Artifact feed. Symbol server too?
Do something with an Azure build to allow "feature" branches to publish to Azure Artifact feed somehow?
Push to local nuget feed. Include pdbs so it can be debugged?
Temporarily break the nuget reference directly for local copy of dll(s)?
Re-think using nuget packages as a whole?
Push nuget "alpha" package straight from developer's machine to Azure Artifact feed. Symbol server too?
It depends on whether you need to debug it. If you need do debug this "alpha" package, you have to push the symbol package to the symbol server.
Note: You do not need to push the "alpha" package to the symbol server, just the symbol package.
Do something with an Azure build to allow "feature" branches to
publish to Azure Artifact feed somehow?
There is a task Push NuGet packages, we could use it to publish to Azure Artifact feed during build, no matter which branch it is on. It depends on whether you have enough permissions for the Azure Artifact feed, you can check it from Artifacts->Settings->Feed settings->Permissions:
Push to local nuget feed. Include pdbs so it can be debugged?
No, you also have to include the source code. Check this thread for some more details.
And there is a lightweight solution how to debugged nuget package on local feed on a network share.
Temporarily break the nuget reference directly for local copy of
dll(s)?
Re-think using nuget packages as a whole?
The answer is yes, when we develop the project on the local, use project reference is better than nuget, check my another post for some more details:
Ticket: Project reference VS NuGet.
Hope this helps.
I have a build pipeline setup creating packages from my projects, and a release pipeline that is pushing those packages to the artifact feed, but now (after some change to the pipeline) I'm seeing microsoft packages in my feed.
Any info about why this is happening would be great.
NuGet.org is an upstream source. Your feed is configured to use nuget.org as an upstream source, so it's caching the packages from nuget.org that your applications are using.
I created a build and release pipeline for my NuGet package using VSTS.
But after running the build and release pipeline successfully, the feed includes the nuget.org reference which was added. How can I prevent this?
This is by design. You enabled upstream sources and installed these packages through this feed. Refer to this documentation for details: Saving packages from upstream sources: continuity.
When you enable an upstream source, packages installed from the
upstream source via the feed will automatically be saved in the feed.