Update 1 to the DSL Tools May 2005 Migration Guide

Here's a little titbit that got past us when we were putting together the migraton guide from the March to May CTPs of the DSL Tools.
I'll keep posting these as our customers come across them and we work out the workaround.

If we get enough then we'll look into posting a revised copy of the guide.

Inbetween steps 3 and 4

Open the project properties of the DomainModel project in Visual Studio.

Modify the "Default namespace" from
CompanyName.ProjectName.LanguageName.DomainModel
to
CompanyName.ProjectName.LanguageName.ObjectModel.

If you're doing this after the fact and not between steps 3 and 4, then you'll need to hit the "Transform All Templates" button to regenerate and then rebuild your solution.

A word of explanation is due (especially as other instructions have you modifying from ObjectModel to DomainModel).

In new DSL Tools projects, we've renamed ObjectModel to DomainModel.  Although the directory in your migrated solution is called DomainModel, we've decided not to modify the namespace of all the code generated therein and all of the places it is referenced from the Designer project. This is currently quite a fiddly operation and we didn't have time to match the excellent rename refactoring sported by the rest of Visual Studio.  However, we missed this step, which means that the strongly-typed wrapper classes  for your resource files will generate in the DomainModel namespace which doesn't match the rest of your project.  Setting the default namespace and regenerating should ensure that all code generated in the DomainModel project actually has a consistent ObjectModel namespace.