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.
Related
I have a question described in the title.
In more details: I'm working on a set of Blazor Components. It has many projects each packaged and published as Nuget packages. But of course all projects depends on some AspNetCore Nuget packages. Currently using .NET 5 Version="5.0.0" packages. But recently Microsoft released Version="5.0.3".
<PackageReference Include="Microsoft.AspNetCore.Components.Web" Version="5.0.0" />
<PackageReference Include="Microsoft.AspNetCore.SignalR.Client" Version="5.0.0" />
So the question is what is the recommended way to develop and distribute my (3rd) party Blazor Nuget packages?
a). Keep the dependent MS framework packages version as low as possible? So it works with projects which targets lower versions and might work/or not work with projects which using the latest official MS AspNetCore packages,
b). Or always update to the latest AspNetCore packages to get all bug and security fixes? But in this case who wants to use my packages probably need to update their projects to the latest version as well? Which they might don't want to do.
I think the question can be relevant not just in case of Blazor Nuget packages. But all 3rd party Nuget package which uses other Microsoft Nuget packages
I think that you should have different versions for your NuGet packages, each of them targeting different versions of the framework (and different package versions). This way you provide both backward compatibility and an option to integrate the latest features.
At least that's what I think it's the best way to go to make your solutions usable by a larger scale of developers and solutions.
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 run a .NET Core application on my Windows Server 2016 instance. It builds/runs fine on my Windows 10 machine.
First I'm doing dotnet publish and I copy the published site to the Windows Server instance. I followed this guide and installed both the hosting bundle as well as the latest SDK (2.1.3).
However when I try to dotnet myapp.dll i get the following error message:
It was not possible to find any compatible framework version
The specified framework 'Microsoft.AspNetCore.All', version '2.1.1' was not found.
- Check application dependencies and target a framework version installed at:
C:\Program Files\dotnet\
- Installing .NET Core prerequisites might help resolve this problem:
http://go.microsoft.com/fwlink/?LinkID=798306&clcid=0x409
- The .NET Core framework and SDK can be installed from:
https://aka.ms/dotnet-download
- The following versions are installed:
2.1.0 at [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
I can see clearly that indeed Microsoft.AspNetCore.All only has a 2.1.0 version located in Program Files\dotnet\shared. How do I get the correct 2.1.1 version?
Any guidance is highly appreciated.
Use this link to install 2.1.1 core sdk version:
https://github.com/dotnet/versions/tree/7a833dddfddc27f2074b755b94234a25b9757637/build-info/dotnet/product/cli/release/2.1
Looks like there's been some issue with publishing the Microsoft.AspNetCore.All package, and it is not set to automatically install with VS update/Core SDK install. At least not for me. The nuget package was also added just 10 hours ago with 0 downloads. So by default we're still stuck with 2.1.0. To fix this, the first thing I did was to check what the ASP.NET web app templates use (they keep changing the defaults, so if you have an old project you're updating, it's always handy to check changes in default templates too).
The fix for me was removing the Version parameter from the tag in the .csproj file, as is now done in the default template. Original:
<ItemGroup>
<PackageReference Include="Microsoft.AspNetCore.All" Version="2.1.1" />
</ItemGroup>
After modification:
<ItemGroup>
<PackageReference Include="Microsoft.AspNetCore.All" />
</ItemGroup>
This will essentially resolve to the latest installed version, i.e. 2.1.0 for now. Most likely 2.1.1 will be installed in the later updates. You could also try installing the latest package manually, but I recommend to resorting to default when possible. This way it's less likely that future updates will break my system.
You have two options:
Install the 2.1.1 framework on the server (as mentioned in another answer)
Publish your app with all the required assets. You can do this with the following command:
dotnet publish --self-contained
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.
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.