I have a profile111-pcl-assembly which should be used by a netstandard2.0 class library.
The compatibility chart [1] says that Profile111 already is compatible with netstandard1.1.
But I always get this silly warning:
warning NU1701: Package 'Name' was restored using
'.NETFramework,Version=v4.6.1' instead of the project target framework
'.NETStandard,Version=v2.0'. This package may not be fully compatible
with your project.
Why the f*ck should it NOT be fully compatible with my project?
I already tried using <PackageTargetFallback> but this did not change anything.
[1] https://learn.microsoft.com/en-us/nuget/schema/target-frameworks
Related
While trying to use HeaderNames.XFrameOptions, I found that it works in one of my projects and fails in another. Both are targeting .NET 6.
In my app, I need to work with the X-Frame-Options HTTP header. When possible, for maintainability reasons, I try to evade specifying constants for such standard strings myself, relying on standard constants instead. For this header's name, there is HeaderNames.XFrameOptions, available since ASP.NET Core 3.0.
By navigating to the class's implementation in VS, I found that the project where it works uses version 6.0.0.0 (.NET 6, x64) of the Microsoft.Net.Http.Headers assembly:
C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App\6.0.12\Microsoft.Net.Http.Headers.dll
The project where it does not work uses version 2.2.0.0 (.NET Standard 2.0, MSIL) of the assembly:
C:\Program Files\dotnet\sdk\NuGetFallbackFolder\microsoft.net.http.headers\2.2.0\lib\netstandard2.0\Microsoft.Net.Http.Headers.dll
The working project is the main project of my console app and the broken project is a library in the same solution, directly referenced by the console app.
When I looked into the broken project's obj\project.assets.json, I found that Microsoft.Net.Http.Headers is really used in version 2.2.0 and it is referenced by Microsoft.AspNetCore.Http.Extensions/2.2.0, which is also used in the broken project.
I used that info to reproduce the failure:
dotnet new globaljson --sdk-version 6.0.404 --roll-forward disable
dotnet new console -f net6.0
dotnet add package Microsoft.AspNetCore.Http.Extensions --version 2.2.0
echo "Console.WriteLine(Microsoft.Net.Http.Headers.HeaderNames.XFrameOptions);" > Program.cs
dotnet run
C:\Repos\playground\Program.cs(1,58): error CS0117: 'HeaderNames' does not contain a definition for 'XFrameOptions' [C:\Repos\playground\playground.csproj]
The build failed. Fix the build errors and run again.
I tried adding all the packages referenced by the working project to the repro project and it fixed it! By elimination and following the dependencies of the last remaining project, I found that the fix can be achieved by adding just a single package (AspNetCore.HealthChecks.UI.Client/6.0.5):
dotnet add package AspNetCore.HealthChecks.UI.Client --version 6.0.5
dotnet run
X-Frame-Options
I see that AspNetCore.HealthChecks.UI.Client references the Microsoft.Net.Http.Headers assembly version 6.0.0.0, but directly, as an assembly, not as a NuGet package. Sadly, the latest packaged version is 2.2.0.0.
How can I make HeaderNames.XFrameOptions work in both my projects at the same time? Is installing an irrelevant package like AspNetCore.HealthChecks.UI.Client the only solution? And is there a more straightforward way to diagnose such assembly resolution issues?
I have a solution with multiple projects, which generates a Visual Studio Package.
Some of the projects and the Nuget packages are shown below. The top level Visual Studio Extension is MultiLanguageWPF.
MultiLanguageWPF
|
+-- MultiLanguageLegacy
| | Nuget: Microsoft.CodeAnalysis.Analyzers Version 1.0.0
| |
| +-- MultiLangCodeParser
| | Nuget: Microsoft.CodeAnalysis.Analyzers Version 1.0.0
| | Nuget: Microsoft.CodeAnalysis.Compilers Version 1.0.0
| |
+---+-- MultiLangCommon
Nuget: Microsoft.CodeAnalysis Version 1.0.0
Nuget: Microsoft.CodeAnalysis.Analyzers Version 1.0.0
All of these Nuget packages are included in the version 1.0.0. All of the projects are built against Framework 4.7.2.
This question is about three warnings which are generated for the project MultiLanaguageWPF:
Found conflicts between different versions of "Microsoft.CodeAnalysis"
that could not be resolved. These reference conflicts are listed in
the build log when log verbosity is set to detailed.
Found conflicts between different versions of
"Microsoft.CodeAnalysis.VisualBasic" that could not be resolved.
These reference conflicts are listed in the build log when log
verbosity is set to detailed.
Found conflicts between different versions of
"Microsoft.CodeAnalysis.CSharp" that could not be resolved. These
reference conflicts are listed in the build log when log verbosity is
set to detailed.
The packages Microsoft.CodeAnalysis.VisualBasic and Microsoft.CodeAnalysis.CSharp are dependencies of the package Microsoft.CodeAnalysis.Compilers.
These three warnings are generated for the project MultiLanaguageWPF, which does not actually use these packages. Obviously all referenced DLLs have to be pulled into the top level project and ultimately packed into the VSIX installation, so I guess that does make sense.
As suggested in the warning messages, I have set the log verbosity to detailed. For the package Microsoft.CodeAnalysis, this is some of what I see.
16> Primary reference "Microsoft.CodeAnalysis, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35".
16> Resolved file path is "C:\Users\Phil\.nuget\packages\microsoft.codeanalysis.common\1.0.0\lib\net45\Microsoft.CodeAnalysis.dll".
16> Reference found at search path location "{RawFileName}".
16> Found related file "C:\Users\Phil\.nuget\packages\microsoft.codeanalysis.common\1.0.0\lib\net45\Microsoft.CodeAnalysis.xml".
16> This reference is not "CopyLocal" because at least one source item had "Private" set to "false" and no source items had "Private" set to "true".
16> The ImageRuntimeVersion for this reference is "v4.0.30319".
16> Unified Dependency "Microsoft.CodeAnalysis, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35".
16> Using this version instead of original version "1.0.0.0" in "C:\MultiLang_Version_7_1\VS2013\MultiLang\bin\Debug\MultiLanguageLegacy.dll" because AutoUnify is 'true'.
16> Using this version instead of original version "1.0.0.0" in "C:\Users\Phil\.nuget\packages\microsoft.codeanalysis.csharp\1.0.0\lib\net45\Microsoft.CodeAnalysis.CSharp.dll" because AutoUnify is 'true'.
16> Using this version instead of original version "1.0.0.0" in "C:\Users\Phil\.nuget\packages\microsoft.codeanalysis.csharp.workspaces\1.0.0\lib\net45\Microsoft.CodeAnalysis.CSharp.Workspaces.dll" because AutoUnify is 'true'.
16> Using this version instead of original version "1.0.0.0" in "C:\Users\Phil\.nuget\packages\microsoft.codeanalysis.visualbasic\1.0.0\lib\net45\Microsoft.CodeAnalysis.VisualBasic.dll" because AutoUnify is 'true'.
16> Using this version instead of original version "1.0.0.0" in "C:\Users\Phil\.nuget\packages\microsoft.codeanalysis.visualbasic.workspaces\1.0.0\lib\net45\Microsoft.CodeAnalysis.VisualBasic.Workspaces.dll" because AutoUnify is 'true'.
16> Using this version instead of original version "1.0.0.0" in "C:\Users\Phil\.nuget\packages\microsoft.codeanalysis.workspaces.common\1.0.0\lib\net45\Microsoft.CodeAnalysis.Workspaces.Desktop.dll" because AutoUnify is 'true'.
16> Using this version instead of original version "1.0.0.0" in "C:\Users\Phil\.nuget\packages\microsoft.codeanalysis.workspaces.common\1.0.0\lib\net45\Microsoft.CodeAnalysis.Workspaces.dll" because AutoUnify is 'true'.
16> Using this version instead of original version "1.0.0.0" in "C:\Users\Phil\.nuget\packages\microsoft.visualstudio.languageservices\1.0.0\lib\net45\Microsoft.VisualStudio.LanguageServices.dll" because AutoUnify is 'true'.
16> Using this version instead of original version "1.0.0.0" in "C:\MultiLang_Version_7_1\VS2013\MultiLang\bin\Debug\MultiLangCommon.dll" because AutoUnify is 'true'.
16> Using this version instead of original version "1.0.0.0" in "C:\MultiLang_Version_7_1\VS2013\MultiLang\bin\Debug\MultiLangCodeParser.dll" because AutoUnify is 'true'.
16> Could not resolve this reference. Could not locate the assembly "Microsoft.CodeAnalysis, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35". Check to make sure the assembly exists on disk. If this reference is required by your code, you may get compilation errors.
It seems that it is the AutoUnify mechanism, which is causing it to choose version 3.0.0.0 instead of version 1.0.0.0.
From what I have learned about this error, it would be possible to fix it using bindingRedirect in the file app.config, if it was an EXE project.
My understanding is that that does not work for a DLL project, and therefore not for a Visual Studio Extension (VSIX) project.
Is there any way that I can get rid of these warnings in a VSIX project?
(By the way, I have not updated to version 3.0.0.0, because this version only targets .NET Standard, so I assume it is not compatible with Framework 4.7.2.)
Is there any way that I can get rid of these warnings in a VSIX
project?
The easily way to reproduce the three warnings is to create a vsix empty project, then reference the Microsoft.CodeAnalysis version-1.0.0 package in PackageReference format.
Build the project and then you can get same warnings.
So I think the packages you referenced is not compatible with the vsix project with VS2019 related sdk. Please check this document, for VS2019, you're supposed to use 3.0 or higher version.
By the way, I have not updated to version 3.0.0.0, because this
version only targets .NET Standard, so I assume it is not compatible
with Framework 4.7.2.
Please check this document for the details about compatibility between .net standard and .net framework.
See: there are several issues with consuming .NET Standard libraries that were built for those versions from .NET Framework 4.6.1 projects. For .NET Framework projects that need to use such libraries, we recommend that you upgrade the project to target .NET Framework 4.7.2 or higher.
Actually referencing to an assembly that targets .net standard 2.0 in .net framework 4.7.2 projects and higher is the official recommended way. So you don't need to worry about that.
I recommend you update the Microsoft.CodeAnalysis to 3.2.0 version, also you may need to update related packages like Microsoft.CodeAnalysis.Analyzers, then this issue will go away.
Hope it helps:)
I have two projects:
an ASP.NET Core 2.2 project (<Project Sdk="Microsoft.NET.Sdk.Web">), which references the Microsoft.AspNetCore.App metapackage
a supporting "utils" project (<Project Sdk="Microsoft.NET.Sdk">), which references various nuget packages that I need in that project (I can't just reference the metapackage as it's not a web project type)
In the utils project I need to reference MediaTypeNames.Application.Json. I discovered it is in the System.Net.Mime namespace, which is in the System.Net.Mail assembly.
But that is in a beta nuget package, which was surprising. Also, the Microsoft.AspNetCore.App metapackage doesn't reference it, which was also surprising and confusing.
So which nuget package should I reference in my utils project, so I can use MediaTypeNames.Application.Json?
The package you linked to has a description that says "This is an untested port of System.Net.Mail" and if you look at the owner, it's not Microsoft. This is certainly not an official package.
Looking at the docs for MediaTypeNames.Application.Json, it says it's available for netcoreapp2.1 and netcoreapp2.2 and the previews of netcoreapp3.0 and netstandard2.1. It doesn't say anything about a pacakge being available for other TFMs.
i need use System.Web.Http in my project.
I found that Microsoft.AspNet.WebApi.Core package has it, but in NET core project I have error:
Package 'Microsoft.AspNet.WebApi.Core 5.2.4' was restored using '.NETFramework,Version=v4.6.1' instead of the project target framework '.NETCoreApp,Version=v2.0'. This package may not be fully compatible with your project.
Can you help?
I have tried to create basic akka.net sample in asp.net core2.0 using f#.Although sample project does not have any error but showing warnings as below
warning NU1701: Package 'Akka.FSharp 1.2.3' was restored using '.NETFramework,Version=v4.6.1' instead of the project target framework '.NETCoreApp,Version=v2.0'. This package may not be fully compatible with your project.
and same warning for all packages.
can I get the solution to resolve this warning?