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.
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.
Trying to generate a Nuget Package from dll. One of our project is generating ConfigurationCore.dll and References of project assemblies given below
Microsoft.CSharp
Newtonsoft.Json
Mak.Enums (Custom Nuget Package available on local Nuget Server)
Mak.Operations (Custom Nuget Package available on local Nuget Server)
PresentationCore, PresentationFramework, PresentationFramework.Aero
System, System.Core, System.Data, System.Data.DataSetExtensions
System.Drawing, System.IO.Compression, System.IO.Compression.FileSystem
System.Net.Http, System.Runtime.Serialization, System.Web
System.Xaml, System.Xml, System.Xml.Linq, WindowsBase
Using below ConfigurationCore.nuspec to generate Nuget Package
<?xml version="1.0"?>
<package >
<metadata>
<id>ConfigurationCore</id>
<version>1.2.0</version>
<title>Configuration Core</title>
<authors>MAKK</authors>
<owners>IT Department</owners>
<requireLicenseAcceptance>false</requireLicenseAcceptance>
<description>ConfigurationCore contains core funcationality of Software</description>
<releaseNotes></releaseNotes>
<copyright>Copyright 2018</copyright>
<dependencies>
<dependency id="Newtonsoft.Json" version="10.0.3" />
</dependencies>
</metadata>
<files>
<file src="C:\Users\makk\source\repos\ConfigurationCore\bin\x86\Test\ConfigurationCore.dll" target="lib\net461" />
</files>
</package>
Attempting to gather dependency information for package 'ConfigurationCore.1.2.0' with respect to project 'NugetTest', targeting '.NETFramework,Version=v4.6.1'
Gathering dependency information took 1.09 sec
Attempting to resolve dependencies for package 'ConfigurationCore.1.2.0' with DependencyBehavior 'Lowest'
Resolving dependency information took 0 ms
Resolving actions to install package 'ConfigurationCore.1.2.0'
Resolved actions to install package 'ConfigurationCore.1.2.0'
The V2 feed at 'http://builtsrv1:8080/nuget/FindPackagesById()?id='ConfigurationCore'&semVerLevel=2.0.0' returned an unexpected status code '404 Not Found'.
Time Elapsed: 00:00:02.1513344
========== Finished ==========
Note: The Nuget package source is on local harddrive... Please advise to fix the issue.
Update your Nuget package link.
Go to Project -> Manage Nuget Packages.
Now click on your package source settings.
Update Source Link to https://api.nuget.org/v3/index.json
Your URL should end with /nuget
Example:
http://yourDomain.co/yourNuGetServer/nuget
This is problem of bad connection in the NuGet package. Add the following link into the NuGet Package.
https://api.nuget.org/v3/index.json
Tha
Nuget returned an unexpected status code '404 Not Found' - Package on local drive
Make sure the path in the src="..." is correct.
Perhaps the path should be:
...\ConfigurationCore\ConfigurationCore\... rather than ...\ConfigurationCore\....
In short, make sure you can find the dll file base on that url.
Note: Generally, we recommend using relative paths in url, like:
<file src="bin\x86\Test\ConfigurationCore.dll" target="lib\net461" />
Update the version of nuget.exe.
There is an issue on the nuget.exe 3.4.x, so please download nuget.exe 3.5 and above.
See Create nuget package from dlls for more detailed info.
Update:
Please following below steps to create the nuget package:
Download the nuget.exe, and set it on your local, for example, D:\NuGetLocalFolder.
Create a new project with project name "ConfigurationCore".
Open a cmd and switch to the path where nuget.exe was stored previously.
Use command line:
nuget spec "C:\Users\<Username>\Source\repos\ConfigurationCore\ConfigurationCore\ConfigurationCore.csproj"
You will find the .nuspec be genererated, Do not close this CMD window.
Edit the ConfigurationCore.csproj.nuspec file and modify it, below is my .nuspec file:
<?xml version="1.0"?>
<package >
<metadata>
<id>ConfigurationCore</id>
<version>1.2.0</version>
<title>Configuration Core</title>
<authors>MAKK</authors>
<owners>IT Department</owners>
<requireLicenseAcceptance>false</requireLicenseAcceptance>
<description>ConfigurationCore contains core funcationality of Software</description>
<releaseNotes></releaseNotes>
<copyright>Copyright 2018</copyright>
<dependencies>
<dependency id="Newtonsoft.Json" version="10.0.3" />
</dependencies>
</metadata>
<files>
<file src="C:\Users\Admin\Source\repos\ConfigurationCore\ConfigurationCore\bin\x86\Test\ConfigurationCore.dll" target="lib\net461" />
</files>
</package>
Save ConfigurationCore.csproj.nuspec file, and back to your CMD window, using pack command to generate the nuget package:
The package ConfigurationCore.1.2.0.nupkg was created into the folder where nuget.exe exists, D:\NuGetLocalFolder.
This can happen because you are supplying a "nuget v3" url when only a "nuget v2" url is supported (in my case apt-get was giving me some ancient version of nuget). Typically a nuget source that supports v3 will also support v2, so if your url looks like
https://<something>/api/v3/index.json
try changing it to
https://<something>/api/v2
This is because you are referencing a non existing link: http://builtsrv1:8080/nuget/FindPackagesById()?id='ConfigurationCore'&semVerLevel=2.0.0'
You are using a method inside url, which is invalid and is the cause for the mistake:
//this is an error
../nuget/FindPackagesById()?
fix the url, test it and try again,
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.