I'm currently develop a set of libraries that progressively add more features.
For example, in my solution, I have a Foo project which defines some basic feature set, an additional project, Foo.Web, for web specific implementations and Foo.Web.Tokens for even more specific features. Foo.Web.Tokens depends on Foo.Web which depends on Foo.
I'm attempting to build separate nuget projects so a user only needs to reference those dependencies they need. I'm versioning the assemblies with GitVersionTask, so after build, they all get the same version number and I'm using the replacement tokens for nuget when building from a project so that the nuget packages all have the same version number.
My problem is that when I try reference a prerelease version of either Foo.Web or Foo.Web.Tokens nuget is unable to resolve the dependency on Foo. If, for example, I have published a 1.1.0.0-alhpa0001 package for each of the assemblies, when I try and update Foo.Web, nuget shows this error:
Install-Package : Unable to resolve dependency 'Foo (≥ 1.1.0.0)'.
Using the -Pre argument doesn't change this. A Foo.1.1.0-alpha0001.nupkg does exist but I feel like nuget won't resolve it because it's not a stable version, and I'm letting nuget automatically detect the dependencies from the solution using the following command:
.\.nuget\NuGet.exe pack source/Foo.Web/Foo.Web.csproj -Build -Version 1.1.0.0-alpha0001 -symbols -IncludeReferencedProjects
How do I properly allow the Foo.Web prerelease package reference the Foo prerelease package of the same version?
The IncludeReferencedProjects option seems to pull the version from the assemblyinfo.cs of the referenced project.
setting the AssemblyInformationalVersion attribute to the desired nuget package version seems to work as you want it to.
eg
[assembly: AssemblyInformationalVersion("1.1.0-alpha0001")]
Related
Not able to restore packages for AutoFixture.AutoNSubstitute in package. This was working fine earlier but now I am not able to build the solution. Projects are using .NET 6. Unit tests inside solution which are using this project are giving error like
Error CS0234
The type or namespace name 'AutoNSubstitute' does not exist in the namespace 'AutoFixture' (are you missing an assembly reference?)
C:\FILEMAN\test\AStorage.Core.Tests\AutoSubstituteDataAttribute.cs 8 Active
I am not able to add the nuget package when I tried adding the nuget package through the Manage Nuget packages .
Please let me know how I can fix this.
Long story short: I am trying to automate package .net framework nuget updates in a solution via VS2019 package manager console and i can't get a package dependencies on other packages (Though i know the data is available because you can see it in the UI).
Long story long: I am trying to automate nuget installation for .net framework and i chose to use the package manager console in visual studio (If there is a preferred option i would love to hear about it). The problem i am trying to solve is this:
Problem input: Package A: version 1, has dependency on package B version > 1. version 2 has a dependency on package B version > 2. Package B: version 1. version 2 has a breaking change. Package C: version 1, has dependency on package B version > 1.
Problem I am trying to solve: I have these 3 packages referenced by the same project. I want to upgrade package A to version 2. Its dependency is package B version > 2. Running package A update to version 2 (via package manager UI or console) will update package B to version 2. Boom! - package C will detect it is missing a method it requires from B version 1 only at runtime!
What i am trying to do - Scripting the installation process prompting the user for these type of dependencies.
My problem - For that i want to get a package dependencies and i can't find the way to do it using the package manager console.
Appreciate some help :)
For that i want to get a package dependencies and i can't find the way
to do it using the package manager console.
We cannot use nuget manage console to get the package dependencies.In addition to UI viewing nuget package dependencies, we can get the dependencies from csproj file in the nuget project A. This is the related content in A.csproj file:
<ItemGroup>
<PackageReference Include="Antlr">
<Version>3.5.0.2</Version>
</PackageReference>
<PackageReference Include="Microsoft.Extensions.Logging">
<Version>3.0.0</Version>
</PackageReference>
</ItemGroup>
Another is that you can view package dependencies is through the nuspec file which is created by command nuget spec (if you use nuspec files to enforce dependencies), which are the documentation you use before packaging the project.
Scripting the installation process prompting the user for these type
of dependencies.
Note: In view of your situation, you cannot use two versions of the nuget package in the same project which will cause version conflict.
Suggestions:
I wonder why you deleted the method required by C when you upgrade B. Basically, when we upgrade and modify the package, we will new features to it without removing the original data and methods to prevent references to other dependent packages in the project from using the corresponding methods.
So you could restore the methods required by the C package in the Package B version two.
If you make a major change to package B version2 and the steps of restoring the method are a bit complicated, I suggest you can make a copy of package B specifically for C packages.
Just rename the Package B version 1 and referenced by Package C to distinguish it from the second version of the B package.
Hope it could help you.
Could using nuget packages cause dependency dll hell?
Example im using two nuget packages A version 1.0.0 and B in my class library
B is also heavily dependent on new feature which is non backward compatible version of A 2.0.0.
In such a case wont i get build errors? If thats the case isnt nuget scary?
Following is the very long answer. In nuget dependecies could be private when authoring
https://github.com/NuGet/Home/issues/6614
About the same issue if you are using libraries
https://devnet.kentico.com/articles/referencing-multiple-versions-of-the-same-assembly-in-a-single-application
In Visual Studio 2017 Update 3 (15.3), with latest Nuget (4.3.0.4339), I am trying to upgrade Microsoft.Data.Edm from 5.6.4 --> 5.8.2.
Attempting to gather dependency information for package 'Microsoft.Data.Edm.5.8.2' with respect to project 'ConsoleApps\FeedProvider', targeting '.NETFramework,Version=v4.6.1'
Gathering dependency information took 1.98 sec
Attempting to resolve dependencies for package 'Microsoft.Data.Edm.5.8.2' with DependencyBehavior 'Lowest'
Resolving dependency information took 0 ms
Resolving actions to install package 'Microsoft.Data.Edm.5.8.2'
Resolved actions to install package 'Microsoft.Data.Edm.5.8.2'
Time Elapsed: 00:00:02.0136869
========== Finished ==========
On Nuget site Edm package does not list any dependencies. When confirmation window shows up it lists dependencies under installing section, which seem to be pulled from Microsoft.Data.Services.Client .NETStandard 1.1 list of dependencies:
I am clearly not using .NETStandard 1.1 for the project in question (nor any other project in this solution), as you can see if you scroll top log to the right with respect to project 'ConsoleApps\FeedProvider', targeting '.NETFramework,Version=v4.6.1'
Does anyone know what's up, or how to get around this problem?
Does anyone know what's up, or how to get around this problem?
Update answer according to the CrnaStena`s comment.
This package should be a problematic package. According to the Dependencies of the package Microsoft.Data.Services.Client：
We can notice that the dependencies Microsoft.Data.Edm has no framework specific. In this condition, NuGet will install the dependencies in the framework .NET Standard, Version=1.1. That why we got that confirmation window shows up the error dependencies.
In order to track this issue, I have create a new issue on GitHub:
NuGet install the wrong dependecies
To resolve this issue, I downloaded this package and add the dependence Microsoft.Data.Edm in to the .net framework 4.0 by NuGet Package Explorer.
Update:
Since there is a new version released:https://www.nuget.org/packages/Microsoft.Data.Services.Client/5.8.3
I have verified it, and it works fine.
Then save this package to the local feed, install the package from local feed.
Short Version
I author a package which targets .NET Standard 1.3 and 1.6. My 1.6 build references System.Runtime.Loader. This package has a placeholder for the MonoAndroid framework, meaning my NuGet package now can not be loaded in Android 7.x projects.
My .NET Standard 1.3 build does not have this dependency. How can I force NuGet to load the netstandard-1.3 build for Android projects, instead of netstandard-1.6?
More Details
When I try and load our current package in an Android 7 project which uses project.json, I see the below error message:
System.Runtime.Loader 4.3.0 provides a compile-time reference assembly for System.Runtime.Loader on MonoAndroid,Version=v7.1, but there is no run-time assembly compatible with win.
My understanding, is that this is caused by the System.Runtime.Loader NuGet package using placeholders for a number of the target frameworks. The structure of this package, is as such:
lib -> netstandard1.5 -> System.Runtime.Loader.dll
MonoAndroid10 -> _._
I also package a netstandard-1.3 build of my package, which does not reference the System.Runtime.Loader assembly. I'm happy for Android users to get the reduced functionality in the 1.3 build - but I can't figure out how to force NuGet to pick this framework, over .NET Standard 1.6.
My current package structure is below:
lib -> netstandard1.3 -> build13.dll
netstandard1.6 -> build16.dll
I've attempted to change it to the below - to force NuGet to pick the more specific target framework, but NuGet seems to prefer netstandard1.6 over MonoAndroid. (I've also tried MonoAndroid10)
lib -> netstandard1.3 -> build13.dll
MonoAndroid -> build13.dll
netstandard1.6 -> build16.dll
Is there any way, as a package author, I can force my downstream users' Android projects to use the .NET Standard 1.3 build of my project, instead of the 1.6 build, which fails to restore due to the placeholder items in the System.Runtime.Loader package?
I eventually found this was a caching problem.
Everything I assumed about how NuGet should work was correct. The issue was that NuGet appears to cache package dependencies, so when I was rebuilding my package, it was still using the old dependency list. Annoyingly, this is only an internal cache - the Visual Studio UI made it appear that my new package's dependencies were being recognised correctly, yet the logs were showing the old dependencies being installed.
The solution was to clear the NuGet cache between each repackage.