Receiving half-lenght strings from .NET client in a C++Builder server

Hello,

I have advanced something in my .NET client, but now I’m facing the issue described: the strings arrive into the Server (which is developed in C++Builder) with half the length.

In my service all strings are defined as WideStrings, and the C++Builder client works fine. With the .NET client I see all the string parameters as type string, and the serialization code appears to be correct: it calls “WriteWideString”.

I haven’t tried changing the service to use UTF8Strings, but would certainly prefer not to change it if it can be avoided.

Is there something special to take into account when mixing .NET clients and VCL servers?

Thanks

I found the problem. It has to do with the TypeInfo helpers created for C++Builder compatibility. For WideString parameters I was using UnicodeString, but it should be WideString.

I haven’t been able to download the latest beta and see how, if they were indeed changed, the TypeInfo helper classes were implemented. But if you used the code I sent it should be checked that the TypeInfo for WideStrings do map to WideStrings and not UnicodeStrings. (although I had the idea that WideString was just an alias for UnicodeString, and that’s why I set it that way originally). I believe the Issue number you used for this was 70830.

Apparently there are still some issues with this, as now the parameters get correctly into the server, but the returned values have some garbage after the string ends, say, where it should say “Magia 101” it says: “Magia 101䱎敽ᔀ蠀” The extra characters are not correct (nor set in the Server). This still seems to be a problem with the amount of data returned/expected, but I don’t really know where else to search for.

can you create a simple testcase, pls?

we can’t reproduce this problem with simple method like

void __fastcall TNewService::echo(
  const AnsiString  NewParam,
  const WideString  NewParam1,
  const UTF8String  NewParam2,
   AnsiString & NewParam3,
   WideString & NewParam4,
   UTF8String & NewParam5
  )
{
  NewParam3 = NewParam;
  NewParam4 = NewParam1;
  NewParam5 = NewParam2;
}

also

function GetTypeInfo_WideString: PTypeInfo;
begin
  Result := TypeInfo(WideString);
end;

was used. everything is work (C++ Builder server and ROD/RON client)

Hello Evgeny,

For this to fail you need to create a C++Builder server and a .NET client. Having both in the same platform works fine here too. This works even with the TypeInfo incorrectly set to UnicodeString, as it was in my original code.

I will try anyway to create a test case, but you should be able to see the problem invoking that service from a .NET client.

Thanks

Edit: re-reading your post, you already tried with a .NET Client? That’s the ROD/RON client?

we have tried these combinations:

  • C++Builder server + .Delphi client
  • C++Builder server + .NET client

I was thinking: I’m using Runtime packages and Dynamic RTL on the Server, and AES encryption, bin Message and a SuperTCP transport. Don’t know if it changes anything, but that’s my setup.

The problem seems to be only with structs. “Simple” params work fine, but when you send/return a struct, or an array of said structs, then the problem appears.

This only happens, at least so it seems, with WideStrings.

I’m polishing the test case to send it, but you should be able to reproduce it adding a struct to your library and later using it.

Here is the test case, the C++Builder server and the .NET client.

This shows the issue for WideStrings only, and only when passing a struct that includes it. Passing the strings directly doesn’t fail.

TestStrings.7z (53.8 KB)

It doesn’t matter if the transport is being encrypted or not (disabling the AES envelope doesn’t change the outcome).

Thanks, logged as bugs://71348

bugs://71348 got closed with status fixed.

I’m glad you could find and fix this issue. Any change of getting the changes as a hotfix or something similar? Thanks!

it will be included into incoming release (in a few days)