And you thought I might never post on D3 again. I know. I know. Jedi knights don’t wait 6 months for a follow-up blog post.1 Well, the wait is finally over. I’ve put a new release of D3 up on code gallery. In this release the code has been updated to work with VS2010/.Net 4 beta 2. The release also includes a reorganization of project names and some new functionality, but I’ll talk about those in a future post or two. For this post, let’s look at the three broad steps involved in upgrading the project since they illuminate EF features and changes you might need to make to move some other project from beta 1 to beta 2.
Step 1 : Basic Compilation
When I loaded the solution in beta 2 and tried to recompile, the first problems I encountered were issues with stylecop—there were a number of errors referring to a file called ".NETFramework,Version=v4.0.AssemblyAttributes." I found a solution in this thread.
The next change needed was to react to the EF’s breaking change from beta 1 to beta 2 where the ContextOptions property DeferredLoadingEnabled was renamed to LazyLoadingEnabled. The semantics of this property didn’t change—just it’s name, so this was a simple fix.
Once compilation was passing, the next step was to start leveraging new EF features in beta 2.
Step 2 : Adding FKs to the Model
Beta 2 not only added runtime support for FKs in the model, but the designer is now smarter about them, and they are turned on by default. So I had a few options:
- I could do everything by hand:
- Manually add the FK properties.
- Go to each association and add the referential integrity constraint between the FK property on the dependent entity and the primary key on the principal entity.
- Remove the association set mappings for the associations since the mapping will now be handled by mapping the FK property on the entity just like any other entity.
- Finally, either manually add the mapping for that property or regenerate the database from the model.
I choose option #3 for no reason except that it was interesting to come full circle from a model-first database to a DB first model and then back to model first when further changes are needed. :-) In the process I encountered one may difficulty which was that reverse engineering from the database uses a simplistic algorithm for naming things that works reasonably well when you only have one relationship between any two entities, but when you have more than one relationship between the same pair of entities things get a bit confusing. In D3 I have two identical relationships between Room and Exit–one for leaving a room by way of an exit and the other for entering a room from an exit. The one tricky thing is determining which association was connected to which navigation and FK property. First you need to right click on the navprop and choose the "select association” menu item. Then you can double click on the association to see a dialog which describes the referential constraint including the FK property.
Step 3 : Updating Model First Workflow & Templates
The final step was to update the D3 model first workflow and templates both because the bug mentioned in this previous post was fixed and because of other changes and improvements made by the designer team in beta 2. You can read the details of those improvements on the ado.net team blog, but the summary is that there are now two properties available in the EDM designer when you click on an empty place on the designer surface. The “Database Generation Workflow” property allows you to specify which workflow xaml file will be used when you choose to generate the database from the model. The default value picks up the file from one of the VS installation directories, but it can also point to a per user directory (where a new xaml file could be installed by a VSIX package for instance) or to a location relative to your project directory. The “DDL Generation Template” property specifies the T4 template used in the step for generating the data definition language based on the SSDL.
I was able to keep the overall strategy the same—for the most part just comparing the original versions of the files to the new versions and reacting to things like the renaming of the namespace Microsoft.Data.Entity.Design.Pipeline.EdmExtension to Microsoft.Data.Entity.Design.DatabaseGeneration.Activities, or the change in xml namespace for the StoreGeneratedAttribute in SSDL from the SSDL namespace to the annotations namespace.
In the case of the SsdlToCode template there were more extensive changes, so I took the new template from the system and reapplied the same customization I originally made. Once the updates were complete, I diff’d the new template against the old one and the changes generally fall into the following buckets:
- Updating assembly and namespace names
- Moving re-usable utility code out of the template and into a shared ttinclude file
- Supporting multiple sql server schemas in the same ssdl file
- Supporting SQLCE by skipping things it doesn’t allow like specific schema names
While I was at it, I also applied a couple of improvements which a colleague suggested could be made to the default template including removing the “WITH NOCHECK” clauses when creating constraints and adding statements to create indexes for each foreign key.
The final result of all this is that D3 is up and running on beta 2. We’re back to the functionality we had last June with beta 1 plus we now have FK properties and a somewhat more efficient database. This is just the foundation needed so that we can start filling in more of the overall application.
1. For some of us increasingly old geezers, the cartoon Bloom County by Berke Breathed was a major part of our lives once upon a time. So I can’t help occasionally throwing out obscure references to it. You can see the specific strip I’m referring to here.