Thank you for the testcases (really liked some of the exception messages used).
You have a main application that references 2 class libraries. Each of these class lib assemblies has its own copy of _Intf file. This means that both referenced class libraries have their own set of interface classes. for .NET they are different classes despite they have equal definitions, names and namespaces.
As a result when a response from the server is received serializer sees that it needs to instantiate a class named TWebException . However there is no way it could tell which exactly class should be instantiated (because there are 2 identical classes in class lib 1 and class lib 2). This will result in odd errors like
Instance of type 'UserInfo' cannot be cast to type 'UserInfo'
not catching exception of type TWebException (because for .NET class system they are different classes).
Move shared classes (aka the _Intf file) to a separate assembly and to reference that assembly from both class library projects
2.Custom exceptions marked as Internal (locked inside assembly)
Remoting SDK expects these classes to be public . Also it is highly not recommended to manually edit the _Intf classes.
Still it is possible to use the internal classes instead of public. You have to manually register types you made internal to let Remoting SDK use them. To do so you need to run code like
during application startup. This will allow Remoting DK to use these classes while deserializing stuff received from the server.
3.RODL generated interfaces
This is actually a bug. Seems there is an issue with the RODL returned from the remote server - not all entities from referenced DataAbstract rodl were marked to be skipped while _Inf is generated.
Considering (1) it shouldn’t generate any code for DataParameter etc at all, instead type definitions from the assembly RemObjects.DataAbstract should be used. CodeGen is fixed already to properly handle this case.
4.IIS Express character encoding
This is the only serious issue here. Your Data Abstract server sends data using 1-byte encoding. Depending on the code page used on the receiving side (IIS or IIS Express process) these bytes can be deserialized into different Unicode characters.
Obviously it is not an option to change Schema on the server side (as this will break all existing client apps). So we’ll consider to provide an option that will allow to explicitly specify which exactly encoding should be used as default when the data is deserialized.
I’ve already tested a prototype of of the fix and it allowed me to read data with Č and Ć chars. Expect the fix to be available mid next week.