I'm trying to add .NET 4.6.1 class library project which using Entity-Framework 6 as DAL layer into a solution which is running under .Net Core 2.2 startup project (Web-Api).
The EF project was using a different "old" (.NET Framework 4.6.1 class library) web-api project as end points, but now I want to gather all the end-points under one project.
The problem is that the running context is .NET Core 2.2 which use appsettings.json as configuration file, so I copied the ConnectionsStrings details from the "old" XML configuration into the appsettings.json file, but it seems like the EF can't read connection strings (which used to be in a web.config XML file when used the "old" .net 4.2 web-api project) from the appsettings.json file.
I'd rather continue working with the current EF and not change it to EF .Core
The error I'm getting is:
"No connection string named '' could be found in the application config file"
How can I solve it ?
Is there a reason for .Net core not "naturally" working with EF 6 when on .NET 4.6 ?
This is my appsettings.json file (Ignore types - it is not copy-paste but free hand copying):
"ConnectionStrings":
{
"MyMainDBEntities": {
"ConnectionString": "metadata=res:...",
"providerName": "system.Data.EntityClient"
}
}
it seems like there is no real option other that using the EF Core - this is how I fixed the problem
Related
i have class library project in .net framework 4.6.1. i have to migrate that project into .net 5.
while doing so I am facing error for netNamedPipeBinding.
Severity Code Description Project File Line Suppression State
Error CS0246 The type or namespace name 'NetNamedPipeBinding' could not be found (are you missing a using directive or an assembly reference?)
following nuget package already installed.
System.ServiceModel.Duplex
System.ServiceModel.Http
System.ServiceModel.NetTcp
System.ServiceModel.Primitives
Any way to to make it work?
Looks like it is not supported.
Named pipes
WCF provided a named pipes binding for communication between processes on the same physical machine. The first release of
ASP.NET Core gRPC does not support named pipes. Adding client and
server support for named pipes (and Unix domain sockets) is a goal for
a future release.
https://learn.microsoft.com/en-us/dotnet/architecture/grpc-for-wcf-developers/wcf-bindings#named-pipes
Also, the documentation page for NamedPipeBinding is resolved to .NET 4.8 section and does not exist for .NET 5
https://learn.microsoft.com/en-us/dotnet/api/system.servicemodel.netnamedpipebinding
HttpBinding documentation page is there for .NET 5
https://learn.microsoft.com/en-us/dotnet/api/system.servicemodel.nethttpbinding
I'm in the process of converting the existing .Net framework project that uses EF 6 with Database First approach (EDMX) file to .Net Standard 2.1 which connects to SQLDB hosted on Azure.
Existing EDMX file has a constructor (auto generated) that accepts ConnectionString as given below -
public TestDatabaseConnection()
: base(ConfigurationManager.ConnectionStrings["TestDatabaseConnection"].ConnectionString)
{
}
This is breaking for two reasons -
ConfigurationManager.ConnectionStrings works only in .Net framework projects and throw runtime errors in the .Net Core project (for eg- ConfigurationManager.ConnectionStrings returns null).
I need to make changes to the above code to use the AppAuthentication nuget as mentioned in the MSDN docs here
So, what are the options available in order to make this work so that I could use the same nuget package for connecting to the database via EF 6 (database first) for both .net framework and .net core projects?
Is the only available is to convert to Code first and make the necessary changes as mentioned in the above MSDN link?
I'm working on porting an ASP.NET MVC application to an ASP.NET Core MVC hosted in .NET Core.
I was excited to see that EF 6.3 can host on .NET Core, since it looks like the EF -> EF Core migration is something that I'd at like to defer (possibly indefinitely).
Looking at Microsoft.AspNet.Identity.* nuget packages, it appears that they don't have dependencies on a particular .NET framework (full or Core) just on Entity Framework 6.1 or greater.
Other than the purist idea that I should just move everything over to core while I'm in the code, is there any reason I can't have an ASP.NET Core MVC application that uses EF 6.3 and Microsoft.AspNet.Identity rather than EF Core and Microsoft.AspNetCore.Identity?
After some experimentation:
It looks like I was wrong and Microsoft.AspNet.Identity.Owin has a dependency on the full .NET framework. So I will revise the question:
Can I use Microsoft.AspNetCore.Identity with Entity Framework 6.3? My key goal here is to avoid biting off the EF -> EF Core migration while getting the rest of my codebase moved to .NET Core.
I am trying to use EF6.0 in Class Library Project .Net Framework 4.6.2 (Repository project) where the DBContext live next to the repository and the Entities have been created in different project(.NET framework 4.6.2) using Reverse Code First POCO,
The Repository will be called thru another (framework 4.6.2) Manager Project referenced inside ASPNET Core 2.0 SPA Project, where StructureMap used as IoC.
The first thing I faced was the issue of passing the connectionstring to the DBContext inside Repository Project, as I want to Register the services (DBContext,Repository) inside the Repository Project not from the ASPNET Core Startup.cs, the reason to that is to avoid exposing the DBContext to the frontend project, anyway I ended up hard-coding the connection string in Repo Project temporarily, "appreciate if there is another way!"
The main issue that I am facing with this design comes when the request send to collect the list of "Products", it reaches to the Repository Project where the Linq statement use _dbcontext.Product , then error message thrown
NotSupportedException: Unable to determine the provider name for provider factory of type 'System.Data.SqlClient.SqlClientFactory'. Make sure that the ADO.NET provider is installed or registered in the application config.
The Entityframework is registered inside Repository project, but not inside ASPNET Core 2.0 Project as it will show Nuget conflict error when its installed in ASPNET Core 2.0.
also I tried to install "System.Data.SqlClient" from Nuget in ASPNET Core2.0 but the error still throwing.
Any Idea on how to use EF6.0 in .netframework 4.6.2 class library project referenced inside ASPNET Core 2.0 project.
The Microsoft article Get Started with ASP.NET Core and Entity Framework 6 has the steps necessary for using Entity Framework 6 from a ASP.NET Core project.
Regarding the NotSupportedException, I would refer to the related question System.NotSupportedException: Unable to determine the provider name for provider factory of type 'System.Data.SqlClient.SqlClientFactory'.
I ran into the same issue because I failed to change the Core .csproj file from <TargetFramework>netcoreapp2.2</TargetFramework> to <TargetFramework>net471</TargetFramework> (which the article told me to do, but for some reason I thought wasn't necessary in Core 2.2).
I provided more explanation and details in the posted explanation/answer to the question I referenced above.
The type 'System.ComponentModel.DataAnnotations.MaxLengthAttribute'
exists in both
[path...]\packages\EntityFramework.4.3.1\lib\net40\EntityFramework.dll
and
'c:\Program Files (x86)\Reference Assemblies\Microsoft\Framework
\.NETFramework\v4.5\System.ComponentModel.DataAnnotations.dll'
Now, I have read on msdn that its safe to exclude the EntityFramework reference (which was added through the nuget package). However, when I do that, I cant create a DBContext properly as the DbModelBuilder class lives in the EntityFramework dll. Also, some other critical classes are missing when I remove the EntityFramework refference so this is old and irrelevant solution now.
Update (disambiguation): Both System.ComponentModel.DataAnnotations.dll and EntityFramework.dll include System.ComponentModel.DataAnnotations.MaxLengthAttribute. The problem is that each dll also includes other classes that are critical to EF code-first design. For example:
EntityFramework.dll:
- System.Data.Entity.DbModelBuilder
System.ComponentModel.DataAnnotations.dll:
- System.ComponentModel.DataAnnotations.RegularExpressionAttribute
Add this statement to top of your class
using System.ComponentModel.DataAnnotations;
System.ComponentModel.DataAnnotations namespace is distibuted across the EntityFramework.dll and System.ComponontModel.DataAnnotations.dll. So you need to add a reference to both of that in your project to make use of DataAnnotations.
The MaxLenth attribute is present in EntityFramework.dll. So make sure you have that reference to that dll present in your project references section.
EDIT : As of .NET framework 4.5, this namespace is moved to the System.ComponentModel.DataAnnotations.dll. So If you use .NET Framework 4.5 with Entity Framework 4.3.1 or less, You will run in to this conflict. The solution is to switch to Entity framework 1.50 beta 1/ 2 release if you want to stick with .NET 4.5 or downgrade to .NET 4 to use EntityFramework 4.3.1.
From the msdn documentations.
Starting with Entity Framework 5.0 Beta 1, the EntityFramework.dll
does not contain definitions for data annotations. These definitions
were moved to System.ComponentModel.DataAnnotations.dll and are
defined in the System.ComponentModel.DataAnnotations.Schema namespace.
I didn't have the option of upgrading the project to use EF5, or downgrading the build machine to .Net Framework 4.
There is a way to solve this though! It turns out when you install Visual Studio 2012 it adds the following folder (amongst others).
C:\Program Files\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0
In VS if you open a project targetting 4.0 and look at the properties of your reference to System.ComponentModel.DataAnnotations you'll see that the path is pointing to the above location, rather than the GAC.
This folder contains the original Framework 4.0 assemblies. If they're present on the machine then MSBuild etc., upon building a project targeting 4.0 will reference these rather than the modified ones that 4.5 puts into the GAC.
In our case this meant we could fix the problem by copying that folder from a dev machine with VS installed up to our build server in the same location. (N.b. We only needed to copy this folder, there was no need to install VS on the build server).
More info here: http://marcgravell.blogspot.co.uk/2012/09/iterator-blocks-missing-methods-and-net.html
Hope this helps someone else!