I have a .NET Core 2.2.0 app that references various NuGet packages.
.NET Core relies on PackageReference style packages defined in .csproj project files. It does not rely on packages.config
Nevertheless I expected Restore NuGet Packages ( or Build ) to pull-down all referenced packages and their dependency packages into the project packages folder ( peer level to .csproj or .sln file ).
I expected this because my understanding is that .NET Core follows many of the conventions of open-source package managers such as npm that operate on the principle of self-sufficient app domains.
However the vast majority of the packages are pulled-down to this folder :
C:\Users\username\.nuget\packages\
( A couple packages are pulled into the project packages folder - and I don't see what about these packages is different. )
Apparently Visual Studio and/or NuGet prefers to avoid duplication of effort and cache almost all packages centrally.
Why is this ? And can it be configured differently ?
First, the "open source package manager" behaviour you describe is not really an "open source package manager" behaviour. It's an implementation of some package managers. Java's Maven (mvn), for example, does the same thing as .NET Core and you can't claim maven is closed source.
Second, some package managers, such as npm copy over all dependencies into a package directory (eg, node_modules) because they use sources, not binaries, and because they grab transitive sources and multiple dependencies same names but different versions. NuGet doesn't do that. It uses binaries only and doesn't support multiple versions. NuGet only resolves exactly one version for each dependency in your project. See this stackoverflow post for more information. The exact version resolved and used is written out to the .deps.json file in your build directory.
Third, .NET Core's Self-Contained Deployments - which are meant to be executible/distributable without any other additional dependencies - don't make use of the package cache. When you publish your application (dotnet publish on the command line), all the dependencies are copied to the publish directory. The version is that in the deps.json file, like I said above.
So the main nuget package cache - which is shared on your system with other projects - is just a simple cache of binaries for .NET Core. There's no reason it has to be unique to your project to copied over to your project directory.
Related
Suppose I am building two class libraries in a single solution in visual stuido. The projects are called "Core" and "Extensions".
Extensions depends upon Core.
I would like to publish these as separate nuget packages for other developers to consume, because while the Core package would always be used, the extensions package just provides some optional functionality.
When I am developing the solution in visual studio, however, it is much simpler for me to set a project dependency from Extension to Core. Otherwise (in a naive approach), building the whole solution would require the following steps:
In visual studio, commit and push Core.
Wait for the CI server to build Core and publish the nuget package to our internal feed.
In visual studio, manage nuget packages for the Extensions project.
Connect to the internal nuget feed
Get the updated Core nuget package.
This approach would work, but is obviously very tedious.
The main difficulty I have been encountering while researching how to do this is that the way all of these things interact has been changing quite rapidly over the past few years, with sdk vs non sdk style projects, nuget pack vs dotnet pack vs msbuild pack, and so on and so forth.
Perhaps the most relevant, most recent answer appears in this question How do I create an individual nuget package for each project in a solution, with project references converted to nuget dependencies? however the answer is now quite old, and is for a dot net framework style project (using packages.config), not a .net5 project.
So, can anyone provide up to date advice on how to correctly accomplish the following:
In a visual studio solution with multiple .net5 class library projects, have dependencies set up as project dependencies at dev-time, but convert each project to its own nuget package with the equivalent package dependencies at publish time.
I created a setup project using Microsoft Visual Studio Installer Projects (0.9.3, this is latest for Visual Studio 2019). After setup is executed it installs Nuget package assemblies that are different from the assemblies generated during build.
Why is it doing that and how can I make it to chose assemblies consistent with build assemblies?
My application is for 4.7.2 framework. Typical example is System.ValueTuple.dll (4.0.2)
Build retrieves assembly from:
C:\Users\.nuget\packages\system.valuetuple\4.5.0\lib\net47\System.ValueTuple.dll
Install retrieves assembly from:
C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.7.2\Facades\System.ValueTuple.dll
While install based on 4.0.2 creates a concern but works, when I upgrade nuget package to version 4.6 (and assembly to 4.0.3) install switches to using assembly C:\Users\vgdev.nuget\packages\system.valuetuple\4.5.0\ref\net47\System.ValueTuple.dll
If you look closer, you will notice path above has \ref folder and it contains "reference" assembly. Reference assemblies are not meant to be installed and cause errors BadImageformatException.
The build after Nuget package upgrade continues to pull packages from the correct \lib folder and application works fine. So what I want to do is to make installer work consistently with build. Any advice?
Install retrieves assembly from: C:\Program Files (x86)\Reference
Assemblies\Microsoft\Framework.NETFramework\v4.7.2\Facades\System.ValueTuple.dll
Which way do you reference that package? I can only reproduce this issue when I add reference manually.(Right-click project=>Add reference=>Browse...) If you're doing so, please remove that reference, and add that reference back by Nuget Package Manager UI.
My application is for 4.7.2 framework. Typical example is
System.ValueTuple.dll (4.0.2). When I upgrade nuget package to version 4.6 (and assembly to 4.0.3)
I can only find it with latest 4.5.0 here. And I think it contains the assembly version 4.0.3 instead of 4.0.2.
(I guess something corrupts the process when VS recognize your assembly version cause in most machines it displays 4.0.3 while in one machine, it displays 4.0.2, quite strange...)
The build after Nuget package upgrade continues to pull packages from
the correct \lib folder and application works fine. So what I want to
do is to make installer work consistently with build. Any advice?
Cause of the issue:
This strange behavior may have something to do with Setup project. I can reproduce same situation and I found this issue only occurs when I use PackageReference format to manage nuget packages in my application.(.net 4.7.2)
PackageReference format is the new nuget package manage format after VS2017. I'm not sure if the Setup project fully support for it.
Here're two suggestions which may help:
1.I found this issue only occurs when using PackageReference format. So you can try using Packages.config format in your application. And I've checked the setup project can recognize this format well.
Uninstall all PackageReference format packages, and go Tools=>Nuget Packages Manager=>Nuget Package Manager to set the Allow format selection... to true.
Clean all nuget cache and click ok. After that delete bin and obj folders, then restart VS to add those packages back using Packages.config format.
2.If you continue to use PackageReference format. Try excluding the assembly from ref folder, and manually add that from lib folder by Add=>Assembly=>Browse.
Note: Since Setup project may not fully support packageReference format projects, actually I think #1 could be more suitable for your situation. And you can create a new simple project with packages.config format to check if the issue can be resolved by Packages.config format. Hope it helps :)
It seems that the root cause of the problem is the usage of the BuiltProjectOutputGroupDependencies target by visual studio setup projects instead of the ReferenceCopyLocalPathsOutputGroup target (see PackageReferences put ref instead of lib assemblies in the output group used by VS installer projects).
The proposed workaround is to overwrite the BuiltProjectOutputGroupDependencies target at the end in the project file of your main project:
<Target
Name="BuiltProjectOutputGroupDependencies"
DependsOnTargets="$(BuiltProjectOutputGroupDependenciesDependsOn)"
Returns="#(BuiltProjectOutputGroupDependency)">
<ItemGroup>
<BuiltProjectOutputGroupDependency Include="#(ReferenceCopyLocalPaths->'%(FullPath)');
#(ReferenceDependencyPaths->'%(FullPath)');
#(NativeReferenceFile->'%(FullPath)');
#(_DeploymentLooseManifestFile->'%(FullPath)');
#(ResolvedIsolatedComModules->'%(FullPath)');
#(ReferenceComWrappersToCopyLocal->'%(FullPath)')"/>
</ItemGroup>
</Target>
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')" />
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.