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.
Related
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.
I would like to add a few packages to proget from nuget.org.
For example I am trying to add NLog but get an error:
The package could not be installed.
The package was not found in the remote repository.
It seems to work if I download the packages to disk first and then upload them.
Same problem here. This seems specific to NLog though, as I can install other packages just fine (e.g. log4net, nlog.config). I used https://www.nuget.org/api/v2 as the feed though (slightly different from yours #Damian). I've reported it to the ProGet support team, let's see.
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.
After updating the nu-get packages for a previously working Azure Mobile Service (.Net back-end), I now get the following error when accessing Table Controllers:
An error has occurred.","exceptionMessage":"Object reference not set to an instance of an
object.",
"exceptionType":"System.NullReferenceException",
"stackTrace":"at Microsoft.WindowsAzure.Mobile.Service.Serialization.
SelectExpandWrapperConverter.ODataReflectedTypes..ctor()
at Microsoft.WindowsAzure.Mobile.Service.Serialization ...
Custom Controllers appear to be unaffected.
I've probably missed something obvious, but I can't see it
Any help would be appreciated
Many Thanks
K.
From Henrik F. Nielsen's answer in the MSDN forums:
There are known incompatibilities with the latest version of ASP.NET Web API which was released the same day as our last update. We are working on an update but in the mean time please don't update all your NuGets but only the WindowsAzure.MobileServices.* packages -- they will then include the right dependencies the need.
This is an integration issue with the .NET backend binaries, and it should be resolved soon.
Expanding on #carlosfigueira's answer, it seems that the WepApi 5.2.0 version is not compatible with Azure Mobile Services yet.
I am one of the unfortunate ones who decided to let nuget go to town and update all the packages in the project so here is what I did to deal with this.
Uninstall every nuget package from your mobile service project. Then add them back. Start by using only the Microsoft Azure Mobile Services.NET Backend.* packages - This will pull the currently compatible WebApi 5.1.2 instead of 5.2.0. and other dependent assemblies.
In addition, I was getting a lot of weird redirect binding errors which I believe the tooling added incorrectly - so I commented out all the dependentAssembly tags in the assemblyBindings and then added them back as the mobile service complained. All I had to add back for redirects were Newtonsoft.Json and Microsoft.Owin. YMMV.
I think this may also have something to do with the fact that there are strange interactions between VS and source control plugins since nuget packages sometimes fail because they can't obtain write permissions for packages.config and web.config files.
I am also using a PCL in my service which requires adding the Microsoft.Bcl libraries - perhaps irrelevant but it is what lead me to discovering the underlying error.
Under Tools -> Options -> Projects and Solutions -> Build and Run, set the MSBuild project build output verbosity to Detailed or above to get some insight into what is happening in the process.
[Update 12/24/2014]
I updated something I shouldn't have and everything broke again.
Uninstall all nuget packages. Delete all dependentAssembly elements from the Web.Config file. Save and restart Visual Studio.
Start adding packages back using the following from the Package Manager Console. In my case:
Install-Package WindowsAzure.MobileServices.Backend -Version 1.0.405
Install-Package WindowsAzure.MobileServices.Backend.Tables -Version 1.0.405
Install-Package WindowsAzure.MobileServices.Backend.Entity -Version 1.0.405
Install-Package WindowsAzure.MobileServices.Backend.SignalR -Version 1.0.405
Install-Package WindowsAzure.MobileServices.Backend.Storage -Version 1.0.405
Never touch it again...?