We're in the process of converting old .NET 4.7.2 code to .NET 7. In the migration we're creating some .NET Standard 2.0.3 projects and moving the data layer code into one so it can be used by both .NET versions. But to do this we need to use an older version of .NET Standard (2.0.3) and Entity Framework Core v3.1.31.
For all of the other developers on our team this works fine. However for myself, when I run the code I get an exception thrown from the data layer .NET Standard project that it couldn't load Microsoft.Bcl.HashCode 1.0.0.0. The weird thing is that the Entity Framework Core version we're using is referencing Microsoft.Bcl.HashCode 1.1.1
I can't find any reference to the 1.0.0.0 version of Microsoft.Bcl.HashCode. Any idea what might be going on?
Related
I have a situation where an application uses various component libraries. The libraries were based on .NetStandard2.0/2.1 and internally used EF Core 3.1. For various deployment and development reasons, we now want to target EF Core 6.0, which raises the following issues.
Net Core 3.1 support runs out in December 2022 so we need to move away from it.
The application uses Net Framework functionality and cannot move to Net Core.
EF Core 6.0 does not support NetStandard, only Net 6.
Changing the library that uses EF Core to target NET 6 means that components referencing it also need to reference Net 6.
Dependencies trickle down to the application that targets Net Framework and, as a result, the application no longer builds because Net Framework is not compatible Net 6.
How can the Net Framework application use the Net 6 assembly? Or, more specifically, how can a Net Framework application use libraries that internally use EF Core 6.0?
The interface between the application (Net Framework) and the one single touch point library component (Netstandard) is very well defined. Maybe Pinvoke could solve the problem? Or something simpler that I have overlooked?
Somewhat related question: NU1202 Package Microsoft.EntityFrameworkCore 6.0.3 is not compatible with netstandard2.1
Other than process to process communication between .NET Framework and .NET 6, this is not supported (for example via a Web API or similar)
As a short term solution, you can change your .Net Standard 2.0 EF Core libraries to be multi targeted to both .Net Standard 2.0 (which will reference EF Core 3.1) and .Net 6 (which will reference EF Core 6). This will let your .Net Core apps use EF Core 6, while allowing your .Net Framework apps to use the same dlls, but to be using EF Core 3.1. I realize that EF Core 3.1 support ends December 2022, but it will keep things moving.
https://learn.microsoft.com/en-us/nuget/create-packages/multiple-target-frameworks-project-file
Btw, has Microsoft even attempted to address the fact that a .Net Framework application cannot reference .Net 6, therefore it cannot use EF Core 6? This is a major issue for us, as we were sold the idea that .Net Standard could be shared between .Net Framework and .Net Core, but this has ceased to be the case since .Net Standard 2.1 was introduced, and now MS has pushed all new features, like EF Core, to .Net 6.
I have a multi-project solution that contains a data layer on .Net Standard 2.1 and a WebAPI on .Net Core 3.1. Currently, I have no plans to upgrade to .Net 5.x (Note: Core is removed in 5.x naming convention) because it is not LTS - that will be .Net 6.x. So, I will upgrade to 6.x when it comes out.
In one of my data layer solutions, the NuGet Package Manager is recommending that I upgrade Microsoft.AspNetCore.Identity.EntityFrameWorkCore from v3.1.8 to v5.0.2. It seems like the major version is moving in lockstep with the .Net major version (Note: 4.x is skipped in order to avoid confusion with the venerable .Net Framework 4.x). Should I follow the advice and upgrade?
Specifically, will this cause any problems with the .Net Core 3.1 WebAPI project? Generally, can I do this for other Microsoft.* packages that recommend upgrading to a 5.x version?
I bit the bullet and upgraded all of them. Everything works flawlessly and I am glad that I did it. There were a few breaking changes that needed to be dealt with. I recommend checking Microsoft's breaking change log here:
https://learn.microsoft.com/en-us/aspnet/core/migration/31-to-50?view=aspnetcore-5.0&tabs=visual-studio
I've verified that Entity Framework 6 Tools is installed as suggested in other answers on this site, but ADO.NET Entity Data Model never shows up in the New Items/Data list. I've also tried installing the .NET CORE 2.0 SDK as other answers have suggested to no avail.
To be clear, I'm not creating a .NET CORE application, I'm just trying to make a class library based on .NET framework 4.6. I created the project via .NET Standard and selected Class Library (.NET Standard).
I just need to install EF so I can do a code first generation from my existing SQL Server DB.
Don't use .NET Standard, select a .NET Framework project type.
.NET Standard is an abstract "Core or Framework" option, as if the naming wasn't confusing enough.
Is it possible to set the .NET Framework version for a ScriptComponentProject?
Currently it defaults to .NET 4, but I want it to be .NET 4.6.1
I've looked on the documentation page for ScriptComponentProject (https://www.varigence.com/Documentation/Samples/Biml/Script+Component+Project), but without any luck.
Ah, I found the answer! You need to set the Target Framework Version in your script project:
https://www.varigence.com/Documentation/Language/Element/AstComponentScriptProjectNode
And I think the available values are these:
Unspecified
Unspecified .NET Framework Version
NetFX20
.NET Framework 2.0
NetFX30
.NET Framework 3.0
NetFX35
.NET Framework 3.5
NetFX40
.NET Framework 4.0
NetFX45
.NET Framework 4.5
NetFX451
.NET Framework 4.5.1
NetFX452
.NET Framework 4.5.2
NetFX46
.NET Framework 4.6
NetFX461
.NET Framework 4.6.1
Which can be found here: https://www.varigence.com/Documentation/Api/Enum/ScriptProjectTargetFrameworkVersion
If you are using BIMLExpress 5.0.6xxx, you have probably faced the same issue.
I opened the generated .dtsx package and found that the TargetFrameworkVersion node placed inside of a separate PropertyGroup node. After I had moved it out to the first PropertyGroup of the same arrayElement node, then reopened my package in Visual Studio again, issue was gone! So you can write a script to move TargetFrameworkVersion node into the proper place for now.
Varigence support team told me that a public preview release is coming late next week which will include a fix for that (+also VS2017 support!).
We have old .net 1.1 project that is using a third party component. Aparently that component is not working properly with new requirements, and there is no support from the provider. Provider proposed to use new component that is working properly. The problem is that this component requires .net 2.0.
The project is big and it will be costly to move this project to 2.0.
What other alternatives we can have? How 1.1 assembly can call 2.0 assembly?
.NET 1.1 can't load .NET 2.0 assemblies, because the internal format changed. Your app will basically think that the assembly isn't a .NET assembly.
Long term, it would be a good idea to update your application to use .NET 2.0 (if not something newer, since there are multiple versions of .NET since 2.0 now). However, if that is not an option, you could create a .config file for your executable, and tell the CLR to always use .NET 2.0 when running your app. This should allow for the .NET 2.0 assembly to load, however any breaking changes between .NET 1.1 and 2.0 that your app makes use of will cause errors.