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.
Related
I have uploaded a package(com.test:project0.1) in azure devops Artifact, however when I am making changes in code, the pipeline is getting successful but unable to replace the old package.
Can anyone please assist me.
If you used another nuget package to replace the old one, also, you have set the same version as the old before, then you should remove the old nuget caches first to remove the old one.
You should check the option Disable Local Cache option.
Then, re-run to check that.
Also, if you push a version number for the nuget package, you should modify the nugrt version under csproj file to the new one.
We have a custom feed in Azure DevOps Server for NuGet packages. When uploading the Microsoft.AspNetCore.Authentication.Core 2.2.0 package something went wrong and now we have a bad package in our feed.
According to this question, asked and answered several years ago, it is not possible to replace the package, only increment the number and push a new version.
What are supposed to do when we don't control the version number of the package and need to replace the bad upload?
Right now, the only option we can see is to create a new feed and reupload everything from the old feed.
What are supposed to do when we don't control the version number of the package and need to replace the bad upload?
As I mentioned in that thread, in order to avoid contamination of the package source, MS strictly controls the package version, does not allow upload a newer revision package with that same version number, or delete it and upload a new package at the same version.
So, if we don't control the version number of the package and need to replace the bad upload, we have to create a new feed to save this specify package.
BTW, if you do not want to reupload everything from the old feed, you could try following workaround:
Upload the package Microsoft.AspNetCore.Authentication.Core 2.2.0
to the new feed.
Delete the damaged package from the old feed.
Add the new feed as upstream source for the old feed.
Now, we could restore the nuget package from the old feed.
Note: Do not reverse the order of step 1 and 3, otherwise you could upload the package due to the 409 conflict error.
This is the method I use to download NuGet package using NuGet.Client API.
public DownloadResourceResult DownloadPackage(string packageId, NuGetVersion version)
{
var packageSource = new PackageSource(_Task.PackageSource);
var sourceRepository = new SourceRepository(packageSource, Repository.Provider.GetCoreV3());
DownloadResource downloadResource = _DownloadResource ?? (_DownloadResource = sourceRepository.GetResourceAsync<DownloadResource>().Result);
var packageIdentity = new PackageIdentity(packageId, version);
var packageDownloadContext = new PackageDownloadContext(NullSourceCacheContext.Instance);
string globalPackagesFolder = SettingsUtility.GetGlobalPackagesFolder(_Settings);
return downloadResource.GetDownloadResourceResultAsync(packageIdentity, packageDownloadContext, globalPackagesFolder, _Logger, CancellationToken.None).Result;
}
Overall it does what it's supposed to do. There is one thing I don't understand. Is there a way to tell GetDownloadResourceResultAsync method to ignore current cache and download and unpack the package again.
For example, I have a NuGet package called MyPackage in the NuGet repository. After I call this method to download the package. MyPackage is downloaded and unpacked into C:\Users[CurrentUser].nuget\packages. If I update MyPackage in the repository and then call DownloadPackage again it won't update the cache and the whole system will think the package was not updated. I can manually delete the package from C:\Users[CurrentUser].nuget\packages before downloading but it seems to invasive. I guess there should be a way for better cache control.
I understand normally it might not be necessary because every time you need to change something in the package you change the package version but it is necessary for automatic packaging and deploying in case you need to re-deploy and re-test something without updating the version.
I believe this is an example of an XY problem. NuGet is designed for packages to be immutable, so you're working against the design if you recreate the same package version with different content, even for testing. You only made a passing comment about automatic packaging and deploying, but didn't explain why you're writing custom code to download packages rather than using nuget.exe, so it's hard for me to make a good suggestion.
If you have a CI/CD environment where packages are created automatically, and other tests automatically use them, then I recommend the packages are built with prerelease version numbers and published to a dev nuget feed. For example, here you can see where the ASP.NET team's CI server publishes dev builds of a package, multiple per day. When they're ready to publish the production ready version, a different CI build packs without a prerelease version and pushes to nuget.org instead of their dev feed.
Depending on what you're trying to do, changing the global packages folder might work for you. Assuming you're using git for source control, if you make your test's global packages folder in an ignored part of your git repo, then git clean -Xdf will delete it, and I believe it's common for CI servers to clean before a build. This is also something I've done for local, manual testing where I didn't want to pollute my global cache. I just delete the folder once I'm done.
Ultimately the package cache is just a folder, which you can delete using System.IO APIs, no need for using NuGet APIs. Although, if you want to account for the fact that nuget.config files can change the global packages folder, you might want to use the NuGet APIs to find it. If you don't mind having all packages deleted, you could just run nuget.exe locals global-cache -clear and avoid writing any code.
Well, this is my first Nuget package I publish, it's as simple as any first..
I've published it through this command line:
nuget push PKG.1.0.0.0.nupkg 0000000-000-0000-0000-0000000000 -Source https://www.nuget.org/api/v2/package
but I don't know how to update it, you know how difficult it is to google "update nuget package"!
Changing the version number is all what I needed,
but changing the package name will likely publish new package
Another way, if you do not want to use the CLI and push your package, is to go to nuget and in the upload section, upload your package with a higher version number. It will pick up the package ID so you wont be publishing a whole new package. That will update your package on your behalf after nuget validates the uploaded package.
I have two VS 2013 projects in separate solutions, one of which uses NuGet to manage/consume the other.
I need to change the second project and want to test it in the first one, but I can't publish to our local NuGet repository, in case someone accidentally uses it. Now that I think of it, I don't have publish rights anyway.
I'd like to temporarily, locally redirect the reference to this second, modified project in the first one. How best can I do that, ideally with as little disruption and cleanup when testing is done?
Add a local directory as a NuGet source.
Create a package of the project you want to test and copy it to this directory in step 1
Install the new package from NuGet Package Manager and test.
This way you dont have to change project refs etc.