I am trying to install nuget package of log4net on a project with dual frameworks (.Net Framework and .Net Core) and it gives me an error of NU 1605 Downgrade Package Detected.
I have seen solutions telling me to clear the field of "Treat warnings as errors" but currently I am looking at a different solution, if possible.
Thank you in advance
Have you seen the official docs for NU1605?
It suggests adding a direct reference to the package in your project. This ensures NuGet's nearest-wins rule always selects the version you have as a direct dependency.
If the package with the downgrade warning is only being restored in .NET Core, you can use MSBuild condition statements to use the package only in one target framework, although there's no way to do this using NuGet's Package Manager UI or Package Manager Console. You'll need to hand edit your project file to use this.
Related
I have made a project in VS2019. I have the same project in .NET Core and .NET Framework. I use a COM reference in my project. I would like to migrate these projects to Pi4.
A simple Hello World project (.NET Core) is running successfully on the Pi4 machine. However, when I try to run my project (.NET core or .NET Framework) it does not run on the Pi4. It says COM is not supported.
I tried to build the project using MSBuild in my Windows environment after looking for solutions in Google. I also see a similar error here. The error is: error : MSB4803: The task "ResolveComReference" is not supported on the .NET Core version of MSBuild. Please use the .NET Framework version of MSBuild.
The .NET Framework project also gives a similar error.
error MSB4028: The "ResolveComReference" task's outputs could not be retrieved from the "ResolvedFiles" parameter. Object does not match target type.
Does anyone have similar issues?
https://github.com/microsoft/msbuild/issues/3986
According to the above link. The employee of Microsoft is saying they can not give solution in the near future.
Set the Projects to x86 for them to build the Interop, the Interop created still could not be used in x64 runtimes.
Add the COM Reference to the Core project, Build it and you will get an Interop.YourCom in the bin/x86/core/debug folder.
Remove the COM reference, and re-add the Interop, it will be put into the Assemblies Dependencies, and MSBuild will work.
My MSB4803 was from a WIXInstaller project, for ADOX, and Microsoft.Office.Interop.Access.Dao
I stumbled upon this question many times and I experienced the same several times in different projects. It doesn't matter if it is Visual Studio 2019 or 2022 and the version of the build, unless you are working with the old MSBuild in a legacy environment, the COM Reference doesn't work. It is always safe to build it in the command line to understand if anything in the VS environment works. I don't truly understand why Microsoft let you make those references in the Visual Studio environment when they will not work nearly anywhere else.
There are some workarounds that might or might not work but if your code is already pointing at a COM library there is no much to do. You can install the NuGet package which is going to pass the build stage and remove the COM reference.
Install-Package Microsoft.Office.Interop.Excel -Version 15.0.4795.1001
The NuGet package has some differences at the types level that you will need to fix (the COM reference allows you to get specific types instead of objects from the cells values)
In any case, you will need the COM installed in the server, there is no workaround that issue.
I wouldn't say I like this error message or the link it shows on how to fix it, to be polite.... ;-);
I figured it out and thought as there are a lot of answers that are not helpful to share mine. What I did is update your command to force the use of msbuild.
dotnet msbuild -v:normal "FullOrRelativePathTo\MyProject.csproj" -p:Configuration=RELEASE
If that fails, try:
"C:\Program Files\Microsoft Visual Studio\2022\Enterprise\MSBuild\Current\Bin\msbuild.exe" "PathTo\Project.csproj" /p:Configuration=RELEASE
I know I'm late to the party, but here is a workaround working for me when I want to use Office Interop in .NET (Core):
Create an empty .net Console app (I'm using Rider and .NET 7)
Build it with the default MSBuild (17.0 in my case at the time of writing)
Add Interop references to the project file (I don't use Nuget, only generate these in a dummy .NET Framework project while adding COM references to Office libraries), eg.
<ItemGroup>
<COMReference Include="Excel">
<Guid>{00020813-0000-0000-C000-000000000046}</Guid>
<VersionMajor>1</VersionMajor>
<VersionMinor>9</VersionMinor>
<Lcid>0</Lcid>
<WrapperTool>tlbimp</WrapperTool>
<Isolated>False</Isolated>
<EmbedInteropTypes>True</EmbedInteropTypes>
</COMReference>
</ItemGroup>
Change the solution MSBuild version to 4.0
Try to build the solution, but the project will not even load properly due to an outdated MSBuild version
Revert the MSBuild version to the default one
Build the project - success! (this is the magic part, I can't explain it :P)
i was able to get the sample asp.net embedded powerbi to work with my reports
now i have to migrate it aspnetcore
i was hopeful when i saw this post - seeing that someone was able to get it done
Embed Power BI Report In ASP.Net Core Website
so i:
started a new project with the aspnetcore
installed the powerbi package
now when compiling im getting this warning:
Package 'Microsoft.PowerBI.Api 2.0.11' 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.
i searched and couldnt find a powerbi package that was specific to aspnetcore
is there one? will there be a conflict crossing cores? or does it not matter?
UPDATE:
4.6.1 powerbi package does indeed work with aspnetcore 2
but looking forward to a powerbi package specifically coded for core
As you can see this is just a warning, not an error. That warning appears because .NET Core 2.0 applications can use some Nuget packages which target .NET Framework 4.6.1 (or less). However, this inclusion might fail if the referenced .NET 4.x package contains some API not included into .NET Core/.NET Standard 2.0
So, my advice - try to run your application. If it works well at the first glance - then, most probably that PowerBI package does not contain any not supported APIs and will work well further. If it fails right at start - then you will need to wait for the release of the new version of that package which targets .NET Standard 2.0.
I understand that .Net Core 2 has a compatibility shim that allows it use Nuget packages that don't specifically target .Net Core/Standard 2. This gives it access to 70% of Nuget. Great - nice feature.
How do I prevent installing nuget packages that aren't fully compatible with .Net Core 2/.Net Standard 2? Or warn me at point of installing that it is being used with the shim?
I created a new .Net Core 2.0 project installed EF 6.1.3 (which I knew didn't work) and nothing prevented me or warned that it didn't target .Net Standard <=2 at the point of install.
I am happy to "run with scissors" but I kind of feel I should be getting a warning before I install MVC5 and EF 6.1.3 into a .Net Core 2 application. I would really like to prevent junior devs from installing unsupported packages etc.
I guess further to Matt Ward answer - my main point is - can it be detected that something is actually 100% compatible at install or are we always just in the situation where we need to make determination ourselves that package works "well enough". I hoped that there was a technical mechanism that detected missing coverage API coverage and could tell us that the nuget package may not operate as it did before. So I guess MS say 70% compatibility - I want to fail if I try to install the 30%
Installing Entity Framework 6.1.3 into a .NET Core 2.0 project there is a NU1701 warning in the Errors window about Entity Framework 6.1.3 being restored using .NET Framework 4.6.1 and that it may not be fully compatible.
You could turn the NU1701 warning into an error in the project so you could not install any NuGet package that does not explicitly support .NET Core 2.0. This can be done by adding the WarningAsErrors property to the project.
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>netcoreapp2.0</TargetFramework>
<WarningsAsErrors>NU1701</WarningsAsErrors>
</PropertyGroup>
Then if you try to install Entity Framework 6.1.3 the restore will fail, the changes will be rolled back, and the NuGet package will not be installed.
You can also set the DisableImplicitAssetTargetFallback property to true which will prevent .NET 4.6.1 being added to the AssetTargetFallback property which is used when checking NuGet package compatibility with .NET Core 2.0 projects.
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>netcoreapp2.0</TargetFramework>
<DisableImplicitAssetTargetFallback>true</DisableImplicitAssetTargetFallback>
</PropertyGroup>
If you wan to be 100% sure, run the package against .NET Portability Analyzer and .NET Standard 2.0 profile.
It won't tell you if the API will be called or not (and is in no way an automatic process), just if the Assembly contains any API which is not .NET Standard 2.0 compatible.
However, you can also only run your application against the Analyzer, as the .NET Portability Analyzer should be able to follow any references made from the application and check these too.
Update
You can als build this into your build server pipeline, to get a more automatic guarantees.
The .NET Portability Analyzer Docs.
Visual Studio is not required for this, just download it from https://github.com/Microsoft/dotnet-apiport/releases and run
From the docs:
Type the following command to analyze the current directory: \...\ApiPort.exe analyze -f .
To analyze a specific list of .dll files, type the following command: \...\ApiPort.exe analyze -f first.dll -f second.dll -f third.dll
Old Answer (may be useful in conjcution with Matt's answer)
Untested, but give it a try:
<!-- old dotnet tooling/.NET Core 1.x -->
<PackageTargetFallback>netstandard2.0;portable-net45+win8</PackageTargetFallback>
<!-- new dotnet tooling/.NET Core 2.0 -->
<AssetTargetFallback>netstandard2.0;portable-net45+win8</AssetTargetFallback>
Typically you want to have it like
<!-- old dotnet tooling/.NET Core 1.x -->
<PackageTargetFallback>$(PackageTargetFallback);dotnet5.6;portable-net45+win8</PackageTargetFallback>
<!-- new dotnet tooling/.NET Core 2.0 -->
<AssetTargetFallback>$(AssetTargetFallback);dotnet5.6;portable-net45+win8</AssetTargetFallback>
Where $(PackageTargetFallback) will tell MSBuild to keep the old values and append the values after that to it. But since $(PackageTargetFallback) probably (can't look/dig deeper in right now) have the .NET Framework moniker there, you'll override it with your own values.
Additionally
Given that PackageTargetFallback is now deprecated, one should use AssetTargetFallback instead.
As far as I know .Net portability analyzer tool can not 100% determine the platform that does not support installation, such as system.runtime.Loader, after tool analysis, 100% supports the framework platform, but it does not
Screenshot of analysis results:analyse System.Runtime.Loader
I started programming with .NET Core and ASP.NET Core and after reading many Docs/Tutorials i still am not sure of how to realize if a Nuget-(Meta-)Package is comptabile/usable within my .NET-Core-App.
How to check if a NuGet-Package is compatible with .NET Core.
E.g. the often recited Newtonsoft JSON. Is it compatible/usable - and how to see this?
Is there a list of all the available .NET Core packages?
(Like here it lists a few
key NuGet packages for .NET Core
). But since they say those are "key" packages i would assume there are more. But which?
The best way to understand compatibility is table here
In this table you can check what API version support NuGet package. If it is standard 1.0+ - it works with .Net Core
For checking (supported API version) dependencies on your package, you can check page of package on nuget.org or in your package manager
Here is an example for Rider
maybe that will be helpful - lots of popular packages https://github.com/thangchung/awesome-dotnet-core
I also don't see nuget.org mentioned anywhere so:
https://nuget.org
General rule of thumb for me is:
if package has a dependency on net standard or .net core, it will run with .net core(mind the versions also)
https://packagesearch.azurewebsites.net
Go to site and search for package to find its compatibility
Well, in fact you don't have to worry, the NET core application will indicate you if the package is compatible or not when you will run a dotnet restore command in your project.
Let say that you have the famous CSVHelper package registered in your csproj file :
<PackageReference Include="CsvHelper" Version="0.12.0"/>
Then, when you'll run any dotnet command such as build or run, you'll have the following input in the console in case of, here, cross-compatibility:
YourProjet/aspnetapp.csproj : warning NU1701: Package 'CsvHelper 0.12.0' 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 '.NETCoreApp,Version=v2.2'. This package may not be fully compatible with your project.
Basically, it mean that NET Core application can use ASP.NET NuGet package, and so far, I've never cross on a non-compatible package. Even if version is incorrect, the build will get the most recent matching version of the NuGet package.
Hoped it answer your question.
I was setting up number of projects to build NuGet packages and push onto NuGet server, so it could be later used by Octopus Deploy.
All was fine until I needed to apply the same process to legacy projects. The error was:
error MSB4062: The "OctoPack.Tasks.CreateOctoPackPackage" task could not be loaded from the assembly ...\OctoPack.Tasks.dll. Could not load file or assembly 'file:///...\OctoPack.Tasks.dll' or one of its dependencies. This assembly is built by a runtime newer than the currently loaded runtime and cannot be loaded. Confirm that the declaration is correct, and that the assembly and all its dependencies are available.
Now I understand that OctoPack was not built for .Net 2.0, but just wonder if anyone hit/solved that problem.
Are you able to change the build target of the application from 2.0 to something more recent? If so, I would upgrade my app, rather than look for a downgraded version of Octopack.
Alternatively, you can use NuGet.exe to create packages rather than using OctoPack. I actually prefer OctoPack, but NuGet.exe wouldn't care about your .NET version.
I ended up amending the Octopack code to work with .Net 2.0 and MSBuild 2, which is successfully applied to all our .Net 2.0 and 3.5 applications being packaged on the CruiseControl server.
If someone is in a similar situation here is the amended code (forked from the original Octopack)