Problem with Loading Dynamic language from XML when merging assemblies

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?