We have a large C# EF Code First based code base. Recently one F# project was added. The project uses FSharp.Data.SqlClient (http://fsprojects.github.io/FSharp.Data.SqlClient/) type provider to connect to DB.
That created a huge problem: F# type provider needs DB (and all referenced structures) to exist before the whole project can be complied from scratch, but EF needs to compile the whole project before it can create / update the DB. Subsequently, the DB can no longer be created from scratch or even modified.
While not using type providers is, obviously, possible, it is not an appealing solution because it nullifies the whole purpose of type providers and requires writing code that's already done by them.
Does anyone has any ideas how to deal with that? Thanks a lot!
Expanding on my comment, assuming you have currently only 2 VS projects:
Your C# project that contains everything including the EF code
Your F# project that contains the code that uses the type provider
What you could do is turn in into a 3 project solution:
A new and small C# project that only does EF stuff (migrations, schema definition, classes declaration)
Your F# project that contains the code that uses the type provider
Your existing C# project that would not contain the ef classes and ef related things but that references both #1 and #2.
That way, you EF C# project can compile first then run the migrations. Then your F# project would compile fine. Finally your 3rd project (that contains the rest of the logic that depends on both the EF and F# projects) can compile successfully.
Related
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've created an MVC application. I would like to now add a new class-library project to the solution, and then add an EDMX file to that project.
This used to be easy. But now I have to choose between .NET Core and .NET Standard. But it appears it doesn't matter which I choose because if I create a class library with either of these frameworks, Visual Studio provides no option for adding an EDMX file to them! And I don't see an option to add a standard .NET Frameworks class library.
So what is the secret incantation to add a new project to my MVC solution, and then add an EDMX file to that project?
Note: I do have the option of adding an EDMX file directly to the MVC project. But I would prefer to place it in a separate project, which I've done before.
EDMX file is deprecated with EF Core and I believe it has been removed from .net core projects as well.
If you need to do that, you may need to add it to a normal .net 4.5 project and copy the files but this will make no sense using it with .net core or .net standard.
You should be using Code First anyway as it is cleaner and easier to use.
If you already have the database, you can refer to this link, it can help you to scaffold the classes from the database
https://learn.microsoft.com/en-us/ef/core/get-started/aspnetcore/existing-db
#Jonathan: The EDMX file is old way of doing things. EDMX is nothing but a T4 template which facilitates in creation of edmx.
With .Net Core the best way is to:
1. Create a .net core library project. Add entityframeworkcore nuget package from here
2. The use this link, to generate your model's from DB
The concept of EDMX is not supported anymore.
Hope this helps.
Based on your description you're using the old ASP.NET MVC framework, and not the new Core one, and in this case you're using the Full .NET framework. So, when you create the new Class Library project, you should do it with the Full .NET Framework, because .NET Core and .NET Standard does not support, EDMX. If you chose this one, you can add your ADO.NET Entity Data model to it:
At least for EF v6, if your using EF Migrations, each ('state'/'target') snapshot of the database (stored within the migrations-history db table & migration file) is an EDMX file just waiting to be decoded, saved to a file, and then loaded in VS (Visual Studio). ;)
It's a little in-depth (or at least challenging), but 'System.Data.Entity.Migrations.Edm.ModelCompressor' may present the clue.
Basically, you can extract the EDMX from one/the relevant migration. But I do agree that the Code-First approach should be used for the implementation, the EDMX is only a development-aid these days.
I am using entity framework with DB first approach. I have migrated from EF5 to EF6 successfully. In EF5, I was using pre generated views to improve startup performance. In EF6, it is not working. I have generated views using power tool. Power tool generated it successfully and I can build the application without any error.
But When I run it, getting following error:
The current model no longer matches the model used to pre-generate the mapping views, as indicated by the ViewsForBaseEntitySetsfc4437b421d2fd7f4d645bf31e3cb5b1b8374d9c77a07ef5f36c1cac0bfea31a.MappingHashValue property.
Pre-generated mapping views must be either regenerated using the current model or removed if mapping views generated at runtime should be used instead
I am not able to understand why there is difference between the hash value generated via power tool and generated by EF at run time. There is no change in the edmx file.
There are more than 290 entities in edmx.
Version of entity framework in 6.1.3.
Power tool is VSPowerTools-Beta4.
I am using visual studio 2013.
Code generation startegy of edmx is 'Legacy ObjectContext'.
This issue is exactly as described in the title.
I have a portable F# class library. I have created an ASP.NET Core Web Application (both .NET Framework and .NET Core), from which I have tried to add a reference to my F# class library.
Trying to add the reference gives a message:
The following projects are not supported as references:
Project type is unsupported by current project and can not (sic) be referenced.
This is extremely disappointing, as the .NET Core is now in General Availability.
Are there any workarounds while this bug gets addressed?
I have a project, which I started with Beta8 bits of .net core and since then I have an F# library, which I use from an asp.net core C# app. (btw here is an RC2 based minimal sample for referencing the F# lib from a net core based console app)
Here is how I did it:
Currently (according to my knowledge) there is no template in VS to create a coreCLR based F# library (the PLC templates under F# are all Full framework based, but that you still cannot reference from asp.net core even if it runs on full framework), so you have to do this with the command line. This is done by:
dotnet new --lang F#
This creates you a hello world coreCLR F# app. You can turn the app into a class library by modifying project.json file.
If you have a VS solution and you click to “Add” -> “Existing project” you can select the project.json file. This way you add it to your solution (and btw. an xproj file will be also created).
So at this point you will have the coreCLR based F# project in your solution. I believe by right clicking the asp.net core project and go to “Add” -> “Reference” -> Projects->Solutions and selecting the F# library you can already reference it. If this does not work, you can do it manually: just list the F# project under the “dependencies” in the project.json of the asp.net core application.
If your asp.net core app runs on full framework still need to do these steps. It actually doesn't really matter.
Now the bad part:
In the RTM (released on Monday) the “dotnet new” command creates an uncompliable F# app, because of some dependency issues. This is tracked here (the title says "on macOS", but it's the same on Windows) and as soon as it’s solved this should be fine (or if you did not yet install RTM and you have RC2 you are also good).
Intellisense and debugging across F# and C# does not work (I posted it here)
Although .NET Core has officially been released, the vast majority of the nuget packages in the ASP.NET Core Web Application are in prerelease. Moreover, although the entity framework identity model has been cleaned up, my attempt to change the key columns for users and roles from strings to ints generated an obscure error when I tried to implement Entity Framework migrations. I know I can do it for a .NET Web Application, even though the process is clunky in places. So for now I have gone back to using a .NET Framework Web Application. I'm looking forward to seeing a fully mature version of ASP.NET Core Web Applications. It's not ready, but it looks very promising.
I am working in Visual Studio 2013 RC and am testing Forms Authentication using new Microsoft.AspNet.Identity.* packages.
I would to integrate these concepts (Users, Roles, etc, etc) but want to use my own domain models (POCOs) which are in different assembly. I also don't want to create a dependency on Microsoft.AspNet.Identity.* dlls.
Is that even possible?
I found this article which says it is not, but the article is written based on Preview not RC versions of identity packages.
I have updated my sample project which you can find here: Identity RC1 sample
It now implements an entity framework model, it still require a reference to the Microsoft.AspNet.Identity.EntityFramework as I didn't want to reimplement all the Store classes also. But the sample shows how you can use your own POCO classes for the model.
If you want to completely remove the dependency on Microsoft.AspNet.Identity.EntityFramework from your model assembly you need to implement an class implementing the IIdentityStore interface which has properties of the following interfaces:
IUserLoginStore
IRoleStore
IUserSecretStore
ITokenStore
IUserClaimStore
IUserManagementStore
IUserStore
The IIdentityStore class should be in an assembly separate from your model assembly, with a reference to your model assembly. The IIdentityStore assembly would be dependent on ASP.Net Identity core.
Your custom implementation of IIdentityStore would need to somwhow be able to convert to and from your POCO classes to ASP.Net Identity interfaces such as IUser, IUserSecret etc.
Seems to me to be a lot of work for little gain, if you are using EF for your stores anyway.
Taking a dependency on the AspNet.Identity.Core assembly and have some of your POCO classes implementing one tiny interface each, seems a lot simpler to me.
Yes this is a fully supported scenario, basically you will want to use exclude using the Microsoft.AspNet.Identity.EntityFramework dll which has the default EF implementation, but you should be able to reuse the Manager classes and just implement your own custom Stores using your own POCOs which the manager will use just fine via the interface. For RTM its been streamlined and simplified a bit more, I believe the RC version was not quite as streamlined yet.
Updated You can get early access to the RTM bits here: MyGet
Just in case. Maybe I can help someone.
exorcising entity framework from asp.net.Identity
I'd created separate project(class library), then add ref to asp.identity.core,
then I'd implemented my UserStore class there, and feed it my Identity config in Web project.
It works fine in project with complex n-tier architecture.