serious bug with strings with non-basic ASCII content (like extended ASCII characters) !!

Please report bugs here. If you are unsure whether something is a bug or an expected behavior, please post it on the "Technical Support" forum instead, and wait for a moderator to handle/move the post.
Sesztak
Posts: 172
Joined: Fri Jun 24, 2016 2:19 am

serious bug with strings with non-basic ASCII content (like extended ASCII characters) !!

Postby Sesztak » Thu Jul 07, 2016 2:51 am

Short problem / bug description: if we call a WCF service methode with extended ASCII string content we have got null result at Server side !

Basic configuration / test enviroment:

WCF Server side interface and method to test string content with extended ASCII characters:
interface:
[OperationContract]
string TestNonBasicASCIIcontentExempliGratiaExtendedASCIIchars( string TestContent);

method implement the interface:
public string TestNonBasicASCIIcontentExempliGratiaExtendedASCIIchars(string TestContent)
{
// echo back :
return "server response: " + TestContent;
}

CSHTML5 test call with only basic (i.e. non-extended ASCII characters):
var response = _kliens.TestNonBasicASCIIcontentExempliGratiaExtendedASCIIchars("Peter Paul basic ASCII chars: oueai OUEAI");
Everything is okay / as expected ! :
Server side debug result: TestContent = "Peter Paul basic ASCII chars: oueai OUEAI"

CSHTML5 test call with Extended ASCII characters):
var response = _kliens.TestNonBasicASCIIcontentExempliGratiaExtendedASCIIchars("Péter Pál common Hungarian spec. chars: öüóőúéáűí ÖÜÓŐÚÉÁŰÍ");
Server side debug result: TestContent = null

More information in attached zip/docx file.

Urgent help needed !

Please, inform us what is the situation / limitations / possibile workarounds with different character encodings what we can use with CSHTML5 + WCF !


Thanks in advance,
Best Regards,
Péter
Attachments
CSHTML5 WCF Server side string content with extended ASCII characters.zip
(145.77 KiB) Downloaded 114 times

Sesztak
Posts: 172
Joined: Fri Jun 24, 2016 2:19 am

Re: serious bug with strings with non-basic ASCII content (like extended ASCII characters) !!

Postby Sesztak » Thu Jul 07, 2016 4:23 am

(in the meantime) We've tried to find a solution for the communication back and forth between WCF server and CSHTML5 client WITH Extended ASCII characters (like éáő, etc.):

Allways convert a string to UTF8 encoded byte [] manually before send to server (and convert back the byte [] to string at server), and vise versa.

Something like this:
public static string ByteArrayToStringUtf8(byte[] value)
{
UTF8Encoding encoding = new UTF8Encoding();
return encoding.GetString(value);
}

public static byte[] StringToByteArrayUtf8(string value)
{
UTF8Encoding encoding = new UTF8Encoding();
return encoding.GetBytes(value);
}



New bug happend :((( !! :
when we call the WCF server function:
public byte[] TestNonBasicASCIIcontentWithManualUTF8Encoding(byte[] TestContent)
{
...
}

the TestContent = null at the server side debugging,

Background information: no problem at simulator, problem allways in real enviroment: in browser .

Frankly speaking we bought your product because we trusted in it and never thought that so many BASIC/FUNDAMENTAL bugs we will find / we will meet.

So, let us recommend to your product manager: no more new features put in your roadmap, till you got rock solid fundamental for such a kind of functionality as above mentioned.
(or if your developer enviroment has some limitations -no problem, it's normal !-, but PLEASE write it down in the documentation)

Waiting for your kind reply,
Thanks in advance,
Best Regards,
Péter

Sesztak
Posts: 172
Joined: Fri Jun 24, 2016 2:19 am

Re: serious bug with strings with non-basic ASCII content (like extended ASCII characters) !!

Postby Sesztak » Thu Jul 07, 2016 4:55 am

Dear Support,
the the byte [] or any Type [] is supported in CSHTML5+WCF scenario ?

Because, we found an extremly labour sensitive solution regarding the above mentioned problem:
if we use the following signature:


[OperationContract]
List<byte> TestNonBasicASCIIcontentWithManualUTF8EncodingLISTversion(List<byte> TestContent);

The only important part: List<byte> , not byte [] !!

We can managed the communication of UTF8 strings between WCF service server and CSHTML5 client,
the only drawback of this solution: it's extremly labour sensitive / lot of manual work:

something like this:

string sTest = "Péter Pál common Hungarian spec. chars: öüóőúéáűí ÖÜÓŐÚÉÁŰÍ";
byte[] sutf8 = StringToByteArrayUtf8(sTest);
ArrayOfUnsignedByte aoub = new ArrayOfUnsignedByte();
for (int i = 0; i < sutf8.Length; i++)
{
aoub.Add(sutf8[i]);
}
var response = _kliens.TestNonBasicASCIIcontentWithManualUTF8EncodingLISTversion(aoub);
byte[] revertedBytes = new byte[response.Count];
for (int i = 0; i < revertedBytes.Count(); i++)
{
revertedBytes[i] = response.ElementAt(i);
}

string reConvert = ByteArrayToStringUtf8(revertedBytes);

Is there any quicker/easier solution ?

Thanks in advance,
Péter

JS-Support @Userware
Site Admin
Posts: 1093
Joined: Tue Apr 08, 2014 3:42 pm

Re: serious bug with strings with non-basic ASCII content (like extended ASCII characters) !!

Postby JS-Support @Userware » Fri Jul 08, 2016 3:10 am

Dear Péter,

Sorry for the inconvenience.

We have gathered several issues related to WCF, including the non-ASCII characters issue. We have in our short-term roadmap to greatly improve the browser-based WCF engine and plan to do so before getting out of the Beta phase in the coming weeks.

As your issue is urgent, we are going to look into it immediately. I will keep you updated.

Thank you for your patience as we fine-tune the product, and sorry again for the inconvenience.

Regards,
JS-Support

Sesztak
Posts: 172
Joined: Fri Jun 24, 2016 2:19 am

Re: serious bug with strings with non-basic ASCII content (like extended ASCII characters) !!

Postby Sesztak » Fri Jul 08, 2016 4:06 am

Dear JS-Support,

Thanks for your empathy & commitment to put it on the top of the todo list.

If you need any help (to test, more background information, etc.), just mention.

Really, really waiting for your solution,
Thanks in advance,
Best Regards,
Péter

JS-Support @Userware
Site Admin
Posts: 1093
Joined: Tue Apr 08, 2014 3:42 pm

Re: serious bug with strings with non-basic ASCII content (like extended ASCII characters) !!

Postby JS-Support @Userware » Fri Jul 08, 2016 7:13 am

Dear Péter,

Here is an update on the investigation.

The issue seems to be due to a bug in the XmlSerializer, which is used to create the SOAP message to send to the server.

We have managed to isolate the bug with the following simple client-only code (no WCF is involved in the code below):

Code: Select all

var testClassToSerialize = new TestClassToSerialize()
{
    Value = "donnée"
};
var serializer = new XmlSerializer(typeof(TestClassToSerialize));
var stream = new MemoryStream(); serializer.Serialize(stream, testClassToSerialize);
stream.Seek(0, SeekOrigin.Begin);
var reader = new StreamReader(stream);
var serializedXml = reader.ReadToEnd();
MessageBox.Show(serializedXml);


We are looking at how to fix it. What we are doing is using the Chrome Developer Tools to do step-by-step on the JavaScript code to see where the issue occurs.

Thanks.
Regards,
JS-Support

JS-Support @Userware
Site Admin
Posts: 1093
Joined: Tue Apr 08, 2014 3:42 pm

Re: serious bug with strings with non-basic ASCII content (like extended ASCII characters) !!

Postby JS-Support @Userware » Fri Jul 08, 2016 10:56 am

Dear Péter,

OK, the issue has now been fixed in Beta 8.4, available at:

http://forums.cshtml5.com/viewtopic.php?f=6&t=5498

Can you please confirm that it fixes the issues that you have encountered regarding encoding in WCF?

Thank you.
Regards,
JS-Support

Sesztak
Posts: 172
Joined: Fri Jun 24, 2016 2:19 am

Re: serious bug with strings with non-basic ASCII content (like extended ASCII characters) !!

Postby Sesztak » Fri Jul 08, 2016 11:28 am

Great ! - You are lightning fast !

So, actually I'm at my Mac but I will check it within 1 - 2 hours with an other Windows laptop + TeamView to reach our server.

I'll be back soon,
In the meantime : thanks in advance,
Best Regards,
Péter

Sesztak
Posts: 172
Joined: Fri Jun 24, 2016 2:19 am

Re: serious bug with strings with non-basic ASCII content (like extended ASCII characters) !!

Postby Sesztak » Sun Jul 10, 2016 2:21 am

Dear JS-Support,

(CSHTML5 v8.4 installed, WCF server rebuilded, client side service reference updated, client code rebuilded)

1.) WCF method call with extended-ASCII string content:

interface:
[OperationContract]
string TestNonBasicASCIIcontentExempliGratiaExtendedASCIIchars( string TestContent);


Server side implementation:
public string TestNonBasicASCIIcontentExempliGratiaExtendedASCIIchars(string TestContent)
{
// echo back :
return "server response: " + TestContent;
}

Client side call with extended-ASCII string content:
var response = _kliens.TestNonBasicASCIIcontentExempliGratiaExtendedASCIIchars("Péter Pál common Hungarian spec. chars: öüóőúéáűí ÖÜÓŐÚÉÁŰÍ");

Server side debug:
TestContent = "Péter Pál common Hungarian spec. chars: öüóőúéáűí ÖÜÓŐÚÉÁŰÍ"

Result: perfect / working as expected !

2., WCF method call with extended-ASCII characters in methode signature (e.g. parameter names, function name, type names !!!)
e.g.:
interface:
[OperationContract]
int TestNónBásicASCIIMethódeSignatőre(int TestNámber, int TestÖtherNámber);

Server side implementation:
public int TestNónBásicASCIIMethódeSignatőre(int TestNámber, int TestÖtherNámber)
{
return TestNámber + TestÖtherNámber;
}

Client side call:
var response = _kliens.TestNónBásicASCIIMethódeSignatőre(2, 3);

Client side Exception:
Error: Type 'System.Runtime.CompilerServices.CallSite`1' has not been defined.

second (3rd, 4th, etc) call from client side, exception again:
Error: A MSIL instruction of type invokecallsitetarget:int32(class [mscorlib]System.Func`3<class [System.Core]System.Runtime.CompilerServices.CallSite, object, int32>::Invoke, arg_A6_0:class [mscorlib]System.Func`3<class [System.Core]System.Runtime.CompilerServices.CallSite, object, int32>, arg_A6_1:CallSite, invokecallsitetarget:object(class [mscorlib]System.Func`5<class [System.Core]System.Runtime.CompilerServices.CallSite, object, int32, int32, object>::Invoke, ldfld:class [mscorlib]System.Func`5<class [System.Core]System.Runtime.CompilerServices.CallSite, object, int32, int32, object>(class [System.Core]System.Runtime.CompilerServices.CallSite`1<class [mscorlib]System.Func`5<class [System.Core]System.Runtime.CompilerServices.CallSite, object, int32, int32, object>>::Target, ldsfld:class [System.Core]System.Runtime.CompilerServices.CallSite`1<class [mscorlib]System.Func`5<class [System.Core]System.Runtime.CompilerServices.CallSite, object, int32, int32, object>>('<>o__33'::<>p__0)), ldsfld:class [System.Core]System.Runtime.CompilerServices.CallSite`1<class [mscorlib]System.Func`5<class [System.Core]System.Runtime.CompilerServices.CallSite, object, int32, int32, object>>[exp:CallSite]('<>o__33'::<>p__0), callgetter:object(class [CSharpXamlForHtml5]System.ServiceModel.ClientBase`1<class KasszaWEB_Kliens.ServiceReference1.IServiceKassza>::get_Channel, ldloc:ServiceKasszaClient[exp:class [CSharpXamlForHtml5]System.ServiceModel.ClientBase`1<class KasszaWEB_Kliens.ServiceReference1.IServiceKassza>](this)), ldloc:int32(TestNámber), ldloc:int32(TestÖtherNámber))) could not be translated.

So, tosummarize:
-extended ascii string content: ok,
-methode signatures with extended ascii characters : client side exception.

One more info regarding extened ASCII chars in custom Types names, like: public class TéstClássWithExtendedASCIIchars
(see the 'é' and 'á' chars in type name !)

if we try to call such a methode (e.g. extended ascii chars in function parameter type name or in return type name):

[OperationContract]
TéstClássWithExtendedASCIIchars TestMetodWithCustomTypesWithExtenedASCIIcharsInName(TéstClássWithExtendedASCIIchars parameter);

We have got client exception:
"Error: Memoized value is undefined"

So, waiting for your kind reply,
Best Regards,
Péter
ps:
background info about extened ASCII chars in custom Types names:
class definition:
[Serializable()]
[DataContract(IsReference = true)]
public class TéstClássWithExtendedASCIIchars
{
[DataMember]
public int SomeTestProperty { get; set; }
}

interface:
[OperationContract]
TéstClássWithExtendedASCIIchars TestMetodWithCustomTypesWithExtenedASCIIcharsInName(TéstClássWithExtendedASCIIchars parameter);

server side implementation:
public TéstClássWithExtendedASCIIchars TestMetodWithCustomTypesWithExtenedASCIIcharsInName(TéstClássWithExtendedASCIIchars parameter)
{
return new TéstClássWithExtendedASCIIchars() { SomeTestProperty= parameter.SomeTestProperty + 1 };
}


client side call -where we have got exception:
var response = _kliens.TestMetodWithCustomTypesWithExtenedASCIIcharsInName(new TéstClássWithExtendedASCIIchars() { SomeTestProperty = 14 });

Important: everything works perfectly in simulator, problem only in real browser + real WCF server (IIS hosted).

JS-Support @Userware
Site Admin
Posts: 1093
Joined: Tue Apr 08, 2014 3:42 pm

Re: serious bug with strings with non-basic ASCII content (like extended ASCII characters) !!

Postby JS-Support @Userware » Sun Jul 10, 2016 3:09 am

Thank you Péter.

I am glad that the issue about non-ASCII characters in passed variables during WCF calls is now fixed.

We are going to look into the issue on non-ASCII characters is method names and signatures. I will keep you updated asap.

Thanks.

Regards
JS-Support

Sesztak
Posts: 172
Joined: Fri Jun 24, 2016 2:19 am

Re: serious bug with strings with non-basic ASCII content (like extended ASCII characters) !!

Postby Sesztak » Mon Jul 11, 2016 1:13 am

Dear JS-Support,

Another acpect: Why the bug with non-ASCII characters with custom types is very important ?

(
like: TéstClássWithExtendedASCIIchars TestMetodWithCustomTypesWithExtenedASCIIcharsInName(TéstClássWithExtendedASCIIchars parameter);
)

Based on our tests:
If you have just one such a methode signature, this will kill all the other methodes as well !!! !!!

e.g. if you have 49 methodes with types with basic-ascii chars only, and you have 1 function with extended-ascii chars in type name:
all the 50 methodes will faulted bacause of 1 methode with.

So, it's very strange and annoying.

Really waiting for your urgent help,
Thanks in advance,
Best Regards,
Péter

Sesztak
Posts: 172
Joined: Fri Jun 24, 2016 2:19 am

Re: serious bug with strings with non-basic ASCII content (like extended ASCII characters) !!

Postby Sesztak » Mon Jul 11, 2016 3:31 am

Dear JS-Support,

Another 3rd aspect: Why the bug with extended-ASCII characters with custom types is very important ? :

We have a lot (huge number of) EXSISTING classes with öüóőúéáűí characters in the class/property/field/event names and it takes enormous efforts to us to translate these source codes to basic-ascii character version only.

(another big problem: we have a lot of data persisted already by with öüóőúéáűí characters in names of classes/properties/fields/events)

This is why we really-really-urgently-waiting for your kind reply to eliminate this bug !

Thanks in advance,

Best Regards,
Péter

Sesztak
Posts: 172
Joined: Fri Jun 24, 2016 2:19 am

Re: serious bug with strings with non-basic ASCII content (like extended ASCII characters) !!

Postby Sesztak » Tue Jul 12, 2016 12:38 am

Dear JS-Support,
Any estimated progress ?

Thanks in advance,
Péter

JS-Support @Userware
Site Admin
Posts: 1093
Joined: Tue Apr 08, 2014 3:42 pm

Re: serious bug with strings with non-basic ASCII content (like extended ASCII characters) !!

Postby JS-Support @Userware » Tue Jul 12, 2016 5:17 am

Thanks Péter.

We are looking into the remaining issue about non-ASCII characters in wcf method names. I will keep you updated asap. I hope we can fix it within a few days.

Thanks.
Regards,
JS-Support

Sesztak
Posts: 172
Joined: Fri Jun 24, 2016 2:19 am

Re: serious bug with strings with non-basic ASCII content (like extended ASCII characters) !!

Postby Sesztak » Tue Jul 12, 2016 5:40 am

Dear JS-Support,
Thanks in advance !

We are urgently waiting for your solution (background info: we had to stop our development temporarily till you should fix the bug as we do not want to re-write our hundreds of such a classes. Frankly speaking, it should be a kind of impossible mission within the available time frame from our point of view).

Please, take care about the following: check all the parts of the full signature of the methodes.
Please, pay special attention to passed parameter custom Types and return Types with extended ascii characters in their names.

(e.g.:
List<Pokémon> GetAll () {...}

or

Résumé Get (Pokémon _pokémon) {...}

)

Waiting for you kind reply,
Br,
Péter

JS-Support @Userware
Site Admin
Posts: 1093
Joined: Tue Apr 08, 2014 3:42 pm

Re: serious bug with strings with non-basic ASCII content (like extended ASCII characters) !!

Postby JS-Support @Userware » Tue Jul 12, 2016 5:53 am

Ok, thanks. I hope in the meantime you can at least work with the Simulator?

Sesztak
Posts: 172
Joined: Fri Jun 24, 2016 2:19 am

Re: serious bug with strings with non-basic ASCII content (like extended ASCII characters) !!

Postby Sesztak » Tue Jul 12, 2016 6:20 am

Sorry if I've been mistaken in advance but if I remember correctly:
we can not use your simulator at this stage of our development,
because we store a lot of settings at client side with IsolatedStorageSettings which is not available at Simulator -m'I right?

Another aspect: frankly speaking we have an experience: generally speaking a lot of things which are works perfectly under Simulator we are not 100% sure that will works seamlessly in real browser enviroment.
This is the reason why we are working the following way actually:
-normally we use real browser enviroment (Chrome),
-and if some strange happens: we use the cripped version of our software to debug&fix the problem with your Simulator.

So, thanks again in advance,
Best Regards,
Péter


Return to “Bug Reports”

Who is online

Users browsing this forum: No registered users and 3 guests

 

 

cron