I have been setting the package references in my .csproj files to accept any minor version of dependent NuGet packages (see NuGet Package Versioning reference examples). An example of this might be as per the below:
<!-- Accepts any 6.2.x version. -->
<PackageReference Include="ExamplePackage" Version="6.2.*" />
However, whilst this appears to work (i.e. the latest release version of 6.2.2 is restored), the NuGet package manager GUI built into Visual Studio appears to read the package reference as 6.2.0 and prompts me to upgrade to 6.2.2.
Performing a restore from the command line appears to download 6.2.2 but I cannot get the VS Package Manager to play ball.
Is there any way to get the VS Nuget Package Manager GUI to accept that 6.2.2 is what has actually been restored?
However, whilst this appears to work (i.e. the latest release version of 6.2.2 is restored), the NuGet package manager GUI built into Visual Studio appears to read the package reference as 6.2.0 and prompts me to upgrade to 6.2.2
This is a known issue about the PackageReference versioning with wildcard.
It seems use a wildcard * is the correct way for NuGet Restore to float to a higher version. However, the NuGet package manager GUI still takes the lowest version. The current workaround is update the nuget package to the latest version via NuGet package manager GUI, but this way will remove the wildcard *.
For tracking this NuGet issue, I recommend that you vote on and follow the earlier reported issue for updates and fix notifications:
https://github.com/NuGet/Home/issues/3788
Hope this helps.
Related
I am building a netstandard2.0, with a series of sub-dependencies, including Azure.Data.Tables. I have found that Azure.Data.Tables on >=12.3.0 is not compatible with 2.2 projects, but version 12.0.0 is (or at least it doesn't crash my .Net Core 2.2 application).
Based on these premises the resolution was simple: put version 12.0.0 in the netstandard library dependencies. There's only one problem, that when I install this library using Visual Studio into my Net Core 2.2 project I get that visual studio decides to install 12.3.0.
I have checked documentation around enforcing certain versions using the allowed wildcards(https://learn.microsoft.com/en-us/nuget/concepts/package-versioning#version-ranges-and-wildcards), such as:
<PackageReference Include="Azure.Data.Tables" Version="[12.0.0]" />
Which produces this package description just before pressing "install".
But it doens't seem to work, Visual Studio simply carries on with the 12.3.0 installation.
It turns out Visual Studio was just using the nuget cache for my locally generated packages. If I either changed the version of the packaged package then the sub-dependencies would change. As well, another way of getting the precise package would be to clear nuget's cache locally: nuget locals all -clear.
having spent the better part of two days on this, time to get some help.
I am reworking our CI build, and have a VS2017 solution which was on .net 4.6.1, using packages.config style nuget refs, and TeamCity was using the NuGet runner v3.4.4 to restore the packages. It was originally build probably using VS2008 or 10, then converted to 2017 in 2018. Someone checked in the packages directory and it's been that way for years.
Time to bring it up to more modern standards. I converted the projects to use packageReference, and now am using msbuild and the restore;build target to restore my packages and build the solution. Works well EXCEPT for this one package.
Even in VisualStudio 2017 15.8.7, the build (which does the restore of course) is failing to restore the smtp-impostor package using a packageReference with the following error:
NU1202: Package smtp-impostor 2.0.8 is not compatible with net461 (.NETFramework,Version=v4.0). Package smtp-impostor 2.0.8 supports: netframework40 (.NetFramework 4.0,Version=v0.0)
I can't get Google to find a single useful post when searching for "netframework40".
If I use nuget3.4.4 CLI, it works fine (it seems to call msbuild 4.0). If I use nuget 5.6 CLI, I get the error message; it's using the msbuild that comes with Visual Studio 2017.
I see a lot of posts on how to get nuget to use a different version of msbuild, but I don't see how to tell msbuild to use an earlier version of nuget!
I have tried:
retargeting the solution to v4.0 - same error occurs - first part of error just changes to net40
setting the ToolsVersion in the csproj file tag to 14.0
Setting the PlatformToolsVersion property in the csproj file to 14.0.
No dice.
I really don't want to stay with packages.config for this project (and an extra CI build step) nor checkin the single DLL for the package into my repo. It's looking more like I'll jsut have to scrap the packageReference upgrade and stick with the old style nuget runner package restore.
Anyone ever seen this? Any ideas where "netframework40" comes from and why newer nuget can't match it with net40?
Thank you in Advance!
Newer versions of NuGet.exe can't resolve framework match when
restoring older packages (net40, netframework40)
The issue is that this nuget package smtp-impostor 2.0.8 is not compatible with the new PackageReference format and has nothing to do with Nuget V3.4.4 or Nuget V5.6.x.
Actually, the package was published on 2011 and the new package management format PackageReference was used since VS2017.
Besides, the author did not make any changes to the package to accommodate the new Packagereference. And I faced the same issue in my side.
Suggestion
As a workaround, you have to use packages.config to install this nuget package rather than PackageReference.
Since VS2017, VS adds the new PackageReference nuget management format and for your old VS2008, it uses Packages.config.
Or you could contains the author of the nuget package to change it.
I'm trying to understand how the roll-forward mechanism with Microsoft.AspNetCore.App is supposed to work along with other nuget packages.
My understanding so far is that any time I publish my app, .netcore will automatically publish the app on the latest patched version that I have installed. This doesn't sound like a good practice to me. I think the application should be deployed on the .net version that it was developed on.
I recently ran into a problem where my build server has a newer SDK installed than I have on my development machine, so it tried to publish the app with a newer .netcore version.
This caused the build to break with the following error:
error NU1605: Detected package downgrade: Microsoft.EntityFrameworkCore.Design from 2.1.8 to 2.1.4. Reference the package directly from the project to select a different version.
I have explicitly specified that I want version 2.1.4 of Microsoft.EntityFrameworkCore.Design because that was the latest version that was available when I originally developed the application.
I feel like I'm missing something here. Am I supposed to make sure that I always
have the same SDK installed locally as the build server and that all of my apps are updated to the latest SDK every time I need to make a change? What if a co-worker wants to write a .netcore app targeting a newer version of the framework so they request that a new SDK be installed on the build server? Surely I shouldn't have to also update my app to the latest patch version.
You experienced the problem because when you reference the versionless Microsoft.AspNetCore.App you shouldn't reference packages which already are pulled in by the metapackage.
Because the metapackage already contains Microsoft.EntityFrameworkCore.Design and you specified a hard version you got a version conflict.
This usually happens when you have one project with the metapackage in another (for example test project) have a specified version. What happens then is that when building it will determine the highest version and use that but when it gets to the test project it will need to downgrade (because of the specified version) and will throw a build error. The recommended way until 3.0 is to add <Project Sdk="Microsoft.NET.Sdk.Web"> to the test project and also use the metapackage.
As far as I know it works like this: When you reference Microsoft.AspNetCore.App it will take the lowest possible version it can. So if for example your targetframework is netcoreapp2.1 then it will take 2.1.1. When it builds it will look what the highest possible version is of the shared framework you have installed for and use that. If you have the following runtimes installed: 2.2.0, 2.1.5, 2.1.12 it will roll forward to 2.1.12. There are some additional roll forward policies having to do with the minor (if its a preview version or not ect.) but those only happen when it can't find a runtime corresponding to the major and minor version.
See also: https://github.com/aspnet/AspNetCore/issues/3292 and https://github.com/aspnet/AspNetCore.Docs/issues/6430
I have a number of projects inside a solution that are .netcoreapp11 based.
In Visual Studio Ver 15.5.6, with Nuget Package Manager Ver 4.5.0,
I have a page full of updates that show Dependencies on .NETStandard, Version=v2.0.
Trying to update any of them results in
Package Microsoft.AspNetCore.Server.Kestrel... 2.0.1 is not compatible with netcoreapp1.1
I am not in a position to move our Solution to .Net Core 2 at this time.
How do I configure my solution or nuget to not suggest updates I am unable to apply?
How do I configure my solution or nuget to not suggest updates I am unable to apply?
I am afraid there is no such direct configuration for your solution or nuget to not suggest updates for all packages automatically.
That is because nuget only detect if there is a higher version in all nuget sources based on the version in the PackageReference rather than detect that the version to be upgraded is compatible with the Target framework. Only when we install nuget package to the project, nuget will detect whether this package is compatible with the Target framework. This is default design for nuget. So we could not direct configuration for the solution or nuget to not suggest updates before we install that packages.
To resolve this issue, there is a workaround that we could manually constrain nuget package upgrade versions for each package by specifying version range Version="[1.*, 2.0.0)":
<ItemGroup>
<PackageReference Include="Microsoft.AspNetCore.Server.Kestrel" Version="[1.*, 2.0.0)" />
</ItemGroup>
In this case, when nuget will not suggest update that package to version 2.0:
Note: You should use a * is the correct way to float to a higher version.
Hope this helps.
I am using teamcity for creating nuget packages that are being feed to a octopus deploy server. I ran into a problem regarding the dll versions that are installed as a nuget dependency, more precisely they are updated to the latest version instead of the specified version, even though in csproj, it checked the option specific version.
I don't know where it is the problem, on the local machine the build does not upgrade the dll, only on teamcity.
Is it msbuild related, or some set up to the nuget installer step, when I restore the nuget package.
Thanks in advance.