I've been using EF 4.1 and the POCO template generator.
I love and hate EF. I love the time I save. I hate maintaining the EDMX file.
But while keeping the EDMX in sync with the database has been a challenge, I'm now overwhelmed by the POCO generator. Up until now, the POCO generator has created POCO's for me and kept the ClassObjects.Context.cs empty and non-conflicting.
After my most recent refresh I have had constant problems with "Amiguity between 'perseus.DataLayer.accounts' and 'perseus.DataLayer.accounts'.
I get this error for every POCO.
I'm on the edge of panicking as I recommended and owned the maintenance of EF. I've spent a couple days on trying everything from database refreshes to deleting all items from the EDMX file and reloading them from the database.
Nothing has made a difference. I have no clue what has suddenly changed from the last few months of relative stability. I'm seriously lost as to what I can do from here.
It looks to me like you have not disabled the code generation strategy. click on the designer background and check the properties tab, the first item is Code Generation Strategy. This should say None, and not Default.
Editing the edmx manually is difficult and error prone. I would suggest copying what you have off to another location then letting the tool regenerate the edmx for you. Compare the two.
I worked with some DB2 entities that I had to manually sync and had constant issues. The tool would clobber my changes and I would have to manually replace that with working code.
If at all possible, don't modify the edmx code yourself. If you must, make the changes, copy those off to a text file in the project for tracking/safe keeping.
Related
I know this isn't the designed method of using EntityFramework but I have a much easier time designing the database in SQL Management Studio to create indexes, link foreign keys, etc... all visually. But I really want to use the automatic database updates for the future when deploying updates to customers.
I designed the original database in SQL Management Studio then created the EntityFramework code first from that database. But if I want to add another table so far, I end up dropping everything then regenerating the DB from SQL Management Studio. This has been ok for the first part of my framework development but now things are starting to get a little more complex.
I've tried to learn the code first mechanism but some of the more complex items have bit me and I don't have a lot of time to allot for this. I was hoping there was a hybrid way of designing in SQL Management Studio then utilizing the database deployment functionality built into EntityFramework.
I'm working on getting the POCO reverse generator running here but having some issues. Ultimately, I think that is the way I'll want to go. But I did find a temporary workaround with existing tools built into VS2019 until I get that tool working.
I made a copy of the name of the model because I had a custom initializing for the connection string.
Delete the model file
I right clicked the folder where the codefirst files are placed in my solution then add-new item
Select ADO.NET Entity Data Model and named id the same as the one in step 1
Select Code First from Database
Deselect saving connection string (it won't overwrite and the needed one is already in the app.config)
Select the tables to import
In my case I deselected the Pluralize object names
Finish
Update the master model file with the custom initializer
In the package manager console enter: add-migration (I'm assuming you already have migrations set up)
name the migration
add-migration [name in step 12] (this applies the migration)
It might seem like a lot of steps, but it's actually not. And so far with a couple of days of playing around with it, I'm not running into any issues.
As we are working on the refactoring of our current legacy code which is in Database first(EDMX files). We have decided to move on Code First approach, but moving edmx to Code First in a single go would create a lot of testing effort. Is there any way to run EDMX and Code First logic simultaneously in a single project for a time being (Planning to move few classes not completely in a single go).
Please suggest.
Is it generally a good idea to manually modify the generated EDMX file when working on a .NET project? I had a project once where the developers were modifying the edmx file manually, and it was accepted as a rule to never regenerate the whole EDMX file. For example, one change we made was with some fields whereby we changed them to enum values.
Then I was hired on a project where the developers were telling me to regenerate the EDMX file whenever I made database changes. This was a totally different point of view.
So what is the better solution? Has anyone had any nightmares where one was better than the other.
A general rule is not to edit any auto generated file whether it's EDMX or WinForms designer. However, if there is absolutely no other way and you do need to edit auto-generated class, then do it by using partial class. This way your change won't get lost after the class is regenerated.
The project I am working on is using Entity Framework 4.3 and data migrations to keep the schema up to date. Over the course of the project the migrations folder has grown and now has over 600 files. This is huge. We now have a binary which is over 12MB due to all the migration meta data.
I would like to collapse all these in to one migration and start again. My concerns are:
Is this possible or will it cause problems with the migration history if I remove migrations?
Are there any guides around describing how to do this?
First: I recommend that you keep your migrations in a separate assembly so they don't have to be published with the application. It could be a simple console app that applies the migrations or a winforms GUI that generates scripts. But there's no reason for it to be deployed with the app imo.
Second: Understanding that you'd be giving up the ability to roll back to previous versions, you could just exclude-from-project all of your prior migrations then generate a new one which should then be able to create a database reflecting your current model. That would serve as your new starting point. Remember that EF doesn't always generate code to do everything you want in a migration, so you might have some hand-written migration code in other migrations you'd need to pull in.
Not sure past versions, but if you are here looking for the same solution for EF Core. You should be able to just delete the ModelSnapshot and re-run your migration to create a clean sheet.
I am using Code First Data Migrations and have my development database so built up that I really don't want to start fresh again. I had deleted an old table and cannot get EF to accept any model changes due to this lingering phantom table. How can I get a clean version of my database context based on the model that's currently in place? Any help would be greatly appreciated!
You could use a "Code Second" approach and reverse engineer the model from the database. A good way to do this is to use the Entity Framework Power Tools for VS to do the reverse engineering. Once it is installed just right-click the project and select Entity Framework > Reverse Engineer Code First and select the relevant database in the dialog. This will generate a model in the Model folder.
I usually do this in a dummy project and then copy the files across. The model generation is actually very clean and adds some nice features like initializing ICollections to a new List in the constructor which are sometimes left out of the original Code First model.
EDIT
Here is an article which outlines the process using EF with an Existing Database