Some packages like AngleSharp have 'Release Notes' in their nuget feed.
IPackageMetadata.cs have ReleaseNotes but it seems this is only used when creating a package.
Is there a way to get ReleaseNotes when possible?
PS: there is an example for metadata, but there is nothing useful there.
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.
So, I've been working on an azure pipeline that is supposed to download a NuGet package and then upload it to a ProGet feet. But it should only upload the package if it doesn't yet exist on the feed to avoid redundancy. (If the package already exists on the feed, but the version is different, it should still be uploaded). Is there a way to check if a package already exists on a ProGet feed using nuget.exe or some other kind of NuGet tool?
You can use one of the several options here.
The first one is to use nuget.exe, in particular, its list command. The following command will list all versions of the package available on the feed:
nuget list <PackageName> -Source <ProgetFeedURL> -AllVersions
where <PackageName> is obviously the [part of the] package name, and <ProgetFeedURL> is the feed URL. The output is a list of packages along with their versions you can easily parse to find out whether the version in question is already on the feed.
The other approach could be to form a download URL for a package in ProGet and send a simple GET request to that URL. The URL is generally formed like this (note that your version of ProGet might form a different URL. You can verify that if you hover a mouse over the Download button in the browser):
http(s)://<ProGetServer>/nuget/<ProGetFeed>/package/<PackageName>/<PackageVersion>
In case this GET request results in 404, you can be sure there's no such version of that package on the feed.
I suppose there must be some REST API of Proget to verify a similar stuff, but I haven't worked with that.
I want to upload a nuget package to my Github repo's "Packages". This is to say I want to upload a nuget to Github Packages.
However uploading the package with the "dotnet nuget" command automatically sets the description of the package in Github to the description of the csproj file. The problem is that there is no other information about the package, specifically - release notes. That is why, considering my repo already shares the same description, I find the only way to inform users of what was changed in a given version is to write it in the "description" of the package on Github.
Is there a way to specify the description either when uploading the package or after that through use of Github Actions or a CLI or an API or whatever? Because I want it to be done automatically, rather than by hand for every version.
The documentation is silent on this matter.
I want to publish a new version of a NuGet package, but I want it automatically in an Unlisted status. When I manually upload the .nupkg file to nuget.org, in the preview there is an option to unlist the package from search results:
Is there a way to do that with nuget.exe or dotnet nuget?
I was able to use PUSH + DELETE commands to achieve this, but I'm not sure this is the same as the above manual action.
For instance, one of the concerns is what happens to the package's RSS (atom.xml)?
Does it first get a new entry which is then deleted later on? In which case, is it possible that someone would still get notified about this release?
Last, I am aware of private NuGet feeds, but regardless, I would still like to use just the main NuGet, for convenience's sake.
I've got a public nuget package that has a prerelease version that depends on the aspnetwebstacknightly feed on myget. Does anyone know if there's a way to create a dependency in my package on that feed? I haven't been able to find anything helpful. I'm guessing there's no way to do this, but just want to try SO as a last resort. :)
You can have the dependency defined in your package. The only issue is that when you push yours to nuget.org without that dependency being present there, your package consumers will have to configure the MyGet feed as well for that dependency to be resolved during install time.
More precisely, the MyGet feed should be put below the NuGet.org feed, and your package should be installed using the "All" aggregate package source.
You could communicate this in your package readme.txt or in your package metadata to have it visible on the NuGet.org package details page. You could also try to add some PowerShell scripts and try to find a way around it, but the issue you're fighting with is by design. However, I would not recommend doing any of this.
Basically, you'll have this issue as long as your dependency has not been pushed to NuGet.org. Why not expose your pre-release package on MyGet and configure the aspnetwebstacknightly MyGet feed as an upstream package source in your feed? Be sure to enable the "proxy" checkbox for this package source so that your dependency will be resolved as well without consumers needing to configure both feeds (installing your package from your feed would also fetch your dependency from your feed - which under the hood then queries the aspnetwebstacknightly feed).
Hope that helps!