I've taken over a project in VS 2010 that uses .NET 4.0. It uses Entity Framework version 4.0. I'm wondering if I should upgrade to Entity Framework 6.0?
While mapping a new table, I noticed the previous developer set his columns on a table as Integer and mapped it to the designer class. However, upon closer look at the entity designer class (.cs) the result is INT32.
However when I created a table with similar specs my Integer column was mapped as decimal in the designer class.
So in a nutshell - it is mapping Oracle Integer to .NET decimal.
I can only guess that the previous developer used brute force to change the properties of each column in the visual EDMX file and set it to INT32.
I would have to select each column of my table in the visual design (EDMX) and ensure it is INT32 in the properties.
A bit tedious but has this been cleared up in EF 5.0 or EF 6.0 as a more straightforward mapping? INTEGER to INT32?
Has EF 5.0 or EF 6.0 cleared up the mapping?
I'm using Oracle 11G.
After further research you can use Oracle NUMBER(10) which tranlates to INT32 on the .NET end.
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?
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.
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'.
I am using EF 4.x POCO Entity Generator for C# for generating classes from database. I have put some data annotation on some classes and its working fine.
But when i made any change in the database and update the entity model, it removes all the changes in the poco classes (data annotations) because "EF 4.x POCO Entity Generator for C#" is persistence ignorant.
But i want to keep my changes. What should i do?
Very common problem. What you want is Buddy Classes.
http://hartzer.wordpress.com/2010/01/26/mvc-buddy-class/
Since POCO's are partial classes, you can create "buddy classes" (that persist outside of the EDMX ad regenerated code) for each POCO with Meta Data Annotations.
Your solution is to generate your code from the database using the entity framework power tools.
Additional db changes should be done to your code first and the use the database migrations feature of entity framework to generate your SQL script to apply to the database using the update-database command in the 'Package Manager Console' of Visual Studio
I go over a similar procedure here at the end on my DEV215 Entity Framewok for Real Web Applications Channel 9 video
http://channel9.msdn.com/Events/TechEd/NorthAmerica/2012/DEV215
We have built a product around EF4 with POCO and the initial requirements were to work against SQLServer 2005. However, we have a few clients who have SQLServer2008 installed. Hence, at runtime, we need to verify the version of the DB and make changes to the manifest token in the edmx accordingly. Or, can it be done to read the ProviderManifestToken from a web.config and build the edmx at runtime. Our client doesn't want one installer per DB version.
Thanks,Murali
Eventhough the actual database is SqlServer2008 you can still have a ProviderManifestToken value of 2005. So unless you are building two different versions of your software, where one targets (and uses the features of) SqlServer2008, you can just keep it as is.