We have classes in a Production environment that are causing us some issues - example attached.

When we export them from the production environment the XML contains a snippet like the following:

<UDLText name="T">
<Content><![CDATA[
//Property any As list Of %XML.String(XMLNAME = "any", XMLPROJECTION = "ANY") [ SqlFieldName = _any ];

]]></Content>
</UDLText>

When imported and compiled into an Ensemble instance this class works as expected.

When viewed/edited in a development environment we run into issues - the presentation is similar with both Studio and VS Code.

On first viewing in Studio the class source code displays like this:

If you use the extension in VS Code view the class, or export it from there, again the code displays as above (and is saved in this form to the filesystem if exported).

However, if the file is modified and saved in Studio, or modified and saved or even simply compiled (import and compile) in VS Code then the source is serialised and returned to Studio/VS Code by Ensemble as:

From part of a previous conversation with @Brett Saviano  (Request textDocument/documentSymbol failed. Error: name must not be falsy · intersystems-community/vscode-objectscript · Discussion #1530) we understand this serialisation is the correct behaviour.

However, we are left with a few of questions:

1. Serialisation does not appear to happen when the Ensemble -> System Explorer -> Classes page exports the class - is this correct? (ie present in Ensemble with the comment as '//Property', then the exported class has '//Property' rather than '// Property')
2. Is this likely to be the same reason that the "InterSystems" tab in VS Code exports the code without the space (they are using the same underlying mechanism)?
3. Can anyone come with any ways in which classes such as the one attached came to be in our Production Ensemble in the first place?
4. We tried importing and re-exporting the class using $SYSTEM.OBJ - Load(file, "cuk") to import, and Export(class, file) to export. It did not modify/serialise the class - the '//Property' was left intact.
5. And finally, is there any way of programmatically forcing this serialisation change and exporting the changed classes - our repo was created with the non-serialised versions of these classes, and now the classes with this issue sporadically show up as "phantom changes" - not relating to the development we are actually attempting to do!