DevForce Community Forum : Pain to upgrade existing EDMX to DF 2010

DevForce Community Forum : Pain to upgrade existing EDMX to DF 2010 http://www.ideablade.com/forum/ This is an XML content feed of; DevForce Community Forum : DevForce 2010 : Pain to upgrade existing EDMX to DF 2010 Tue, 21 Apr 2026 22:24:05 -700 Wed, 28 Jul 2010 19:29:35 -700 http://blogs.law.harvard.edu/tech/rss Web Wiz Forums 9.69 360 www.ideablade.com/forum/RSS_post_feed.asp?TID=2022 DevForce Community Forum http://www.ideablade.com/forum/forum_images/IdeaBlade_logo_tm.png http://www.ideablade.com/forum/ Pain to upgrade existing EDMX to DF 2010 : Ralph and Ken.Nelson, Thanks... http://www.ideablade.com/forum/forum_posts.asp?TID=2022&PID=7903#7903 Author: Amy
Subject: 2022
Posted: 28-Jul-2010 at 7:29pm

Ralph and Ken.Nelson,

Thanks for sharing your upgrade experience. Your posts will help the developers like me a lot.

Ting and Ward,

Thanks for the expert input

I'll try to do upgrade again soon and will post my expertise here.

Amy

]]> Wed, 28 Jul 2010 19:29:35 -700 http://www.ideablade.com/forum/forum_posts.asp?TID=2022&PID=7903#7903 Pain to upgrade existing EDMX to DF 2010 : Ralph - thanks for your notes! Curious... http://www.ideablade.com/forum/forum_posts.asp?TID=2022&PID=7893#7893 Author: WardBell
Subject: 2022
Posted: 28-Jul-2010 at 5:26pm

Ralph - thanks for your notes!

Curious about a few things.

1) We have run into something like your experience with assemblies downloaded over the web. Doesn't seem related to signing. Seems to relate to the way your internet settings and filters guard against nasty code. They block DLLs. You have to "unblock" them manually ... at least that's what we know to do at the moment.

3) Checkpointing was rarely used; obviously some folks used it ... because you did :-) I was one of those who could not find a good use for it. My main concern: if you saved and the saved failed, you couldn't roll back. We had to commit-in-memory before initiating save ... and we had no way to uncommit.

I've used the 2-EntityManager approach for years. Works like a charm and it's both safe and easy to understand. The main manager holds ReadOnly entities. The user picks the entity to edit. Your code communicates that to a module holding the supporting EntityManager2. EntityManager2 is your "sandbox" and you can do anything you want in there without affecting the information displayed from entities in the main manager.

When it's time to save, you do that with EM2 (I never save anything with the MainManager ... I make that ReadOnly). You'll probably want to raise some kind of event (see EventAggregator pattern) so that the MainManager and associated displays update themselves to reflect the committed changes. This is easier than it sounds.

You don't have to refresh from the database either. The EntityManager.ImportEntities feature makes it easy to copy entities from one EntityManager to another.

4a) You wrote:

"Any field that is set in a partial class upon invocation at the server does not preserve its value when returned to the client. So, if you have an entity called 'Dog', and inside your partial class 'Dog' you set a string field called m_Name = "Fido", when the entity is returned to the client, m_Name will be set to null or string.empty"

Can you send me an example? I'm not sure under what scenario this worked in DF 2009 and no longer works in DF 2010.

Is the Name property (backed by m_Name I presume) a mapped (persisted) property? Or is it a custom property? If a custom property, did you remember to mark it as a [DataMember] so we know to serialize it?

4b) You wrote:

"You must have public get/set properties for ALL fields that you want to set upon initialization. Unfortunately this opens your objects' fields to be set by other users."

I am unaware of this restriction. Can you send me a confirming example.

I know that you can't use "private" or "protected" for mapped properties if the model will be used in Silverlight. That's a Silverlight restriction, not a DevForce restriction. You can mark them "internal" though. That yields enough information hiding for most use cases; will it work for you?

You wrote: "just be prepared for a long uncomfortable battle during your upgrade process"

You are in the trenches, Ralph. I'm sure you know better than I. I've converted some apps without much trouble but then (a) they weren't huge, (b) I know where the bodies are buried, and (c) I've got the development team sitting right next door.

So ... yes ... you folks out there are shouldering a transition burden.

I must hope that you will continue to communicate your experience and suggestions to help those who follow in your pioneering footsteps. We really appreciate your help and forebearance. I believe the journey really is worth it ... and that you will come to believe that as well.

]]> Wed, 28 Jul 2010 17:26:18 -700 http://www.ideablade.com/forum/forum_posts.asp?TID=2022&PID=7893#7893 Pain to upgrade existing EDMX to DF 2010 : Ting wrote: "When you do... http://www.ideablade.com/forum/forum_posts.asp?TID=2022&PID=7888#7888 Author: WardBell
Subject: 2022
Posted: 28-Jul-2010 at 5:01pm

Ting wrote: "When you do migrate, make sure to include the foreign keys as properties on the entities"

Let me elaborate a little. Your choice of whether or not to expose FK ids goes beyond the visibility of the FK Id property itself ... it goes to how association XML is generated in the EDMX. I haven't taken the time yet to decypher the details yet but I know there's a snake in the grass somewhere. And I know you have to make the decision to expose FK Ids early in your EDM design ... as I 'll explain below.

There is no switch in the EF Designer UI to throw it from one mode to the other. The only place I've found IN THE UI where you can make this choice globally for the model is in the Wizard ... when you pick the "Generate from Database" option.

[Aside: you can "throw the switch" in the EDMX XML but (a) why do it the hard way and (b) doing so will only affect subsequent association generation; it won't "correct" existing associations. It will be too late later.]

With "400+ tables" to convert, your only reasonable conversion path is to use the EF Wizard to "Generate from Database". You can do it in chunks (Using the Wizard to "Update from Database" to add the next round of entities) ... or shoot for the moon and do it all at once ... which is what I'd probably do.

MAKE SURE that you have checkmarked both "Expose FK Ids" and "Pluralize"!

There are other differences between DF 2009 (5.x) and DF 2010 (6.x) to work through. You might want to get your feet wet by converting a "Hello World" scale application first ... even if this means writing such an app in DF 2009 first.

Assuming you have that under your belt, you can bring in your new model. Compile. And analyze the inevitable compiler errors. What might these be:

Namespace / Custom EntityManager / DataSource Key

You may have to change these values.

The namespace of generated classes will be the default namespace of the project. That's set in the project properties. You can change that at anytime and regenerate your entity classes.

Set "EntityManagerName" and the "DataSource Key" are at model-level in the "DevForce" section of the EF Model Browser's property sheet.

Pluralization Differences

The EF Wizard pluralizes a little differently than we do. You'll pick out those differences right away and use the VS refactoring tools to clean those up.

Suggestion: Get ReSharper if you don't have it already. It is far better at refactoring than VS 2010.

Massive Renaming

Perhaps your DBA forced you to prefix table and column names (e.g., INV_Invoice, PER_Person, COM_Company). You probably went through a lot of effort to strip off those prefixes in your DF 2009 model. You'll have to do it again.

I know of one tool out there that might help with massive renaming: http://www.huagati.com/dbmltools/

Or you can apply some form of regex search-and-replace tool to your EDMX; I'd give that a look first.

No more "_fk_" Foreign Key Ids

"Company_CompanyId_fk_Id" becomes "CompanyId". Global search and replace accordingly.

Inheritance

Did you use that in your old code? You'll have to rebuild your inheritance relationships. Hope you don't have too many of them. It's just basic blocking and tackling. The options are the same. The VS 2010 designer is more supportive.

Property Access

If you any of your mapped properties were other than "public", you'll have to reapply those changes. Search your original generated code for "internal", "protected", "private"; these will almost always front properties you modified in the DF 2009 Object Mapper.

Important! If you intend to use your model in Silverlight application and you want a property to be other than "public", make it "internal". We can find "internal" properties. Silverlight prevents us from finding "protected" or "private" properties.

New Option: You can delete one side of a navigation property. You really shouldn't be able to navigate from "Gender" to "Person"; delete the Gender's "Persons" navigation property.

Validation Options

If you messed with these you'll have to reapply them. You can change the model level default in the "ValidationAttribute Mode" setting in the "DevForce" section of the EF Model Browser's property sheet.

Property level validation options are different in DF 2010. The "Validation" option under the "Attributes to Suppress" setting may do the trick. Let us know if you get stuck here.

Unmapped Abstract Entity Classes

In both DF 2009 and DF 20010 you can put your own logic in a custom base class that isn't mapped to anything. Many folks create their own "EntityBase" that sits on top of our "Entity" class and just below their concrete entity classes (e.g., "Customer", "Employee").

You'll have to tell DevForce about this if you're using a base class.

If you have one type that you use for alll (or almost all) entities in this model, type the name of this "Default Base" class into the "Injected Base Type" setting at model-level in the "DevForce" section of the EF Model Browser's property sheet. Remember to include the namespace if your base class is in an assembly other than your model project (e.g, "CommonEntity.EntityBase"). Your base class must inherit from IdeaBlade.Entity ... unless you were modeling with POCOs instead of doing code generation (another side topic).

In DF 2009 you could insert unmapped base classes in the middle of an inheritance tree. For example: Apple -> FruitBase -> Produce -> EntityBase -> IdeaBlade.Entity. "FruitBase" is your abstract class between two mapped classes, "Apple" and "Produce".

You can't do that in Entity Framework v.4 and therefore you can't do that in DF 2010. You'll have to come up with another approach to specify common "Fruit" behavior for your apples and oranges. I have some compositional strategies in mind.

You can stack multiple base classes but they all have to reside below the first mapped entity ... Apple -> FruitBase -> EntityBase -> IdeaBlade.Entity.

Unfortunately, you can't specify different abstract base classes for different mapped entity classes through the UI. You can't have concrete fruit types inherit from "FruitBase" while concrete meat types inherit from your custom "MeatBase". You'll have to either post-process the generated code (which will be wiped out the next time you regenerate) or customize our code generation.

Custom Code Generation

The (almost) universal solvent is custom code generation. It is really easy in DF 2010 to customize the code we generate. We are using T4 templates for code generation. We've got a nice customization API over our T4 so you don't have to wrestle with that technology.

Code generation customization lets you intercept the EDMX XML, interpret it yourself, and emit your own code. You might get out of some jams with this technique.

Such are my current ideas on the subject. It's a far cry from the automated conversion tool you seek. I bet it will cost you a day or two to convert 400 entities. The compiler will surely help; just about everything that will go wrong will be caught by the compiler.

Do let us know ... we are curious.

]]> Wed, 28 Jul 2010 17:01:34 -700 http://www.ideablade.com/forum/forum_posts.asp?TID=2022&PID=7888#7888 Pain to upgrade existing EDMX to DF 2010 : Yes, the migration across architectures... http://www.ideablade.com/forum/forum_posts.asp?TID=2022&PID=7873#7873 Author: ting
Subject: 2022
Posted: 28-Jul-2010 at 2:54pm

Yes, the migration across architectures is a bit of an undertaking. Some of the pain is unavoidable, but some we could have made easier with documentation (see the 6.0.1 section in the Release Notes for notices in key areas).

Unfortunately, for one of the larger items - EDMX migration, Microsoft changed the spec considerably and did not provide a migration tool to move the .NET 3.5 EDMX to .NET 4.0, so this meant that their recommendation was to rebuild the model again with the new Entity Framework. We don't have the full spec for the EDMX, so writing this tool ourselves would have been a bit risky and out-of-scope for us. Some of the other changes you are seeing were also decided by Microsoft and we are following their standard. When you do migrate, make sure to include the foreign keys as properties on the entities. If you don't, you'll get an "Index was outside the bounds of the array" (or similar) exception.

Regarding the signed assemblies on the server. I was not aware of this, but will take a look at it.

Also, for anyone following along, there's more information about serialization of custom properties here:

http://www.ideablade.com/forum/forum_posts.asp?TID=1957

Finally, for the stored procedures, jmpinchot reports that everything is working in DevForce 6.0.4.

Edited by ting - 28-Jul-2010 at 3:08pm]]> Wed, 28 Jul 2010 14:54:03 -700 http://www.ideablade.com/forum/forum_posts.asp?TID=2022&PID=7873#7873 Pain to upgrade existing EDMX to DF 2010 : We ended up alleviating some of... http://www.ideablade.com/forum/forum_posts.asp?TID=2022&PID=7854#7854 Author: ken.nelson
Subject: 2022
Posted: 28-Jul-2010 at 8:22am

We ended up alleviating some of the _fk_ problem by doing a solution wide search and replace of "_fk_" to "". This didn't fix them all but was a decent start.

It also seems like the navigation property generator is not as robust as the 2009 version, as it left us with a bunch of navigation properties named "Image" and "Image1" instead of "PatchImage" and "SymbolImage" even though the foreign keys were named with Patch and Symbol. If you look at the relation in the navigation property properties, you can figure out how to name it properly (tedious, but worked).

And if you're using any StoredProcQuery, they currently need a workaround to function properly.

See here:
http://www.ideablade.com/forum/forum_posts.asp?TID=1968&KW=stored&PID=7739#7739

]]> Wed, 28 Jul 2010 08:22:06 -700 http://www.ideablade.com/forum/forum_posts.asp?TID=2022&PID=7854#7854 Pain to upgrade existing EDMX to DF 2010 : Hi Amy, We just finished the... http://www.ideablade.com/forum/forum_posts.asp?TID=2022&PID=7853#7853 Author: Ralph
Subject: 2022
Posted: 28-Jul-2010 at 8:09am

Hi Amy,

We just finished the upgrade as well, and discovered a few caveats that were unexpected and painful:

1) Signing the assemblies causes a 'Target Invocation Exception' to be thrown when retrieving your entity models from the server. I was able to get this same message using DevForce's sample project.

2) Changing the entity event argument object types on fetched, login, and save events. This wasn't too bad, since the compiler did most of the work, but it did affect a good chunk of our code.

3) The checkpoint manager has been removed. According to DevForce, this feature wasn't used by many people (although I can't imagine how they came up with this conclusion), so they decided to remove it. Their suggestion is to use 2 entity managers and manually manage this yourself.

4) Any field that is set in a partial class upon invocation at the server does not preserve its value when returned to the client. So, if you have an entity called 'Dog', and inside your partial class 'Dog' you set a string field called m_Name = "Fido", when the entity is returned to the client, m_Name will be set to null or string.empty (I'm curious as to how DevForce is creating the objects on the clients w/o the class constructors being called at the client). You must have public get/set properties for ALL fields that you want to set upon initialization. Unfortunately this opens your objects' fields to be set by other users.

I feel like I'm forgetting a few things, but just be prepared for a long uncomfortable battle during your upgrade process. I'm sure their changes are for the better, but we were disappointed with how much work the entire process was. Good luck.

]]> Wed, 28 Jul 2010 08:09:39 -700 http://www.ideablade.com/forum/forum_posts.asp?TID=2022&PID=7853#7853 Pain to upgrade existing EDMX to DF 2010 : One correction: After I changed... http://www.ideablade.com/forum/forum_posts.asp?TID=2022&PID=7848#7848 Author: Amy
Subject: 2022
Posted: 28-Jul-2010 at 6:40am

One correction: After I changed the project target FrameWork to 4, the 'Include FK in the Model' check box is not grayed out any more, but the FK format problem still remains.

Thanks!

Amy

]]> Wed, 28 Jul 2010 06:40:32 -700 http://www.ideablade.com/forum/forum_posts.asp?TID=2022&PID=7848#7848 Pain to upgrade existing EDMX to DF 2010 : Hi Everyone, Did any one upgrade... http://www.ideablade.com/forum/forum_posts.asp?TID=2022&PID=7847#7847 Author: Amy
Subject: 2022
Posted: 28-Jul-2010 at 5:47am

Hi Everyone,

Did any one upgrade existing EDMX(like from v. 5.x.x.x) to DevForce 2010 yet?

Currently we are using version 5.2.3.1 and VS 2008. Our database includes 400+ tables. I was trying to upgrade to VS2010 and using DevForce 2010. There is not much instruction how I can upgrade the existing EDMX easily. I upgraded my solution and refreshed the DevForce dlls with new ones. Open my existing EDMX --> Update Model from database, the 1st thing I noticed that the 'Include FK in the model' is grayed out. But that check box is required to be checked to pass the compiling. If I started everything from scratch, I will lose everything I changed in old OM. For example In NorthwindIB database table, the Employee table has FK to itself(ReoptsToEmployeeID), in the old OM, it is already nicely renamed to Manger & DirecReports; if I recreated the EDMX in DF2010, I have to go thru all the renaming procedure again, plus the old FK was created at Manager_fk_EmployeeID format, the DF 2010 doesn't follow the format _fk_ any more, we have to make a lot code changes for that too. It seems too much to do the upgrade to DF2010.

In the past, every time we upgraded to a new version DF, we have to make code changes: either some DevForce dlls is no longer supported or the function/property is obsolete. Never pain free. This time, the pain is unbearable. Basically I gave it up to upgrade to DF2010, until somebody show me an easy way, may be I went to wrong direction?

Please help!

Thanks!

Amy

]]> Wed, 28 Jul 2010 05:47:24 -700 http://www.ideablade.com/forum/forum_posts.asp?TID=2022&PID=7847#7847