Problem with Loading Dynamic language from XML when merging assemblies

SyntaxEditor for Windows Forms Forum

Posted 10 years ago by mrjoltcola
Version: 12.1.0304
Avatar

I am using the SQL dynamic language via embedding the SQL.xml file as an embedded resource. Works fine in the standard case.

I am struggling with the requirement of the XML to contain the assembly name of the dynamic language class it is being loaded for. When using an assembly merging utility, the merged result doesn't load the language file because the assembly has changed from what I have the XML property SyntaxLanguageTypeName.

In other words, to give an example, I have a windows class library project (Foo.SQLEditorClassLib) that uses a syntax editor, and it includes a XML language file as an embedded resource.

   

SyntaxLanguageTypeName="Lib.OracleSQLEditor.OracleSyntaxLanguage.OracleDynamicSyntaxLanguage, Lib.OracleSQLEditor"

 

I load it with:

  

 System.IO.Stream xmlStream = Assembly.GetExecutingAssembly().GetManifestResourceStream("Lib.OracleSQLEditor.OracleSyntaxLanguage.OracleSyntax.xml");
   editor.Document.LoadLanguageFromXml(xmlStream, 0);

 

The class lib project is referenced from several windows form application projects (MainProgram). If I run the program assemblies through a tool like SmartAssembly to merge (and maybe obfuscate some classes, though I am not currently obfuscating), the syntax language fails to load. I can get around it by putting an XML file in each main project with a corresponding SyntaxLanguageTypeName to match, like so:

  

 SyntaxLanguageTypeName="Lib.OracleSQLEditor.OracleSyntaxLanguage.OracleDynamicSyntaxLanguage, MainProgram"

 

but then the debug / standard release builds don't work for the same reason. I don't feel I should be required to put the XML file into each main project (as I have multiple solutions), I feel that approach is poor design and breaks encapsulation. I need to be able to include this class library and have it work properly, preferably without some sort of kludge or multiple copies of the same language file.

I don't understand why the SyntaxlanguageTypeName is so inflexibile or needed at all, but I assume it is a relic of serialization. Am I missing something or approaching this wrong?

[Modified 10 years ago]

Comments (2)

Posted 10 years ago by mrjoltcola
Avatar

After writing the post above, it occured to me that I could create a workaround by wrappingthe file load into a method or class that detects the current running assembly and does a simple string replace in the XML before passing to the SyntaxLanguage.LoadLanguageFromXml() method to set the SyntaxlanguageTypename appropriately. Not ideal, but should work better than the alternatives I have considered.

Posted 10 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar

Yes, what you ended up doing in the end is one thing I would recommend.  The alternative is to just exclude the related syntax language type name from being obfuscated by making it public.

On a side note, in the newer object model design we have in our WPF/Silverlight/WinRT versions, we handle things like this very differently and don't have any attributes in the XML that require a type name.


Actipro Software Support

The latest build of this product (v24.1.0) was released 1 month ago, which was after the last post in this thread.

Add Comment

Please log in to a validated account to post comments.