I have a NuGet package that references Newtonsoft.Json v 12.0.2. I can't access the source to that NuGet package. (Technically, NuGet Package Explorer stats that it's really >= 12.0.2 )
If I wish for that package to leverage Newtonsoft.Json v 12.0.3, is it as simple as me "installing" v 12.0.3 into my project and all dependants (and their children, etc) which are using v 12.0.2 will now be magically using my installed 12.0.3 version?
Or does each dependency only use the version explicitly defined in their package?
What is this called? explicit referencing?
Other Info: This is for .NET Core 3.1
For the new sdk project, when you install a nuget package, it will install its lowest dependencies on your project and if you want to use the higher version, you only need to install the updated dependency nuget package separately and then it will update all the dependencies to the updated version.
And it will update all dependencies of your project to that version. Note that it will not act on a single nuget package but all.
These two nuget packages used Newtonsoft.Json 12.0.2 dependency
And if I install Newtonsoft.Json 12.0.3 nuget package separately:
They all used Newtonsoft.Json 12.0.3 and it proves that they are Shared rather than using a separate version.
Related
Whenever I try to install any package from Nuget through Visual Studio 2022 - be it the GUI or package manager console, I can't seem to find a way to get the highest dependency version.
For example: if I add latest version 1.0.152 protobuf-net.Grpc to my project it has a dependency on Grpc.Core.Api >= 2.36.1. The current version for Grpc.Core.Api is 2.46.3...
In the GUI under options I have no option to control dependency version what so ever it seems like the Install-Package cmdlet doesn't obey -DependencyVersion Highest:
Install-Package protobuf-net.Grpc -DependencyVersion Highest
Installing NuGet package protobuf-net.Grpc 1.0.152.
Committing restore...
Successfully installed 'Grpc.Core.Api 2.36.1'
Successfully installed 'Microsoft.NETCore.Platforms 2.1.0'
Successfully installed 'protobuf-net 2.4.6'
Successfully installed 'protobuf-net.Grpc 1.0.152'
Successfully installed 'System.Memory 4.5.3'
Successfully installed 'System.Private.ServiceModel 4.5.3'
Successfully installed 'System.Reflection.DispatchProxy 4.5.0'
Successfully installed 'System.Security.Principal.Windows 4.5.0'
Successfully installed 'System.ServiceModel.Primitives 4.5.3'
How can I force Nuget to install the highest dependencies version?
According to your description here are some suggestion:
First check your project type “-DependencyVersion Highest” only used in packages.config format.
You can see the project type support about two package management formats: Projects.config and PackageReference.
Someone posted a similar issue on github, see the issue here. Hope this help you.
If you want to use “Grpc.Core.Api 2.46.3 “, you can try to delete the bin and obj folder and then go to Tools>Options>Nuget Package Manager>General>Clear All Nuget Caches.
Then you can install Grpc.Core.Api 2.46.3 package before install protobuf-net.Grpc 1.0.152
I am trying to reference from a .NET Core 3.1 project, a NuGet package that targets only net40 via the NuGet compatibility shim. The package is added to my project, however the net40 dependencies are not.
The package is structured as:
lib\
net40\
AssemblyA.dll
nuspec:
<dependencies>
<group targetFramework="net40">
<dependency id="PackageB" version="1.0" />
</group>
</dependencies>
Visual Studio's Package Manager lists the dependencies, but when installed, the dependencies are not listed by VS' Preview Changes window and are indeed not installed. PackageB also targets net40.
It does work if I:
Include the dependencies in an "Any" (blank) dependency group as well as under net40
Remove the net40 dependency group and list the package directly under <dependencies> as a flat list
Remove the net40 under lib\ and use a flat list
These are not ideal as it obfuscates the true nature of the targets frameworks. The last two produce NU5128 on pack. For future reference, I should mention that it's required to remove the dependencies from the local cache for even these scenarios to work (surely a bug?).
Any ideas on how to pull dependencies from such packages? Is this simply not supported? A good test example of this is the "Polly.Net40Async" package.
(VS: 16.6.5, dotnet: 3.1.302, PackageReference, Windows 10)
I am trying to reference from a .NET Core 3.1 project, a NuGet package
that targets only net40 via the NuGet compatibility shim. The package
is added to my project, however the net40 dependencies are not.
The nuget package only targets to net40 which means the package is used for net framework 4+.
And by default, Net Core projects cannot use this type of nuget unless the package and dependencies are listed as supporting Net Core or Net Standard.
==========================================
Also, you can notice the info from the Polly.Net40Async nuget package:
group targetFramework="net40" means that if your project targetframework version is 4+, it will install the listed dependencies.
So you should not install this type of packages into Net Core 3.1 project. And it is designed by the author.
Besides, if you change the sub folder of lib in the nuget package to any, you can add the dependencies into the Net Core project.
After all, any means it targets to any framework versions--net core, net standard, net framework. And you just need to remove the condition of the dependency (contention on Net Framework 4+).
====================================
Add more detailed info
Update 1
Actually, Net Core projects can install some nuget packages which only targets to Net Framework.
In my side, the package can be installed in the Net Core project.However, there is a warning which shows it may not be fully compatible with your Net Core project. Although you can use it, there are still some problems just not encountered in special situations.
For the dependencies, since your project targets to Net Core rather than Net Framework, the dependencies will not be installed automatically along with the main package. But you can manually install these dependencies separately through Nuget Package Manager UI.(search them and then install them one by one).
And if condition group targetFramework="net40" is met, it will install these dependencies automatically along with the main nuget package. But since your project targets to Net Core, it will not install them automatically.
As a suggestion, you could search these dependencies on the Nuget Package Manager UI, and then manually install them separately.
In a Visual Studio 2015 C# project, is there any way to selectively install the components of a NuGet package? (Aside from manually adding references)
Background:
I have been using the Microsoft.CodeAnalysis.CSharp package recently. This package contains several libraries that I need:
Microsoft.CodeAnalysis
Microsoft.CodeAnalysis.CSharp
It also installs many libraries that these are dependent on. For the features I am using, I only need these two:
System.Collections.Immutable
System.Reflection.Metadata
But it also installs many more libraries that I never need:
System.AppContext
System.ComponentModel.Composition
System.Console
System.Diagnostics.FileVersionInfo
System.Diagnostics.StackTrace
System.IO.FileSystem
System.IO.FileSystem.Primatives
System.Numerics
System.Security.Cryptography.Algorithms
System.Security.Cryptography.Encoding
System.Security.Cryptography.Primitives
System.Security.Cryptography.X509Certificates
System.Text.Encoding.CodePages
System.Threading.Thread
System.Xml
System.Xml.Linq
System.Xml.XmlDocument
System.Xml.XPath
Systen.Xml.XPath.XDocument
Is there someway I can check the boxes of the libraries I want when installing the package?
According to the docs , there only -IgnoreDependencies command could help us ignore all dependencies. We could not ignore part of dependencies.
But you could implement your requirement with -IgnoreDependencies, please refer to following steps:
Install the Microsoft.CodeAnalysis.CSharp package without any dependence:
Install-Package Microsoft.CodeAnalysis.CSharp -IgnoreDependencies
Install the dependence package Microsoft.CodeAnalysis. Common package without any dependence:
Install-Package Microsoft.CodeAnalysis.Common -IgnoreDependencies
Install the dependence package System.Collections.Immutable and System.Reflection.Metadata package:
Install-Package System.Collections.Immutable
Install-Package System.Reflection.Metadata
If you do not need to use the dependences of “System.Collections.Immutable”and “System.Reflection.Metadata”, you can also use the same option to ignore dependences.
Is there any way, when installing a NuGet package. to not attach it to a project? E.g. if the package is content-only, I just want to install it per solution, not per project.
I'm configuring a TFS 2015 build using the new scriptable system. During the build, when NuGet is retoring some packages, it fails with the following error:
The 'System.Collections 4.0.10' package requires NuGet client version
'3.0' or above, but the current NuGet version is '2.8.60318.667'.
The 'System.Diagnostics.Debug 4.0.10' package requires NuGet client
version '3.0' or above, but the current NuGet version is
'2.8.60318.667'.
The 'System.Globalization 4.0.10' package requires NuGet client
version '3.0' or above, but the current NuGet version is
'2.8.60318.667'.
The 'System.Linq 4.0.0' package requires NuGet client version '3.0' or
above, but the current NuGet version is '2.8.60318.667'.
The 'System.Resources.ResourceManager 4.0.0' package requires NuGet
client version '3.0' or above, but the current NuGet version is
'2.8.60318.667'.
The 'System.Runtime 4.0.20' package requires NuGet client version
'3.0' or above, but the current NuGet version is '2.8.60318.667'.
The 'System.Runtime.Extensions 4.0.10' package requires NuGet client
version '3.0' or above, but the current NuGet version is
'2.8.60318.667'.
The 'System.Threading 4.0.10' package requires NuGet client version
'3.0' or above, but the current NuGet version is '2.8.60318.667'.
BTW, I've installed Visual Studio 2015 in the whole build machine and I've checked that NuGet 3.1 is present in the extensions manager menu.
I guess TFS Build is using a different NuGet installation location, but I can't figure out where's looking for it and how do I update it from 2.8.x to 3.x.
There's a workaround to this problem.
By default, if you use VSBuild/MSBuild tasks, you can only choose whether to run nuget restore or not via the appropriate checkbox. But there is a separate task called NuGet Installer (it lives in the Package section). It exposes an optional field for the custom path to the NuGet.exe:
So, here is the idea:
Schedule NuGet Installer step before the appropriate VSBuild/MSBuild step
Specify correct custom path to NuGet.exe
Make sure Restore NuGet packages flag is off for the VSBuild/MSBuild step
NOTE: Your solution with replacing the physical executable directly in the build agent internals might work well up until the agent is updated (either on purpose, or somehow automatically) and overwrites NuGet.exe with newer, but still outdated version.
It was easier than I thought...
After checking the TFS build log I found the following string:
X:\TfsBuild\Agents\project\agent\worker\tools\NuGet.exe
restore
"X:\TfsBuild\Agents\project\c57207ab\path\to\solution\whatever.sln"
-NonInteractive
That is, when TFS build agent ZIP is downloaded from the TFS Web Access, it includes an outdated NuGet executable.
The worst part that there's no publicly available NuGet Command-Line 3.x executable, and I needed to use Google once I've found a post in the official NuGet blog pointing to a NuGet Command-Line 3.1 beta version executable I've replaced the one in the build agent tools location with the beta one, and the error got fixed.
The issue also affects XAML builds
If you want to work with XAML builds, you'll need to download the same NuGet Command-Line executable and copy it to C:\Program Files\Microsoft Team Foundation Server 14.0\Tools\nuget.exe and replace existing one...
I had the same problem. You need to use more recent version of nuget.exe. Version 3.5.0 soved my problem.
You can download Nuget distributions here: https://dist.nuget.org/index.html
There should be a .NuGet folder at the top of your solution. TFS will use the nuget.exe in this folder for package restore operations.
Visit this URL: https://dist.nuget.org/index.html
Download the latest nuget.exe
Delete the existing nuget.exe from the .nuget folder.
Use add/existing item to add the new nuget.exe to this folder.
Check in the change.
You should now be able to queue a build and have it restore packages successfully.