I don't get it - can someone please explain to me why I should use NuGet rather than installing a bunch of libraries via a setup.exe or MSI? What advantage is there?
For example is it better to install Entity Framework 4.3 via NuGet rather than downloading the setup? Also, if I install entity framework via NuGet then is it available to any new solutions or projects that I create (bit confused here).
Basically what does NuGet do that a normal install doesn't do (or vice versa!)
Besides making it simple to add a package to your project, I think NuGet's biggest advantage is dependency management.
NuGet allows project owners to package their libraries as packages. Before, if they depended on other libraries like log4net, they would include those assemblies in their setup/zip file and upload to their web site.
With NuGet, they simply add a reference to these external packages in the .nuspec file. When NuGet installs the package, it will see that there are dependencies and will automatically download and install those packages as well. It also supports conflict management so that if 2 packages depends on different versions, it will figure out the correct one to install.
I think the best way to determine if NuGet will work for you is to actually try using it. I'm sure that once you do, you'll realize that it has many benefits.
Nuget provides several additional benefits:
it automatically configures your projects by adding references to the necessary assemblies, creating and adding project files (e.g. configuration), etc.
it provides package updates
it does all of this very conveniently
What advantage is there?
Nuget simplifies third libraries incorporation : With a single command line (Install-Package EntityFramework) you make your package available for your project. Instead of googling-find the package-download-setup-reference the package in your project...
Auto-Update is not mandatory, Nuget configuration file let you specify the version, or the range of version, that your application is compatible with.
Also, if I install entity framework via Nuget then is it available to any new solutions or projects that I create
Once you installed a package, dlls are copied in a directory at solution level, you can then reference them from there in others projects of your solution.
For each new solutions, re-installing packages is a better solution. As it is very easy with nuget, it won't be a problem.
Nuget contributes to creating a DLL hell and makes the solution go out of control very quickly, especially when different versions of so called "packages" come into play. Apart from assembly versioning, there are now nuget package versions. Nuget is just adding another wrapper over DLLs and does nothing that would make developers' life easier.
Related
In my solution some projects reference the "MahApps" NuGet package, which includes 'System.Windows.Interactivity.dll' 4.5.0.0. Some projects also reference the "Prism" NuGet package, which includes 'System.Windows.Interactivity.dll' 4.0.0.0.
The app.config has a binding redirect of "0.0.0.0-4.5.0.0" to "4.5.0.0" by the way.
A handful of projects reference both NuGet packages, and looking in their "References" lists some of them have S.W.I v4.5.0.0 while others have v4.0.0.0. (I'm guessing this randomness is down to the order in which the packages were installed to the projects).
Sometimes the solution will build and run fine, but if only make a code change in one of the projects referencing S.W.I 4.0.0.0 then I get a runtime error along the lines of "v4.5.0.0 could not be found". v4.0.0.0 is being copied to the build output folder but my binding redirect is telling it to expect 4.5.0.0.
Any thoughts on a solution? I could try uninstalling and reinstalling the packages in the projects causing the issue, to see if I can get them to reference the 4.5.0.0 in the MahApps package, but my concern is that this may not be guaranteed to work during a package restore, screwing it up for another developer (or the build server).
I ended up upgrading to Prism 6, which includes no DLLs other than its own. Thankfully it was a straightforward job.
I also had to remove the MahApps package then add it again, to get Visual Studio to add that package's System.Windows.Interactivity.dll (4.5.0.0).
We use Visual Studio to write and maintain native Windows apps. We are looking into using NuGet to handle our dependencies, which consist of native static libs.
After some research, I've managed to use NuGet, package.config and the CoApp PowerShell scripts to create and consume NuGet packages with native libs in them. The issue we're facing right now is that we need to have Snapshot support.
The rollover PreRelease mechanism (with * for version rollover) that NuGet 3 and onwards supports looks great, however, it seems to only work with project.json and not with package.config. Project.json, however, doesn't seem to work with native packages, as they don't get installed in the local solution folder so the build can't find the headers and libs.
The question boils down to:
Is there a way to use project.json and NuGet 3 with native static libs?
If not, then, what alternatives are out there to support this use case? (The use case being build-time dependency distribution for native, unmanaged Windows static libraries).
EDIT:
At the end, we decided to use Maven for dependency management since NuGet doesn't seem to support our use case. I filed an issue about two weeks ago but it hasn't received any response. However, if we had decided to force NuGet into our use case, the solution proposed by Wendy would probably be the way to go, so I'm accepting it.
There are two ways could add content files into project that uses project.json file. One is "contentFiles" node and another is "files" node in nuspec file. Detailed steps please refer to:
http://blog.nuget.org/20160126/nuget-contentFiles-demystified.html
But please note, these ways only support UWP and Portable class libraries.
This feature is only for packages that will be installed to projects that are managed using a project.json file. Currently only two projects types are managed by a project.json.
1.UWP apps
2.Portable class libraries
The contentFiles option is not available for other project types
If you are using .NET Core application or other type project that use project.json, the content files in nuget package is not supported added into project at present.
What is the difference between a NuGet package, a Reference (is reference similar to a tool?), and a template in Visual Studio?
Why do we need them?
What is done / changed in our project when we install each one of them?
Are they dependent on each other in some way? Which one(s) of them are global installs, and which one(s) need to be installed in every project?
Before any comments or misunderstandings: this answer is NOT composed by me, but it was accepted as an answer here, so for the sake of the users trying to find an answer to this, I am literally Copying the answer to your question in this place.
What is the difference between a NuGet package, a Reference (is reference similar to a tool?), and a template in Visual Studio?
References are used to pull additional libraries into your project. For example, your colleague develop a library which implement some functions that you wanted. You needn't write it by yourself, just add the dll into your project through add reference. Of course you can add any libraries not it come from third part or from Microsoft. But it won't notice you when the libraries changed or updated.
NuGet package is the package manager for the Microsoft development platform including .NET. It will help you manage your packages which installed on your project. When the package has new version released, it will notice you to update it. The NuGet client is a tool provide the ability to produce and consume packages.
Template is similar to a sample project which provides the frameworks based on different type of project. You just need to add your content/functions into this frameworks to implement your requirement. For example, if create a WinForms project, it will reference System.Windows.Forms automatically which contains all stuffs you needed in WinForms project.
Why do we need them?
NuGet package and Reference can help us invoke some functions which have been implemented by others or some have been encapsulated by Microsoft. And the Template can help us create a project without build framework by our self. All of them help us save a lot of time when developing a project.
What is done / changed in our project when we install each one of them?
Add references in your project, it will let you invoke the functions in these references in your project.
Install NuGet packages will add the package reference into your project automatically and then you can use the functions the package provided.
The template will be installed when you install Visual Studio. Most of common templates will be installed. Then you can create a new project through these templates quickly.
Are they dependent on each other in some way? Which one(s) of them are global installs, and which one(s) need to be installed in every project?
Reference and NuGet packages need to referenced/installed on a project. But this project can be create through the templates or can be create by customer self. So in some way, reference and NuGet package are dependent on project.
Templates is global installs and NuGet packages and reference need to be install in every project.
I have noticed many times that developers tend to reference assemblies directly by browsing to the .dll file under the .\packages folder (installed by another project) and adding that to project references instead of installing the nuget package on that project. In that case, even though it compiles, but the Nuget Package Manager does not know that the referenced assembly is from a package, and so updating the package solution-wide does not update those references in that project. If you are doing a Service Oriented architecture where each piece of feature in your application is a separate project in the solution, then you probably have hundred of projects, and managing those references would become a nightmare. Is there any way to prevent developers from referencing assemblies directly if they belong to a nuget package? For example is there any MSBuild task to verify all references to package assemblies require the package to be installed on the project?
If your team uses resharper, they have a plugin to help with this:
http://blog.jetbrains.com/dotnet/2012/11/20/add-packages-not-references-a-nuget-plugin-for-resharper/
I'm guessing the issue is caused by people using resharper without it, since by default VS won't know to include that DLL but Resharper will find it and reference it (and not update package config without the plugin)
Also get used having people using nuget at the solution level, not project level. That will force people to update all nuget packages across the solution, and not leave you with V 1.1.1.0 on Project A and v 1.1.2.0 on Project B.
I'm working on a project that uses nuget but does not use package restore. (This is a decision outside of my control by the way, so any answers that involve enabling package restore aren't ones I'll be able to use.)
A handful of projects in the solution (4 out of a total of 34; a WinJS app store project, two ordinary .NET class library, and one of my Azure cloud projects) are reporting this infamous warning:
...packages\Microsoft.Bcl.Build.1.0.13\tools\Microsoft.Bcl.Build.targets(225,5): warning : All projects referencing Valhalla.Consumer.Core.csproj must install nuget package Microsoft.Bcl.Build. For more information, see http://go.microsoft.com/fwlink/?LinkID=317569.
That link assumes that I'll want to turn package restore on. So does every other bit of advice I've managed to find so far on this subject.
I tried disabling Package Restore in Options -> Package Manager -> General settings, by the way. That doesn't help (and even if it did, it would be undesirable - I use package restore in everything else I work on).
I don't really understand why I'm getting this in a solution that doesn't use package restore. As I understand it, the whole point of the package it's asking for is to support package restore. So in a solution in which package restore is not in use, it seems odd for this package to be present.
However, it appears that certain other nuget packages cause you to depend on this. I have a Windows Runtime Component project that uses Microsoft.Bcl, a nuget package that, for some reason, has a dependency on Microsoft.Bcl.Build. (Visual Studio seemed to add the Microsoft.Bcl package for me when I created the project. Presumably it's necessary.) Other projects seem to acquire a dependency on Microsoft.Bcl.Build via the HTTP client libraries.
So apparently, certain common nuget packages appear to force a dependency on Microsoft.Bcl.Build whether or not you're using package restore.
That would be fine if you could eliminate the warning simply by adding the relevant package to all projects that get this warning. But the vexing thing is that even if I add the Microsoft.Bcl.Build package to the consuming components (e.g., my WinJS Window Store app) I still get this warning! (So it continues to complain that I need to install the nuget package even after I have installed it.)
Does anyone know how to eliminate this warning in this situation? Doing what it asks me to do doesn't seem to be sufficient. What's missing?
I had the same issue. Updating the Microsoft.Bcl.Build package from 1.0.13 to 1.0.14 solved my problem.
We recently had the same issue. Using Nuget 2.8, BCL build 1.0.14, BCL 1.1.9, we had a project A using BCL build, that was referenced by another project B.
Short story: Project B compilation gave the mentioned error although the packaged were added to it. The solution was to remove the packages and re-add them. We ended up doing that for both project A and B.
I believe the cause of the problem was a mismatch in versions. The original project referenced BCL 1.1.8 (the latest version when it was created) was while project B automatically used the more recent BCL 1.1.9.
I am not sure if that's relevant but on the first time we added packages using the project->NuGet package manager, and on the 2'nd time we used the NuGet Console (Tools->Nuget->console).
The remove,add caused a distinct difference in the csproj of project B.
the following lines were added:
<Import Project="..\..\..\packages\Microsoft.Bcl.Build.1.0.14\tools\Microsoft.Bcl.Build.targets" Condition="Exists('..\..\..\packages\Microsoft.Bcl.Build.1.0.14\tools\Microsoft.Bcl.Build.targets')" />