We use various packages of NuGet in our company for productive applications. But we do not know how long a particular version of a package is available.
We do not want to include the packages in the source control system.
To be precise. If our source code is older than 10 years, is then a package in a particular version still available?
With NuGet.org you can delist a NuGet package but not permanently delete it. Delisting removes it from the search results but it is still available for NuGet package restore.
That being said the NuGet team can permanently delete NuGet packages in exceptional circumstances. This has happened at least once, as far as I am aware, when Oracle asked the NuGet team to remove some NuGet packages that were using their software or could be mistaken as being supported by Oracle.
So in practice the NuGet packages will be available as long as NuGet.org is still around. However it is hard to predict what will be happening in 10 years time.
No one knows exactly how long a package is available. When a new version comes out, sometimes the old version is still available and sometimes it's not. AFAIK, they don't have a release schedule, so no one is ever sure when a new version is available until very close to the release date.
Related
We have an .Net 6 API.
We have our own Nuget server to ensure we have backup of used Nuget packages so we always are sure we can run our CI chain.
After the upgrade to .Net 6, then every time MS publishes a new version of any of these three assemblies then our CI builds fail, because our NuGet server doesn't have the new version.
Microsoft.NETCore.App.Runtime.win-x64
Microsoft.AspNetCore.Runtime.win-x64
Microsoft.WindowsDesktop.Runtime.win-x64
Latest with 6.0.8. We then have to download the new packages to our Nuget server and then everything works.
In general I would like us to keep on known versions all the time, and only change referenced package version on purpose - and not just because developers publish new versions.
But I can't find any explicit references to these three packages.
Does anyone know where they come from - and more importantly - are there any way to lock our solution to use e.g. 6.0.8, until we decide to upgrade next time?
Best regards
/Anders
My company has internal components that we deliver via internal NuGet. Now i want to make a Version 5.X of these components which will be breaking a lot from the 4.X versions.
However now if my colleagues browse for updates, the Nuget browser would recommend these new packages.
What i would prefer: If example 4.6 is installed, it would take the highest 4.X version but not 5.0 or above. Making packages for the 5.X path under completely different names would be annoying when the developer choses to upgrade.
Is there a way to mark nuget packages to do something like that? If that's not clear, tell me and i try to clarify.
If your projects are using packages.config, you can use allowedVersions: https://learn.microsoft.com/en-us/nuget/reference/packages-config#schema
There's no way to do this if your project uses PackageReference, but you can upvote (👍) this isse: https://github.com/NuGet/Home/issues/9082
I am using Chocolatey to make installers for a bunch of different tools, but the versions I need for some of these tools are considered outdated and are not available as packages on the Chocolatey package repository. What should I do?
If you are part of an organization, I (and Chocolatey.org) recommend setting up your own Chocolatey feed and building your own packages for internal use. This way, you control the package versions and their sources. Another benefit is that you can host the source internally or embed any installation files in the installer without worrying about distribution rights (as long as the feed is only available internally).
Unfortunately, you can't squeeze blood from a stone. Many packages in the public Chocolatey feed are "unofficial" from the software's point of view (as in, not maintained by the vendor) and as such it's tough to rely on the public feed. If you can't get the package maintainer to update the package, and you don't want to maintain your own feed, then as long as you can commit to keeping the package up to date for the community then consider creating your own community package to maintain.
It was there yesterday and now its page is completely gone. A bunch of my builds straight up started failing, I didnt think that nuget removed packages.
Is there any way I can find out why its just completely gone?
https://www.nuget.org/packages/odp.net.managed/
Indeed. Somehow Oracle removed their nuget package odp.net.managed causing a lot of headaches among developers relying on it.
However, you can use the package Oracle.ManagedDataAccess which offers the same functionality.
In normal situations, permanently removing a nuget package from nuget.org is not supported (source). I guess Oracle explictly forced the nuget.org team to remove it for reasons unknown (maybe licensing?).
I suspect that is one of the NuGet packages that Oracle asked Microsoft to remove from nuget.org.
Oracle identified some NuGet packages that were using their software or made it look as though they were from Oracle and asked Microsoft to remove them.
There is a Package Content and Removals blog post about this which includes information about what NuGet packages should be used instead:
If you are looking for the official Oracle software, they ask that you please download the Oracle.ManagedDataAccess package or the Oracle.ManagedDataAccess.EntityFramework package to work with the Oracle database using Entity Framework.
We use the Entity Framework 6.1.2 NuGet package in 6 solutions. EF was just updated to 6.1.3 and we want to update all of the solutions to use the newest version. Taking the naive route we would open a solution in Visual Studio, use the NuGet Package Manager to update the package, close the solution, repeat for next solution. Running Update-Package EntityFramework in the Package Manager Console is probably a little more efficient than using the GUI but still requires opening each solution individually.
I'd love to be able to run a script which finds all the solutions in a folder and updates the package for (all projects in) each solution. I realize that updating the version number in the packages.config is not the same as installing the new version of a package, so that (very simple) option won't work. I also realize that there's not much efficiency to be gained by doing this one time, but libraries are updated so frequently these days keeping up to date can become an (admittedly minor) annoyance. Is it possible to automate this task?