I have a project that uses a package that is no longer available.
When trying to restore the packages I get and error.
When trying to remove the packages using the "Manage Nuget Packages" windows it fails because the feed is no longer available.
How do I remove this package even though the feed is no longer available?
If you do not have access to the original NuGet package (.nupkg) then unfortunately the only way to do this is to manually remove the reference information from the project file and the packages.config file.
NuGet requires the original NuGet package (.nupkg) so it can determine what files should be removed from the project when the NuGet package is uninstalled.
Related
https://github.com/unoplatform/Uno.Telerik.UI-For-UWP is there a nuget for this repo?
I couldn't find any on nuget and Telerik.UI.for.UniversalWindowsPlatform is not support on mobile projects. Thanks.
[Update 2]
I am no longer continuing development on this and instead focusing my efforts on Telerik UI for MAUI.
[Update]
I am working on making this available for the Uno community. You can find it on nuget.org at xxx
[Original]
Telerik doesn't own that fork, so they do not publish a NuGet package for it.
If you would like to have a NuGet package, you can clone the repo locally and compile it yourself. See the Getting Started section of the README to lean how to compile the repository.
Generate NuGet Package
Once it is compiled, you can generate a .nupkg file (see number 6):
Make sure you have the required software to build UWP applications
Clone a copy of the repository code
Open UWPControls.sln located in Controls folder and build it
Open UWPMap.sln located in Controls folder and build it in x86/x64 and ARM configs
All binaries are now located in Binaries folder
You can additionally build a NuGet package by running BuildTools/BuildNuGet.bat. The generated package will be located in the NuGet subfolder.
Next Steps
Once you have your own nupkg file, you can put it in a Package Source (i.e. just a local folder) or put it in your own nuget feed server and list that as a packages source.
I need to update package repo before building a solution in TFS Build Definition. I want to implement this using CommandLine build task.
Could someone tell me how to write a command to update package repo using a path.
According to your prior question, there are just missing some external packages during your TFS build pipeline.
Usually TFS use Package Management that hosts NuGet, npm, and Maven packages alongside all your other TFS assets: source code, builds, releases, etc, also be able to handle the external packages.
You could directly add external packages to a TFS Package Management feed. When you restore the packages, select the feed. All need packages will be restored entirely. To achieve this, just use Push NuGet packages to specify the packages you want to publish and the target feed location.
More details please refer Get started with NuGet Package Management in TFS
While installing the NuGet packages from the NuGet package manage, having configured multiple NuGet package sources in VS2017, the NuGet client tries to retrieve the package in all the configured NuGet sources and returns messages like "Not Found".
I have configured the below NuGet sources in my NuGet.Config,
I have tried to restore the Newtonsoft.Json NuGet package from the command prompt by using the nuget restore command. The NuGet client will try to retrieve the Newtonsoft.Json NuGet package from my custom NuGet feed, which does not contain the Newtonsoft.Json package and returns a NotFound message in the output:
However the package is restored perfectly without issues. But why does the package manager search all the sources which are configured and prints not found errors even it found it in the first NuGet source?
Why does the NuGet client try to retrieve in all configures sources? Is this a bug from NuGet? I am using Visual Studio 2017 (15.4) and NuGet package Manager (4.4.0).
No, it's not a bug.
When the NuGet client is doing a restore and sees you have a dependency on some package, it has no way of knowing which feed the package exists in. In the past, the NuGet client would query each source in order, but at some point it was changed to query all sources concurrently and use the first successful response.
There are also several scenarios where you would want to get a package that is available on nuget.org, from a source other than nuget.org. One example is you might have a private feed with commonly used packages on the same network as your build servers, so that package restore is as quick as possible and more resilient to network outages.
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.
How to gracefully stop support of NuGet package in nuget.org repository? Actually I moved the package to another NuGet channel (e.g. moved https://www.nuget.org/packages/my_old_package/ to https://www.nuget.org/packages/my_new_package/). And want to notify existing subscribers that they should switch.
Currently, I consider the following solutions:
Publish last build with description like "This package is no longer
supported. Switch to other package..."
Simply delete package - not sure how will it affect customers.
What approach can you recommend?
You can unlist the old NuGet package so it will not be found when searching for packages. Unlisting is what happens when you delete the package either from the command line using NuGet.exe or from the gallery on nuget.org.
With the NuGet package being unlisted existing users can still use that package. Restoring the package will still work since the NuGet package still exists.
Notifying existing users of the NuGet package not being supported is not a feature of NuGet. If you need that you would have to implement yourself. For example, you could add a readme.txt to the latest NuGet package which informs the user that this package is now deprecated and they should be using a different NuGet package. The readme.txt will automatically be opened by Visual Studio when the package installed. The only problem here is that this approach is incompatible with unlisting the NuGet package. The NuGet package with the readme.txt would still need to be listed on nuget.org.
Another approach, which may or may not be a possibility, is to have your old NuGet package simply install the other NuGet package. So the old NuGet package has no content itself but just has a dependency on the other NuGet package.
Of these approaches I think I would just unlist all the versions of the old NuGet package. You could also update the package description on nuget.org by editing the metadata directly on the site to indicate the old NuGet package is deprecated.