I'm looking for some experience or thoughts on the following problem.
I have a Nuget Package (EntityFrameworkExtras 1.2.0) thats hosted on the main Nuget Feed.
This package has a dependency on EntityFramework. Everything was hunky dorey until EntityFramework 6 was released.
A change in the EntityFramework code means that my package no longer works with EntityFramework 6 and onwards.
I'm trying to consider how best to deal with this problem, i foresee two options:
1) Maintain 2 versions of the Package
So, i would have one version of the package that is compiled with EntityFramework 5.0.0 and the .nuspec would
dictate that it is dependant on EntityFramework [0.0.0 - 5.0.0]
I would introduce a new package called EntityFrameworkExtras (ef6). This package would be compiled in EntityFramework 6.0.0
and the .nuspec would dictate that it is dependant on EntityFramework [6.0.0 >= *]
2) Have a new version of the current package that would support EntityFramework 6.0
so the currently version would support EntityFramework 5.0.0 and less
and i would add a new version of the package (version 2.0.0) that would depend on EntityFramework 6.0.0 [6.0.0 >= *]
I went for option 1) in the end. I believe this is an easier option for the user of the packages because its clear what each of the package's dependencies are.
I also believe its easier to use the nuget commands when working with different packages, rather then attempting to be aware that different versions of one package have different dependency versions.
Also from a development perspective it cleaner and easier to develop and fix bugs on the different packages. Finally, it would make a continuous integration environment easier to implement, because each package would be consider a different project.
Related
According to a recent JFrog Xray scan, our application (.NET 5) has a "critical" vulnerability due to a dependency on a specific version of Microsoft.NETCore.Platforms. There is a newer version of the package with the vulnerability resolved that I want my project to use instead. The problem I'm having is that this is not a package that we've explicitly added to the project, but rather a dependency that some other packages have, so simply adding the newer version of the package to the project isn't enough to remove the dependency entirely; I can still see references to the "bad" version appearing in project.assets.json. Upgrading to the latest version of the top-level packages has helped, but has still left some references to the "bad" version of Microsoft.NETCore.Platforms via dependencies of dependencies of dependencies.
E.g, we're using the very latest version of Microsoft.ApplicationInsights, but this has a dependency on System.Diagnostics.PerformanceCounter, which has a dependency on the "bad" Microsoft.NETCore.Platforms.
TLDR; I want to be able to tell my project "If you have a dependency on this package anywhere in your dependency tree, don't use version X, use version Y instead", but I'm not sure if there exists a way to do this.
You can't change what version of a library your dependencies use because that could easily introduce breaking changes. This is the modern version of DLL hell.
The answer is to update the library that has the old dependency. If it's open source, you can do this yourself and use your forked version with the updated dependencies. If you don't have access to the source then you will have to contact the developer and tell them about the vulnerability.
If the developer is Microsoft, godspeed.
I have started at a new company recently and was tasked to resolve dependency management issues.
Tools:
Visual Studio Enterprise 2015
Nuget 3.x
Team Foundation Server 2012 (won't be upgrading for at least six months)
MS SQL Server 2008
Current Dependency Management solution is to use Project References (it's quite the web of confusion)
.NET FrameWork 4.0 (they won't be upgrading anytime soon - several dozen products all written in 4.0 or earlier)
I have tried to get nuget packages and dependencies to work with VS 2015 and the tools above. The problem I run into is a common one: csproj hintpaths written to the csproj file. If I can't get flexible versions for these dependencies life is unpleasant.
I am looking for something more flexible like Project.JSON where we can use Transitive Restore.
My first impression is I am stuck with classic csproj and hintpath hell.
Thoughts?
With Nuget 3 you can use project.json. That may be the best bet here.
Thanks everyone! :D
In a project we have Umbraco 7.3.4 and it has a dependency for JSON.NET <= 6.0.8. When I'm trying to install other 3rd party packages which require JSON.NET >= 8.0.0, this forces Umbraco to automatically update to version 7.4, which I don't want.
Putting aside considerations of pros and cons of making a hack, I am happy to do a hack because I know that Umbraco works with JSON.NET 8.0.0. The question is how to disable in Nuget automatic update (dependency resolving) only for the Umbraco package? In an ideal case (and much better one) I would only want to ignore JSON.NET dependency for Umbraco package, but let Nuget update Umbraco package if any other cross-dependency update requires this.
Many thanks for an advice
This isn't an Umbraco feature but a Nuget feature, you can include the flag -IgnoreDependencies but it's not selective as far as I am aware. Beware you may well miss other dependencies that could cause you to end up in dependency hell!
Example:
Update-Package Newtonsoft.Json -Version 8.0.0 -IgnoreDependencies
Nuget Documentation:
-IgnoreDependencies
Installs only this package and not its dependencies.
Required: false
See https://docs.nuget.org/consume/package-manager-console-powershell-reference
Warning: Backup your project before attempting this so you can roll it back in the event of a problem!
I need the Microsoft ASP.Net Web Pages NuGet package, but I need the version which targets .net 4.0
How do I figure this out?
Is there a way to figure this out for any given NuGet Package?
The later versions of the Microsoft.AspNet.WebPages NuGet package only support .NET 4.5
The older version 2.0.30506.0 supports .NET 4.0
To figure this out I used the NuGet Package Explorer, displayed the list of package versions and opened a few of the NuGet packages to see what .NET frameworks they support. As far as I am aware you cannot get the supported .NET frameworks from the metadata returned by the nuget.org OData feed. The only way I know is to look inside the NuGet package itself.
I want to make my .net 4 project load the .net 3.5 version of a nuget package so that other .net 3.5 references don't get the nuget dll overwritten in the output directory.
Yikes! If the package has a .NET 3.5 and a .NET 4 version of the DLL, there's no real way to do that other than changing your project to target 3.5 itself.
I can think of a couple of workarounds though. They're not ideal, but they'd probably work.
After you install the nuget package, go into the "packages" directory (it'll be next to your solution (.sln) file. Find the package. Delete the "\lib\net40" folder. This way, NuGet will reference the next version down. You'll have to manually change the assembly reference. Note if you even upgrade this package, you'll have to do this again.
You could create a custom version of this package that only contains your 3.5 version of the DLL. Perhaps put this up in a custom feed at http://myget.org/ and install it from there.
One of those ought to work.