MDG VS2005 Synchronization

[kimballjohnson]

I don't understand what can and cannot be accomplished using the synchronization features within Visual Studio 2005 when a EA model is connected.

In addition, there are apparently some features that can be done from EA and some from the MDG.

Let's Presume I understand (probably) about the differences between forward and reverse engineering and the union of the two being synchronization=first forward and then reverse.

Now then...

If I want to rename a package in a connected model and have the folder in the VS solution renamed, how do I accomplish that? (changing the folder name and re-synching doesn't work.)

If I want to move a package containing objects to another level in the package hierarchy, how do I do that? (moving the folder in visual studio doesn't work.)

If I attempt these changes in the Model, I get no change in the solution. If I attempt the changes in the Solution, I get duplicates in the model.

I would expect that 'synchronization' would handle it. But there seems to be a difference between
'generating code', 'synchronization' and 'importing from a directory'. Although I can see each requires different UI Steps, the functional differences elude me.

Thanks,

Kimball

[kimballjohnson]

Ok, I found out this much:

1. If what you are trying to do is make sure the VS Project contains the same folders as your EA Model Package (the Package you selected to be connected to Visual Studio) then...

1. Name your VS Solution with the exact text name of the EA Model Package .

2. Add a 'local paths' entry value to map to the exact path from your hard drive's root to the directory you want the folders to show up in. Like 'c:\dev\solutionfoldername\projectfoldername' and don't add a final backslash.

3. Be very careful not to enter an invalid path in the 'local paths' dialog. If you 'apply' an invalid path you will get a '0' replacements error. If you 'extend' an invalid path you will insert an invalid path into the 'genfile' tag in the underlying xml structure for every class and then you will have to export to xmi and replace text for every invalid path before you can proceed.

4. Use the 'synchronize package contents' menu item under 'code engineering' in the right-click context menu of the the connected package in the project explorer. This will generate files using the replacement of the 'local paths' tag for the actual starting portion of the path string you entered. That is, the synchronization process will walk down the path you entered as the local paths value and start creating folders and adding class files at that level.

5. Do not use the 'generate code' option unless you have explicit understanding of the 'generate file paths' options. It is clear that these options are aware of the 'genfile' value in the underlying xml but it is nowhere stated how they are using that value. You can put in several hours of experimentation without gaining any clarity from the results.

6. the 'namespace' options scattered about do not have anything to do with this process despite the obvious correlation between the EA Model Package hierarchy, the VS Folder Hierarchy and the Class Namespace hierarchy.

7. No doubt when I look inside the files I have finally gotten put in the correct folder using this method I will find that I now have to figure out the namespace issues. But, so far, I can make no sense of the docs. These are filled with statements that have no context, written only for those who already understand the way the application was conceived to work.

Thanks,

Kimball

[kimballjohnson]

On the question of how to handle changing Package names or moving sub-packages, the answer seems to be that synchronization does not handle this.

So it looks like you have to be very sure about how you want your file structure and namespaces to be laid out before you start your round-trip engineering.

Otherwise, after you hand off the solution files to developers, you will only be able to modify or read modified class files, not folders, packages, namespaces, etc.

This is going to make your refactoring have maintenance consequences for your model synchronization.

If someone has a suggestion about this part, I'd really like to get some advice!

Thanks,

Kimball Johnson