Have you ever tried to change the structure of your database, or include a new table in your database-first EDMX, only to find that when you go to rebuild your solution you get about 1,837 new errors? “How can this be?!”, you might ask. “The database is setup right! The code worked fine 2 minutes ago! I just added a new table to the EDMX and everything blows up!”.
Here’s the thing: Visual Studio and Entity Framework aren’t perfect yet, and the wizard for adding/refreshing/removing objects from the EDMX isn’t smart enough to handle everything you throw at it. It gets confused fairly easily, to tell you the truth. Sometimes you need to take your superior human brain into the XML guts, root around, and fix some messes. Here’s how.
I want to take a second here to remind you to backup, branch, or at least commit your code while it’s in a good state. You’re going to be messing with complicated XML and if you delete the wrong thing, or change the structure incorrectly you could have a hard time fixing it. You might have to revert and start again. You have been warned…
Right-click on your EDMX file, select Open With…, then select XML (Text) Editor. Boom, there is your entire EDMX file as Visual Studio and .Net sees it, in all its XML wonderfulness.
As I said above, the EF wizard isn’t all that smart about changing existing entities. If you change your database structure and remove a field or two then refresh your model, chances are those fields are still going to be hanging around in your models causing confusion. You’re going to need to do the wizard’s job and remove those fields for good.
Using the instructions above, open up your EDMX as XML. Search the text for the name of the field you changed/removed. It will appear 4-5 times if it’s a normal field, and considerably more if it’s any kind of primary/foreign key. Go through all instances and modify the XML to your liking for each. In the case of removing a field, you’ll just remove all traces of that field the EDMX file.
As you probably know, every time you hit save while looking at the EDMX diagram, Visual Studio spins for a couple seconds. It’s actually looking at the XML we just talked about and deciding whether it needs to change any of your generated classes as a result. It doesn’t always do the best job of changing existing classes. Sometimes you might have done something to confuse it and it doesn’t update the classes as you’d expect. For instance, take removing or renaming a field from your database as an example. You don’t want to modify those generated classes, because at some point you’ll regenerate them and all your changes will be overwritten. You might just want to have VS start over and try again from scratch.
To do this, find the [YourDatabase].tt file (not to be confused with the [YourDatabase].Context.tt file), and expand the cs files below it. You’ll see one file for each database table you’ve imported. Highlight all of the files and delete them all. Trust me, it will be ok. Once deleted, right-click on the [YourDatabase].tt file and select Run Custom Tool. Give it a few seconds to think and all your classes will be regenerated again.
Visual Studio’s default EDMX process is great, but it can’t foresee every nuance of every custom database. One example is multiple relationships to the same table. For instance, in my legacy application I sometimes have tables with multiple relationships back to the user table. (A table with fields like CreatedBy, LastModifiedBy, SubmittedBy, etc.) The generated class will contain objects like User, User1, User2, etc. Not really helpful when you’re using those classes in code. You can do a few things to make your generated classes more helpful. Let’s dive into the T4 templates.
Open the [YourDatabase].tt (T4 Template) file. This contains the template used to generate all the classes for your database tables. In it, you’ll see each part of a class file with other methods and properties sprinkled in. You can do a ton of cool things inside this file to help make your generated classes easier to use. I’m going to show you one of these neat tricks.
Search the file for “foreach (var navigationProperty in navigationProperties)”. This is going to loop through all the relationships (navigation properties) in the class it’s working on. A little farther down you’ll see <#=codeStringGenerator.NavigationProperty(navigationProperty)#>. This is going to output the property text, think public User User3 { get; set; }. Right above that line we’re going to add:
/// <summary>
/// Relationship Name: <#=code.Escape(navigationProperty.RelationshipType.Name)#>
/// </summary>
#=codeStringGenerator.NavigationProperty(navigationProperty)#>
This is going to add a summary block above each navigation property including the relationship name (foreign key name). This summary block is included in the intellisense displayed when you hover over the relationship while typing out code. If you have your foreign keys named decently, you can use this to help you figure out which User (User, User1, User2, User3, etc) is CreatedBy, LastModifiedBy, SubmittedBy, etc.
To summarize, Visual Studio makes working with Entity Framework pretty easy but it still has a way to go. Hopefully this post will help make up for a few of the places it falls short.
We love to make cool things with cool people. Have a project you’d like to collaborate on? Let’s chat!
Stay up to date on what BizStream is doing and keep in the loop on the latest in marketing & technology.
