I have a confusing issue with Nuget. I have a number of projects who claim to have System.Collections.Immutable installed at version 1.3.0 but if I look at the version of the dll in all the references I see version 1.2.1.0
When I open up the DLL with JustDecompile I see
which declares that the DLL version is indeed 1.2.1.0 but has been installed in directory packages\System.Collections.Immutable.1.3.0
A typical packages.config file will contain
<package id="System.Collections.Immutable" version="1.3.0" targetFramework="net452" />
and the csproj is
<Reference
Include="System.Collections.Immutable, Version=1.2.1.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL">
<HintPath>$(SolutionDir)packages\System.Collections.Immutable.1.3.0\lib\portable-net45+win8+wp8+wpa81\System.Collections.Immutable.dll</HintPath>
<Private>True</Private>
</Reference>
If I try to open the downloaded nuget package from the gallery and open with nuget package explorer I get
The NuGet package version and the assembly version are not necessarily the same. There is no restriction on what versions are used in either.
So looking at System.Collections.Immutable 1.3.0 the assembly version is 1.2.1.0 for the assemblies in the NuGet package.
If you cannot open the NuGet package in the NuGet Package Explorer you can open it in a zip file application such as 7-zip. Or just rename the file to .zip and open it with the built-in Windows zip file extractor.
Got the same problem recently. System.Collections.Immutable is a multi-target package, so the version of the assembly imported to your solution depends on the target. For instance, if you are in a .Net Framework project, this is the file stored in portable-net45+win8+wp8+wpa81 that will be used, hence the different version.
Related
I reference System.Net.Http as a nuget package in my project, the references are correct in packages.config and .csproj file, but in Visual Studio property tab it always uses the package in system's Reference Assembly path, does anybody know why?
Another weird thing is this file in built <webproj>\bin\roslyn has another version, seems it doesn't use the dll file neither in nuget nor in Reference Assembly.
And actually the System.Net.Http.dll in nuget package, in Reference Assembly, in built <webproj>\bin\roslyn directory are have different versions, the file in <webproj>\bin\roslyn seems use the file of Visual Studio directory(C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\Common7\IDE\Extensions\aqwf5fqp.2lv\System.Net.Http.dll or C:\Program Files (x86)\Microsoft SDKs\NuGetPackages\system.net.http\4.3.0\runtimes\win\lib\net46\System.Net.Http.dll or C:\Program Files (x86)\Microsoft SDKs\NuGetPackages\system.net.http\4.3.0\lib\net46\System.Net.Http.dll, judged by its version and file size)
dll in different path
assembly version
dll in nuget, package version 4.3.4
4.1.1.3
dll in Reference Assembly(aka referenced in VS property tab)
4.2.0.0
dll in built <webproj>\bin\roslyn directory
4.1.1.0
in packages.config
<package id="System.Net.Http" version="4.3.4" targetFramework="net472" />
in .csproj
<Reference Include="System.Net.Http, Version=4.1.1.3, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL">
<HintPath>..\lib\Nugets\System.Net.Http.4.3.4\lib\net46\System.Net.Http.dll</HintPath>
<Private>True</Private>
</Reference>
in property tab
And I want to force VS(property tab) or the file in bin\roslyn to use the dll in nuget package, how to do it please? Thank you.
You can try Migrate from packages.config to PackageReference.
This can help you Manage all project dependencies in one place: Just like project to project references and assembly references, NuGet package references (using the PackageReference node) are managed directly within project files rather than using a separate packages.config file.
I created a project that is automatically packed into a NuGet package and added to Azure Artifacts through a pipeline
My NuGet package uses a library from nuget.org called "TextFieldParserStandard"
I install my NuGet by adding the Artifacts Feed package source in Visual Studio
I import classes and use functions, but I receive the error:
System.IO.FileNotFoundException
HResult=0x80070002
Message=Could not load file or assembly 'TextFieldParserStandard, Version=1.0.0.0,
Culture=neutral, PublicKeyToken=null'. The system cannot find the file specified.
If I manually search and add this library in my projects where I use the NuGet, my NuGet works. But they should come automatically. When I install other packages I don't need to manually install their libraries.
So the problem is "TextFieldParserStandard" is not installed automatically at once with my NuGet installation.
In Artifacts Feed, I have only my package "MyNuGet version 1.0.0.11538". I don't know if I should have "TextFieldParserStandard" in my Feed.
In Visual Studio, Manage NuGetPackages, my NuGet does not have any dependencies.
My NuGet SDK: .NET Standard 2.0 (note: compatible with imported projects since it works if I manually add TextFieldParserStandard).
If needed I can give the yaml pipeline. This targets somehow the problem. Build NuGet Package automatically including referenced dependencies
But adding IncludeReferencedProjects to yaml did not solve.
Azure custom Nuget package external libraries
That because you are not add the reference package TextFieldParserStandard to your custom package MyNuGet as dependency.
In this case, it will not automatically install the reference package TextFieldParserStandard to your project when you install the package MyNuGet.
To resolve this issue, you could add the property <PrivateAssets>all</PrivateAssets> for the package TextFieldParserStandard in your project MyNuGet file MyNuGet.csproj:
<ItemGroup>
<PackageReference Include="TextFieldParserStandard" Version="1.0.0">
<PrivateAssets>all</PrivateAssets>
</PackageReference>
</ItemGroup>
Submit this change to the repo, then generate the new package for your custom package, it will have the TextFieldParserStandard package as dependecy:
Update:
Since TextFieldParser cannot be referenced in unit tests.
You could try to create your .nupsec file with Dependencies element, like:
<dependencies>
<dependency id="another-package" version="3.0.0" />
<dependency id="yet-another-package" version="1.0.0" />
</dependencies>
You can refer this document for some more details.
I am being confused by how dependencies are resolved when using a group-based dependency specification in NuGet.
I have a Visual Studio project targeting .NET Framework 4.6.1, with a NuGet dependency to a NuGet package (internal to my company):
This is in the packages.config file of my project:
<package id="Name.Of.My.Package" version="2.0.65" targetFramework="net461" />
And this is in the .csproj file:
<Reference Include="Name.Of.My.Package, Version=0.0.0.0, Culture=neutral, processorArchitecture=MSIL">
<HintPath>..\packages\Name.Of.My.Package.2.0.65\lib\net45\Name.Of.My.Package.dll</HintPath>
</Reference>
That package is a multi-targeting package with a group-based dependency specification, which looks like this when I get it straight from the .nuspec file obtained by opening the packages\Name.Of.My.Package.nupkg file as an archive:
<dependencies>
<group>
<dependency id="Newtonsoft.Json" version="11.0.2" />
</group>
<group targetFramework=".NETFramework4.0">
<dependency id="Microsoft.Bcl.Async" version="1.0.168" />
</group>
</dependencies>
And the packages\Name.Of.My.Package\lib folder contains:
net40
net45
nestandard2.0
So my understanding here is that because my project is in net461, the reference should be added to the net45 version of my package (as seems to be the case if I look at the .csproj file), but more importantly that the only implicit dependency should be to Newtonsoft.
But this happens when I try to remove the Microsoft.Bcl.Async package in the package manager console:
Uninstall-Package Microsoft.Bcl.Async
Attempting to gather dependency information for package 'Microsoft.Bcl.Async.1.0.168' with respect to project 'Name.Of.My.Project', targeting '.NETFramework,Version=v4.6.1'
Resolving actions to uninstall package 'Microsoft.Bcl.Async.1.0.168'
Uninstall-Package : Unable to uninstall 'Microsoft.Bcl.Async.1.0.168' because 'Name.Of.My.Package.2.0.65' depends on it.
This is happening in the latest version of Visual Studio 2017 (15.8.6).
Erroneous dependency resolving for multi-targeting NuGet package
This is the correct behavior of nuget. As we know, .NET Frameworks are backwards compatible. Meaning if your project is targeting v4.6, you can consume packages with lower versions, such as v4.5, v4.0.
NuGet's specialty is compatibility checking (if packages are authored
correctly ofc) :) NuGet knows the available frameworks are v3.5, v4.0,
v4.6 and netstandard1.3. The "nearest" compatible framework with v4.5
is v4.0, so it'll pick the v4.0 assets when you install it.
Source: How to figure out the information of dependency packages for missing frameworks
So nuget will install the dependence "nearest" backwards compatible framework v4.6.1, in you case, the dependency Microsoft.Bcl.Async will also be installed.
That is the reason why you could not uninstall the package Microsoft.Bcl.Async when you have package Name.Of.My.Package installed.
For example, when you add the package Microsoft.AspNet.WebApi.Client 5.2.6 to the .net framework 4.6.1 project, nuget will also add the dependency Newtonsoft.Json (>= 6.0.4) under the .net framework 4.5:
Check this document for some more details.
We have a project on .Net 4.6.1 that we've added IdentityServer packages to.
One error we're getting is apparently solved by updating the System.Net.Http.dll to version 4.3.3 (https://github.com/aspnet/Security/issues/1116)
Problem seems to be that VS 2017 (15.7.3) only references C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net461\lib\System.Net.Http.dll and not packages\System.Net.Http.4.3.3\lib\net46\System.Net.Http.dll even if I manually add it. At least that's the path shown in the reference details window and the version that ends up in the bin folder.
Looking in the .csproj it shows
<Reference Include="System.Net.Http, Version=4.2.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL">
<SpecificVersion>False</SpecificVersion>
<HintPath>..\packages\System.Net.Http.4.3.3\lib\net46\System.Net.Http.dll</HintPath>
</Reference>
One other things that complicates this is that there's no matrix between NuGet versions, file versions, and assembly versions that I could find to help me figure this out.
I'm checking multiple environments but I can only get the file version and there's nothing to cross check that against.
NuGet Package 4.3.3 = File Version: 4.6.25705.1
The version in the framework dir = 4.6.26011.1
Some version in one of our envs that doesn't work = 4.6.25514.4
I am trying to determine how a version number is determined for a nuget package.
I assumed that this would be in the packages.config file. In the packages.config file, this is the version number it is looking for: <package id="UnitClassLibrary" version="1.1.0" targetFramework="portable-net40+sl40+win+wp" /> Likewise, in the .csproj file, it is looking for <Reference Include="UnitClassLibrary, Version=1.1.0, Culture=neutral, processorArchitecture=MSIL">.
So I have defined a need for version 1.1.0 in both of these files. However, when I try to run a nuget restore command, it reports Unable to find version '1.10' of package 'UnitClassLibrary'. I cannot find anywhere that the nuget version is defined as 1.10.