I have three projects built with:
.NET Standard 2.0 (Library 1)
.NET Core 3.1 (Library 2)
.NET Framework 4.6.1 (Library 3)
The Library 1 & 2 refer Library 1. Because .NET Standard 2.0 would not be supported soon, I tried to upgrade Library 1 to .NET 5.0. The upgrade worked fine. The Library 2 is able to refer Library 1 also.
But the Library 3 can't be built. This the error that I see:
Error CS1705 Assembly 'AAAAA.AAAA.AAAA' with identity 'AAAAA.AAAA.AAAA, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' uses 'System.Runtime, Version=5.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' which has a higher version than referenced assembly 'System.Runtime' with identity 'System.Runtime, Version=4.1.2.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'
I tried to migrate the library 3 to net5.0, but the project is not allowing me to build because it can't recognize the version. I also tried to migrate to .NET Framework 4.8, but also gave the error about the System.Runtime.
Is there a solution for the Library 3 to refer Library 1?
Related
I have an ASP.net core web app which references a DLL called BLL, which in turn references a DLL called DAL, and within the DAL there is a reference to Microsoft.EntityFrameworkCore 7.0.2.
I have changed the .net versions of these 3 projects from 6 to 7 today, it all compiles and runs fine locally in Visual Studio.
However when I come to deploy it the BLL won't compile, I get an error:
Error CS1705 Assembly 'ST.CMS.DAL' with identity 'ST.CMS.DAL, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' uses 'Microsoft.EntityFrameworkCore, Version=7.0.2.0, Culture=neutral, PublicKeyToken=adb9793829ddae60' which has a higher version than referenced assembly 'Microsoft.EntityFrameworkCore' with identity 'Microsoft.EntityFrameworkCore, Version=6.0.2.0, Culture=neutral, PublicKeyToken=adb9793829ddae60' ST.CMS.BLL C:\Users******\ST.CMS\ST.CMS.BLL\CSC 1 Active
So there is a conflict between 6.0.2 and 7.0.2 for EntityFrameworkCore, however i'm not using 6.0.2 anywhere, I can't understand where it's getting 6.0.2 from.
Before I did this change today it deployed fine. I have tried closing and reopening Visual Studio and rebooting the laptop but it still keeps happening.
Simply removing the Nuget package references to Entity framework core in the DAL project then re-adding them solved the problem.
I have a VB.NET Windows Forms project targeting the .NET Framework 4.7.2:
I am trying to install Microsoft.EntityFrameworkCore.SqlServer of which the latest stable version is 5.0.8:
However after clicking install and accepting all terms I get an error:
Could not install package 'Microsoft.EntityFrameworkCore.SqlServer 5.0.8'. You are trying to install this package into a project that targets '.NETFramework,Version=v4.7.2', but the package does not contain any assembly references or content files that are compatible with that framework. For more information, contact the package author.
Does anyone know what the heck its moaning about version for?
Does anyone know what the heck its moaning about version for?
EF Core 5 requires .NET Standard 2.1. .NET Framework only supports .NET Standard 2.0. So it will never work.
EF Core 3.1 is the last version to support .NET Standard 2.0, and so it's the last version of EF Core compatible with .NET Framework.
But .NET Core 5 supports Windows Forms.
So the options are:
upgrade everything to .NET Core 5
downgrade EF Core to version 3.1
switch from EF Core to EF 6, which is mature, stable and supports .NET Framework
so basicly out complete company dataaccess is based in .Net Framework 4.6.
We are only on windows, so no problems here atm.
We have a new project in which I want to use .Net Core 2.0 and WebAPI but I have to use this "old" .net Framework lib.
When I add the reference and start my project I will get an error:
Could not load type 'System.Security.Principal.WindowsImpersonationContext' from assembly 'mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'.'
As far as I googled it and understand, the dataasccess lib will try to get the win auth but this isnt available in .net core (obvious) any more.
I found the nuget Microsoft.Windows.Compatilibity and after installing the error is gone.
But another one comes up:
Exactly this error:https://community.oracle.com/thread/4139377
And the only solution to this seems to be to remove the MS.Win.Comp package...
So a bit of a circle.
Any ideas?
I have a .NET Core project which I am getting back to which was working fine. I ran a NuGet update which upgraded a number of items, mainly going from AspNetCore 1.0.0 to 1.1.0. The solution compiles fine, but when I run it, I get this exception in the browser:
FileLoadException: Could not load file or assembly 'Microsoft.AspNetCore.Http.Features,
Version=1.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60'
or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
Adding Microsoft.AspNetCore.Http.Features in project.json does not fix the problem and I can find no reference to it. Does any one have a suggestion on resolving this?
I encountered the same problem after updating from 1.0.0 to 1.1.0 (ASP.NET Core Web Application (.NET Framework 4.6.2) x86) using Visual Studio Community 2017 RC.
My solution were to uninstall the Codegeneration design package:
Microsoft.VisualStudio.Web.Codegeneration.Design (1.0.0-msbuild1-final)
Update!
The faulty package has since been updated (1.0.0-msbuild2-final as of this writing). So instead of removing the package, tick "include prerelease" and update.
According to this site Announcing the Fastest ASP.NET Yet, ASP.NET Core 1.1 RTM the .NET Core 1.1 SDK needs to be installed. I assumed that I had already done that through a Visual Studio notification, but that wasn't the case. Once I installed it, the site worked.
I just starting to use Visual Studio 2010 and .NET 4.0. I created a new WPF project a DLL built for .NET 2.0. When I build the project, I get a bunch of warnings like this one:
The referenced assembly
"MicroFour StrataFrame Business...processorArchitecture=MSIL"
could not be resolved because it has a dependency on
"System.Web, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"
which is not in the currently targeted framework ".NETFramework,Version=v4.0,Profile=Client".
Please remove references to assemblies not in the targeted framework
or consider retargeting your project.
When I reference a project I created that targets 3.5, it can't find any of the namespaces (during compile), though they show up in the object browser and intellisense correctly shows them.
Is there something I'm missing that needs to be done to reference an older .NET assembly?
There is very little point in targeting the client profile for .NET 4.0. The download is 41MB, the full version is 48MB, only 15% bigger. Unfortunately it is the default in VS2010, just change it with Project + Properties, Application tab, Target framework combo.
The client profile does make a lot of sense if you target 3.5, the full install is ~350 MB. The huge difference is explained by the prerequisites, .NET 4.0 requires at least XP SP3 or Vista SP1. But 3.5 installs on any version of Windows > 2000. The 3.5 installer thus contains lots of the required updates for unmanaged Windows components used by .NET. The web installer lessens that blow considerably btw.
Your 2.0 assembly has a reference to System.Web. The reference is being automatically forwarded to your target framework, 4.0. So it is attempting to use System.Web, version 4.0.0.0. The problem is with 4.0 (actually this started with 3.5), there is now the notion of a client profile. The client profile has a smaller set of reference assemblies, anything web/server related has been removed. This is to make the .NET framework a smaller/simpler download for end users.
With VS 2010 and .NET 4, the client profile is being pushed a lot harder, MS really wants us to use it. So your .NET 4 project is targeting the client profile by default. Your referenced assembly wants System.Web, so in that case you need to switch to the full profile.