We've been transitioning from an old manually maintained MDG file (to one maintained via a Model) for the last few years. Because we had to support both versions, we developed an automaton to help generate the MDG, taking the model's output and merging it into the older, manual file. This has worked VERY successfully for the last 3 years (or so). Under the premise, "If it ain't broke, don't fix it", we ran this part of the functionality under v15.2 using a .eapx file for the model!
We've recently decided to move the .eapx to SQL Server since we are moving away from .eapx files (as apparently is Sparx). The rest of our setup runs v16.1; this is the only part that we use v15.2 for.
We found that moving the model to the SQL Server still produced the same output from the Model as the .eapx. We ran the same automation, and the final MDG was the same! We verify this by running File comparators on the component files and the final MDG comparing the last good output with the current output. Thus, we CAN PROVE we are getting the same results (and that the automaton is NOT affected by the change in the repository platform)!
Flushed with this success, we thought, "We can move to v16.1 since we're no longer dependent on .eapx"!
Imagine our DISMAY when we found the automaton broke and produced an invalid XML file for the resulting MDG!
Investigating further, we found that the component file generation is producing different outputs for the encoded icon and image definitions, among other differences!
Even the first line is different!
<?xml version="1.0" encoding="windows-1252"?> (v15.2)
versus
<?xml version="1.0" encoding="windows-1252"?> (v16.1) - (an extra space character) Why? Who does that?
Has anybody seen anything like this? Has anybody proven that they can generate the same MDG file under v16.1 as under v15.2?
We are using "SavePackageAsUMLProfile (GUID, File)" to generate the components (in both cases, we are running the identical script).
Help!
TIA,
Paolo
