I'm not sure if it's possible or not, the target framework in project properties is .NET Core 3.1
I also installed version 3.1.18 and upgraded all related Nuget packages to 3.1.18
is there a way to indicate that the project is using .NET Core 3.1.18? (or is it using the latest by default)
You need only to indicate the major release as described here:
https://learn.microsoft.com/en-us/dotnet/standard/frameworks#latest-versions
Then it depends on your target output, like:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>net6.0-ios14.0</TargetFramework>
<SupportedOSPlatformVersion>13.0</SupportedOSPlatformVersion> (minimum os platform version)
</PropertyGroup>
...
</Project>
or:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFrameworks>netstandard2.0;net45</TargetFrameworks>
<Description>Sample project that targets multiple TFMs</Description>
</PropertyGroup>
</Project>
If you read the documentation you see:
netcoreapp3.1
Then the project will be upgraded at the latest version available on target system.
If you have installed version 3.1.18 on your target system that version will be used.
The nuget packages are, instead, related of your configured nuget sources.
If you have configured your system with the standard sources, the build system or VS will download the version declaration json file from the sources. This file contains the latest stable (or preview, in case you selected it) version number, so the build system will use this file to verify the version number of the package you indicated.
If the package number is compatible with your target framework that package will be downloaded from the related source.
When using .NET Core 3.1 in VS 2019, there is no option to tell the project to use a specific framework version (for example - 3.1.16 or 3.1.18), it will simply use the latest installed version.
Related
Package 'Microsoft.Bcl 1.1.6' was restored using '.NETFramework,Version=v4.6.1, .NETFramework,Version=v4.6.2, .NETFramework,Version=v4.7, .NETFramework,Version=v4.7.1, .NETFramework,Version=v4.7.2, .NETFramework,Version=v4.8' instead of the project target framework '.NETStandard,Version=v2.0'. This package may not be fully compatible with your project.
According to the error message you provided, it lists some supported versions of NETFramework and you are using NETStandard.
So You should change your projecr target framework from .NETStandard to .NETFramework.
I've following structure for a .NET Framework project:
-->ProjectSoln -------->ClassLibProj1 -------->ClassLibProj2 -------->ConsumerLibProj3
I've defined GlobalAssemblyInfo.cs file at solution level and added the reference to this file in all
the 3 projects. ConsumerLibraryProj3 has project reference to ClassLibraryProj1 and ClassLibraryProj2.
I've added nuspec file in the ConsumerLibProj3 that contains $version$.
I'm generating Nuget Package for the ConsumerLibraryProj3 using following command
nuget pack ConsumerLibProj3.csproj -includereferencedprojects -verbosity detailed
The package gets generated successfully, but the version of the ClassLibProj1 and ClassLibProj2 dlls
in the package is not the latest. e.g. in the package ConsumerLibProj3.dll has version 1.0.0.2
whereas the ClassLibProj1.dll and ClassLibProj2.dll has version 1.0.0.1. The expectation is that all
the three dll's should have same version because the the version is coming from the
GlobalAssemblyInfo.cs file. The solution is using .NET Framework type project. Any help will be appreciated.
At last I was able to resolve this issue by forcing the nuget to use release configuration while packing. Surprisingly, I was building the solution with Release profile but still nuget was getting confused somehow. I used following command
nuget pack ConsumerLibProj3.csproj -includereferencedprojects -build -properties configuration=release -verbosity detailed
Thanks for the help.
I am trying to reference from a .NET Core 3.1 project, a NuGet package that targets only net40 via the NuGet compatibility shim. The package is added to my project, however the net40 dependencies are not.
The package is structured as:
lib\
net40\
AssemblyA.dll
nuspec:
<dependencies>
<group targetFramework="net40">
<dependency id="PackageB" version="1.0" />
</group>
</dependencies>
Visual Studio's Package Manager lists the dependencies, but when installed, the dependencies are not listed by VS' Preview Changes window and are indeed not installed. PackageB also targets net40.
It does work if I:
Include the dependencies in an "Any" (blank) dependency group as well as under net40
Remove the net40 dependency group and list the package directly under <dependencies> as a flat list
Remove the net40 under lib\ and use a flat list
These are not ideal as it obfuscates the true nature of the targets frameworks. The last two produce NU5128 on pack. For future reference, I should mention that it's required to remove the dependencies from the local cache for even these scenarios to work (surely a bug?).
Any ideas on how to pull dependencies from such packages? Is this simply not supported? A good test example of this is the "Polly.Net40Async" package.
(VS: 16.6.5, dotnet: 3.1.302, PackageReference, Windows 10)
I am trying to reference from a .NET Core 3.1 project, a NuGet package
that targets only net40 via the NuGet compatibility shim. The package
is added to my project, however the net40 dependencies are not.
The nuget package only targets to net40 which means the package is used for net framework 4+.
And by default, Net Core projects cannot use this type of nuget unless the package and dependencies are listed as supporting Net Core or Net Standard.
==========================================
Also, you can notice the info from the Polly.Net40Async nuget package:
group targetFramework="net40" means that if your project targetframework version is 4+, it will install the listed dependencies.
So you should not install this type of packages into Net Core 3.1 project. And it is designed by the author.
Besides, if you change the sub folder of lib in the nuget package to any, you can add the dependencies into the Net Core project.
After all, any means it targets to any framework versions--net core, net standard, net framework. And you just need to remove the condition of the dependency (contention on Net Framework 4+).
====================================
Add more detailed info
Update 1
Actually, Net Core projects can install some nuget packages which only targets to Net Framework.
In my side, the package can be installed in the Net Core project.However, there is a warning which shows it may not be fully compatible with your Net Core project. Although you can use it, there are still some problems just not encountered in special situations.
For the dependencies, since your project targets to Net Core rather than Net Framework, the dependencies will not be installed automatically along with the main package. But you can manually install these dependencies separately through Nuget Package Manager UI.(search them and then install them one by one).
And if condition group targetFramework="net40" is met, it will install these dependencies automatically along with the main nuget package. But since your project targets to Net Core, it will not install them automatically.
As a suggestion, you could search these dependencies on the Nuget Package Manager UI, and then manually install them separately.
I was using .Net Core 2.1.1, and recently updated the SDK to 2.1.401 (.Net Core Runtime 2.1.3). When i create a new project the version of Microsoft.AspNetCore.App under Dependencies > SDK is still 2.1.1. Looking at the properties of Dependencies > NuGet, the package is being referenced from "C:\Program Files\dotnet\sdk\NuGetFallbackFolder\microsoft.aspnetcore.app\2.1.1"
I tried installing Package 2.1.3 using NuGet package manager, and it downloaded all dependencies from NuGet despite that i have 2.1.3 already installed on my machine.
How do i force existing / new project to use the latest version of packages from the SDK install ?
You shouldn't need to update the version of Microsoft.AspNetCore.App manually in your project. 2.1.1 is perfectly fine. Your application will run on the latest 2.1.* framework installed on the machine.
If you publish a self-contained application, the tooling will automatically switch to the latest known version of 2.1.* at build time for the self-contained build only. (-r win-x64 argument)
This may or may not change for the 2.2 or 3.0 releases, read/follow this GitHub issue and thread for more information.
This is a bug as it has already been reported but for now this can be the solution.
In ProjectName.csproj file:
<PropertyGroup>
<TargetFramework>netcoreapp2.1</TargetFramework>
<RuntimeFrameworkVersion>2.1.3</RuntimeFrameworkVersion>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Microsoft.AspNetCore.App" Version="2.1.3" />
</ItemGroup>
I'm configuring a TFS 2015 build using the new scriptable system. During the build, when NuGet is retoring some packages, it fails with the following error:
The 'System.Collections 4.0.10' package requires NuGet client version
'3.0' or above, but the current NuGet version is '2.8.60318.667'.
The 'System.Diagnostics.Debug 4.0.10' package requires NuGet client
version '3.0' or above, but the current NuGet version is
'2.8.60318.667'.
The 'System.Globalization 4.0.10' package requires NuGet client
version '3.0' or above, but the current NuGet version is
'2.8.60318.667'.
The 'System.Linq 4.0.0' package requires NuGet client version '3.0' or
above, but the current NuGet version is '2.8.60318.667'.
The 'System.Resources.ResourceManager 4.0.0' package requires NuGet
client version '3.0' or above, but the current NuGet version is
'2.8.60318.667'.
The 'System.Runtime 4.0.20' package requires NuGet client version
'3.0' or above, but the current NuGet version is '2.8.60318.667'.
The 'System.Runtime.Extensions 4.0.10' package requires NuGet client
version '3.0' or above, but the current NuGet version is
'2.8.60318.667'.
The 'System.Threading 4.0.10' package requires NuGet client version
'3.0' or above, but the current NuGet version is '2.8.60318.667'.
BTW, I've installed Visual Studio 2015 in the whole build machine and I've checked that NuGet 3.1 is present in the extensions manager menu.
I guess TFS Build is using a different NuGet installation location, but I can't figure out where's looking for it and how do I update it from 2.8.x to 3.x.
There's a workaround to this problem.
By default, if you use VSBuild/MSBuild tasks, you can only choose whether to run nuget restore or not via the appropriate checkbox. But there is a separate task called NuGet Installer (it lives in the Package section). It exposes an optional field for the custom path to the NuGet.exe:
So, here is the idea:
Schedule NuGet Installer step before the appropriate VSBuild/MSBuild step
Specify correct custom path to NuGet.exe
Make sure Restore NuGet packages flag is off for the VSBuild/MSBuild step
NOTE: Your solution with replacing the physical executable directly in the build agent internals might work well up until the agent is updated (either on purpose, or somehow automatically) and overwrites NuGet.exe with newer, but still outdated version.
It was easier than I thought...
After checking the TFS build log I found the following string:
X:\TfsBuild\Agents\project\agent\worker\tools\NuGet.exe
restore
"X:\TfsBuild\Agents\project\c57207ab\path\to\solution\whatever.sln"
-NonInteractive
That is, when TFS build agent ZIP is downloaded from the TFS Web Access, it includes an outdated NuGet executable.
The worst part that there's no publicly available NuGet Command-Line 3.x executable, and I needed to use Google once I've found a post in the official NuGet blog pointing to a NuGet Command-Line 3.1 beta version executable I've replaced the one in the build agent tools location with the beta one, and the error got fixed.
The issue also affects XAML builds
If you want to work with XAML builds, you'll need to download the same NuGet Command-Line executable and copy it to C:\Program Files\Microsoft Team Foundation Server 14.0\Tools\nuget.exe and replace existing one...
I had the same problem. You need to use more recent version of nuget.exe. Version 3.5.0 soved my problem.
You can download Nuget distributions here: https://dist.nuget.org/index.html
There should be a .NuGet folder at the top of your solution. TFS will use the nuget.exe in this folder for package restore operations.
Visit this URL: https://dist.nuget.org/index.html
Download the latest nuget.exe
Delete the existing nuget.exe from the .nuget folder.
Use add/existing item to add the new nuget.exe to this folder.
Check in the change.
You should now be able to queue a build and have it restore packages successfully.