As a side note, even if I remove the linked RODLs, the generated file has some methods missing on the ILicenseService interface, which is quite annoying.
As a side note, even if I remove the linked RODLs, the generated file has some methods missing on the ILicenseService interface, which is quite annoying.
It looks like the RODL file has beed edited manually and 2 method definitions in the LicenseService were copied over from similar methods. The issue is that these methods (source and copy ones) now have the same UID value. For the 2 methods missing from the generated code you need to manually change the UID node value (it should be enough to change literally any digit to another one).
As for the original issue:
An exception is raised because code generator cannot determine the proper namespace that it should use for the entities defined in the reference RODLs. Thanks for your testcase this will be fixed in the next build.
For now as a workaround please open the main RODL file in a text redactor and find text </use>. There should be 2 entries for RODLs you reference. Insert before each </use> tag the following line:
Thanks, I have fixed the duplicate UIDs, you were right, I often edit the RODL in a text editor as it is easier this way when I add a new version of a function. Maybe there could be a “duplicate element” menu item in the Service Builder.
As to the other workaround, it does prevent the Service Builder from crashing, but I’ve had to adjust the suggestion a bit. First, I made the UID parameter use the same GUID as the one in the use tag.
Second, I made sure the DotNet tag gets a proper namespace value (ROServerDiscovery for instance) as Namespace.Child is not a magic value at all, it gets used as is as a prefix in the generated interface file.
Then I made sure DontCodeGen is set to 1 on both use tags as not doing so would generate a duplicate and ambiguous TLogLevel enum.
But despite all this, I get a uncompilable interface file because TLogLevel is not prefixed by its source namespace in the TASMOptions.ReadComplex and TASMOptions.WriteComplex methods.
Editing the interface file to add the proper prefix in those three locations allowed me to get a compiling file and use it properly from my application.