Custom error exceptions, IIS express encoding, RODL generation issues

Hi,

I’ll cover 4 use cases where I found some things quite interesting.

1. Custom exceptions:

Server is Delphi based with one custom exception class called TWebException. It’s thrown when web application needs to parse some specific data due globalization and localization.

Client is ASP NET MVC 5 application on .NET 4.5 framework. Nothing fancy, just imported interfaces inside 2 assemblies so that I’m not dependent on RemObjects inside MVC application.

Issues comes when two assemblies are included in main project, and custom exception is invoked. For the first assembly call, proper handling is executed and custom exception is invoked. When the second assembly is called, error happens, but custom exception is invoked from the wrong assembly (it’s called from the first one), and returned error is of type Exception, but when you review in debug mode, there are properties from custom exception.

2. Custom exceptions marked as Internal (locked inside assembly)

Same thing as first one, but this time from the generated interface, I’ve changed public partial class to internal partial class (don’t want to expose it publicly), and custom exception is not invoked.

3. RODL generated interfaces

This is pretty simple, click on Visual Studio (2015) icon for RemObjects services (solution explorer) to import interface, enter url, click done. By this point I would expect to just compile and run assembly, but that’s not happening. Generated interface is missing some assemblies and proper namespace to work.

(See README in sample)

4. IIS Express character encoding

Now let’s move on and try combine DA tables with services, common case in our environment, btw our language is Croatian, Bosnian, Serbian with latin and cyrillic letters. I would expect that RemObjects and DA handles encoding properly on IIS Express and IIS server the same, with proper encoding, but some specific letters as Č and Ć are missing in IIS Express.

I have sample ready for review.


Sample is not for public, can you provide me with private repo where I can attach files?

Hello

You can send as a mail attachment to support@ . It will be kept private there

Samples are sent on support@

Hello

Thank you for the testcases (really liked some of the exception messages used).

1.Custom exceptions

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'

or

catch(TWebException)

not catching exception of type TWebException (because for .NET class system they are different classes).

Solution:

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

RemObjects.SDK.TypeManager.AddType(typeof(TWebException));

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.

Regards

Thanks, logged as bugs://78647

Thanks, logged as bugs://78648

Great, thank you for review.

When we’re there, can I ask one more thing, regarding unit tests.

I’ts easy to mock and test services because they are generated as interfaces, thumb up for that, but I have problems mocking RemoteDataAdapter to test Fills from server (it’s delphi based). Can you give me some guidelines how to can I cover DA things with unit tests.

Example can be found in sample (4. CombinedServicesAndDA.cs) where I’m fetching data through remote data adapter.

Usual tactics is to hide all DA stuff behind an interface, cover that interface with integration tests and mock the interface for all other layer’s tests.

Well that’s the way that I’m doing things right now, just wanted to see is there any better ways to do it.

Thank you for feedback.

bugs://78648 got closed with status fixed.

bugs://78647 got closed with status fixed.

You will be able to explicitly set encoding that should be used to decypher Delphi-set 1-byte chars into .NET Unicode chars and vice versa:

var adapter = new RemoteDataAdapter();
adapter.DataStreamer = new Bin2DataStreamer {DefaultStringEncoding = Encoding.GetEncoding("windows-1250") };

Thank you, when I can expect patch release?

It should be availabe during next few days.

Hi again, there are few more mistakes that you need to patch up.

DataAbstract dlls are not included, they must be manually included after generation and you don’t have implementation for 5 factories that you expose via ServerAccess.

Tested on 9.3.0.1333

Fixed the code generation there as well. Thanks for reporting.

Can confirm that issues are resolved in version 9.3.105.1337.

Thanks.