I recently added MathNet.Numerics through NuGet to my C# solution. The package directory in the solution folder ballooned to about 50 MB! Yet I can simply download the MathNet dll and use only that, which takes up only 1.5 MB. If I want documentation as well, I can include the XML, which is another 3.5 MB.
Am I using Nuget wrong or is this expected behavior? It seems like it is wasting a lot of space.
The reason the package contains that many editions of the same version is a conflict of interests:
We would like to support a wide range of platforms.
We would like to leverage advanced features even if they are only available on some of the platforms (usually only on the full .Net framework, like TPL or System.Numerics), for performance but also for compatibility and usability reasons.
Avoid downstream dependency nightmares by only publishing a single package per version, including all platforms.
If this is causing you problems, consider to bring this point up with the team in discuss.mathdotnet.com (new) or maybe open an issue in GitHub.
PS: If NuGet doesn't work well for you, we also provide Zip archives you can handle manually and pick exactly what you need.
It looks like expected behaviour. It is up to the NuGet package owner to decide how many versions to put in a single package.
You can probably safely delete it, but it'll come back every time you restore the NuGet files. If you are worried about a lot of bloat being included in your build or release, check your .csproj file and make sure you only copy over the MathNet.Numerics.dll version you need.
Related
I'm looking for a simple way to manage NuGet packages for the whole solution, to prevent conflicts between transitive NuGet packages when assembling all files into one installer.
When building a project all direct and indirect dependencies are analyzed and the NuGet resolution picks up the best matching version for each NuGet that is at least the same version as the lowest version and might also create binding redirects if necessary. (all good and fine)
The problem we have lately encountered was when we build the whole solution (200+ projects) at once, the resulting NuGet versions between all top level projects might not be identical. And due to the fact, that all resulting DLL and EXE files are installed into the same program files folder, the application can and will crash at runtime due to version mismatches when loading assemblies.
To better understand this issue I've created this sample repo.
The dependency graph looks like this:
Library1
Microsoft.IdentityModel.Tokens-5.2.1
Executable1
System.IdentityModel.Tokens.Jwt-5.3.0 (transitive reference: Microsoft.IdentityModel.Tokens-5.3.0)
Library1
results in: Microsoft.IdentityModel.Tokens-5.3.0
Executable2
Microsoft.IdentityModel.Tokens-5.2.1
results in: Microsoft.IdentityModel.Tokens-5.2.1
To demonstrate the problem, all projects compile to the same bin folder. When the whole solution is compiled and Executable2 is started, the application crashes, since the application expects Microsoft.IdentityModel.Tokens in version 5.2.1 but the actual version is 5.3.0.
For this constructed sample it is easy to find the problem and fix it with updating the Microsoft.IdentityModel.Tokens NuGet to the same version. (Manually, since Visual Studio Package Manager does not recognize this conflict in the consolidate tab).
But at a much greater scale it is far more complex to find those mismatches.
What we have found so far
Centrally managing NuGet package versions
Since it is not yet available, it cannot be used to solve the issue here.
Microsoft.Build.CentralPackageVersions
Unfortunately there is no IDE support for it, which makes managing NuGet packages very uncomfortable, which I would like to avoid if possible.
So my question is what is the best approach to avoid NuGet version conflicts between projects within the same solution?
We've experienced the same problem with some of our projects. We've been using Paket package manager since a couple of years and this has resolved that issue for us.
In short: you define on your solution level which packages you want to use in a file called 'paket.dependencies'. You can be very specific about versions, or let packet use the latest greatest. Then you can specify per project which NuGet package you want to use within that project in a 'paket.references' file. As the name implies, you reference to a package in the paket.dependencies file.
This will make sure, all references packages in your project will use the same package version. I hope this suits your needs as well.
A few of our NuGet packages, in a framework we use for our ASP.NET MVC sites, reference binaries EVOPdf / EVOPDFtoHTML to be exact that I'd rather not have hard pathed on our build machine. The specific versions we are using are not found on nuget.org any more, so we are forced to hold onto the .dll's ourselves.
The solution I have come to involves housing those binaries in source control, and building them as an in-house NuGet package to be distributed to the other packages that need them; while this works, and though it eliminates hard-pathed references, it goes against standard practice to house binaries in source control.
Because I am one of the few who access this NuGet framework (and the wonders of VSTS) I am not too worried about slowing down our branch splitting/merging times but I am still wondering if there is a more practical way to accomplish this.
First of all, I would like to clarify that I'm coming from a Java/Maven background.
I am managing Nexus and we have a team that are developing in .NET who are asking whether they can store exe files in Nexus under a Nuget repository. As this is not possible (and exe-s are not really artifacts as in "archives"), are Nuget packages a reasonable place to store exe-s? I would personally say "no", as, in my opinion, Nuget packages are supposed to just contain libraries and other resources, but as I'm not a .NET developer myself, I'd like to find out what the best practices are.
are Nuget packages a reasonable place to store exe-s?
If it's a tool, then yes. There are several good examples where Nuget is an excellent place to store exe-files.
For example:
The nuget package dotless has a tool (standalone exe), which is a compiler for CSS-files. This enables us to use that tool in our (TFS-) build server without installing any third party software on the build server.
But other than that, I agree with you. A Nuget-package is mainly for libraries and other resources that will be references in the project. But it's after all just a platform for spreading code between developers and different teams.
Or as Nuget puts it:
No matter what your package does or what code it contains, NuGet is
how you package that functionality into a component that can be shared
with and used by any number of other developers.
If the purpose of your nuget package is to deploy an executable program, then sure you can store an exe in there - what other option is there after all!
We are developing a WPF application at work which has various "common" dependencies (Unity, Prism, etc.).
It's all fine when adding new projects and then setting up the NuGet package dependency per project but when it comes to upgrades, it's really painful as it means we have to go through each and every project, delete the old references and then refetch the latest packages from NuGet.
Today for instance, I was tasked with upgrading Prism from 5.0 to 6.0 (which has breaking changes anyway) and this meant, in addition to fixing all the namespace conflicts, etc. that I had to go through every project, delete the old references, add the new dependecies and rinse and repeat.
My question is, is there a smarter way to deal with this problem or is this the standard approach?
Many thanks in advance,
Update:
I am mostly concerned with "major" upgrades which don't show up on the package manager. Version 5.0 -> 6.0 upgrade would be treated as a major upgrade and hence, would not have an automatic update applied to it in the NuGet package manager.
I don't expect NuGet to be able to do this automatically for me since such upgrades may (and often do) include breaking changes but I would like to know if there's a way to do the major upgrades less painfully than deleting the references from the projects and the packages.config for every project and then re-adding them using NuGet. For a relatively large project, this is very time consuming and I was wondering if anyone had a better way of managing such dependencies.
If you use VS2013 like you say, you can manage ALL your NuGet packages by right-clicking on your Solution and selecting 'Manage NuGet Packages For Solution'. This brings up a dialog where you can view all packages installed for all projects in the solution and all packages that have updates available. When you do upgrade the packages, VS takes care of all the reference changes required. If the package has breaking changes, then you're still on the hook for fixing those.
Disclaimer: I've never worked on a WPF project/solution but for Web/Forms apps, NuGet packages are handled this way.
I can understand your pain because i had the similar problem like you, but there is no easy way. but certainly you need to break the process differently of your daily development and your dependency update roll-out.
for the project i worked on, I use the common repository path that shared among the solutions that you work on, and you need to delete all the solutions folder references in order to get a clean state.
For each solution you work on you need to modify the property group that point to the common target repository (i'm using relative path)
Once all the things setup, you can actually perform an update with a script(I'm using python run-time script)
you can actually look at setting up common nuget-packages-folder for reference updates for detail, but it seems like what you looking at for the automate process
I had a similar problem when trying to upgrade multiple packages with alpha channel issues in Xamarin Studio, which also does not have the niceties of VS 2015 NuGet manager. I ended up writing a very simple PowerShell script that I run multiple times a day.
#
# This script updates local ibGib NuGet packages for mobileGib Android app solution.
# For convenience in copy+paste in manager console:
# ../UpdateLocalNugetPackages.ps1
Update-Package commonGib
Update-Package ibGib
Update-Package languageGib.Biz
Etc.
I believe you could tailor your NuGet commands to fit your needs.
Also, just in case you aren't aware of it, you should definitely read the NuGet command line reference. I may be mistaken, but it sounds like your scenario is doable with the Update command.
At my work place, we are not allowed to install packages from Nuget, so I am just wondering is there any place to download installer instead, so an internal packaging team can distribute it across the firm.
And is the package production ready?
Unfortunately, Microsoft.Bcl.Async is only distributed via NuGet. You would need to use the package manager to get the assemblies, though you could then just copy the assemblies manually into your system.
And is the package production ready?
Yes, it is now production ready. The BCL Team just announced that this package is now considered Stable. From their post:
Being stable means the owner of that package states that API and functionality are unlikely to change and therefore suitable for use in production.
You could just download the package from another PC (out of work) and then copy the assemblies. Of course you don't get the extra benefits from NuGet, but it's still a viable option.
EDIT Just saw that a few days ago the package was declared stable as Reed correctly indicated.