0

Using .NET 5, I have two Lists of the same class List. One was generated from Entity Framework from a SQL database and the other using Oracles DataManagedAccess library (if it matters) from a Oracle database. At this point, per what VS debugger shows, the strings in question are correct.

            foreach (var PairedCustomer in PairedCustomers)
            {
                bool MakeProp = false;
                //compare properties we care about (defined in mapping)
                foreach (string prop in PropertiesWeCareAbout)
                {
                    string tProp = PairedCustomer.TargetCustomer.GetType().GetProperty(prop).GetValue(PairedCustomer.TargetCustomer, null).ToString(); 
                    string dProp = PairedCustomer.DCustomer.GetType().GetProperty(prop).GetValue(PairedCustomer.DCustomer, null).ToString();

What the issue is, in the above code "PairedCustomer.TargetCustomer" has a string value in the object as "für Fischerei" however, the tProp value is showing up as: "f?r Fischerei". It does this with all umlaut and similar characters but only for the List that came from Oracle. Why does it appear correct in the List (via VS debugger), but is replaced with ? when using reflection (Yes... I hate using reflection, but I don't have a better way at the moment).

enter image description here

Joshua Fellers
  • 111
  • 3
  • 11
  • You need to use `Encoding`, if you are trying to print in log file or console, you need to do `Console.OutputEncoding = System.Text.Encoding.UTF8;` , see SO [answer](https://stackoverflow.com/questions/14057434/how-can-i-transform-string-to-utf-8-in-c) – Anand Sowmithiran May 02 '22 at 11:51
  • Can you explain how you observe the mangled string? Are you displaying it somewhere, like in a web page, desktop form, console window? If not, can you debug the code and see, using the debugger, the property on the object in the list being OK but the variable you stored the value into, obtained using reflection, is wrong? – Lasse V. Karlsen May 02 '22 at 11:51
  • And where does `tProp` values come from? I highly doubt the reflection code is the culprit here so most likely the values are already mangled, can you check the properties of that `TargetCustomer` object and check whether they are OK or already mangled? – Lasse V. Karlsen May 02 '22 at 11:53
  • I added a image to show what I see. "Test" is from: string Test = PairedCustomer.TargetCustomer.BusinessName; Again - appears fine, until Reflection. – Joshua Fellers May 02 '22 at 11:54
  • And `prop` is `BusinessName`? – Lasse V. Karlsen May 02 '22 at 11:55
  • Correct - Prop is businessname – Joshua Fellers May 02 '22 at 11:55
  • What does `string tProp = PairedCustomer.TargetCustomer.GetType().GetProperty(prop).GetValue(PairedCustomer.TargetCustomer, null).GetType().Name;` evaluate to? – Lasse V. Karlsen May 02 '22 at 11:57
  • It evaluates to "String" – Joshua Fellers May 02 '22 at 11:59
  • OK, then I'm stumped, all the assumptions I had seems to be invalid. This is indeed very strange. – Lasse V. Karlsen May 02 '22 at 11:59
  • There's no "temporal code" in that property, so that if you just read the value twice it will be mangled the second time? I assume not since you probably didn't have that test variable there to begin with. – Lasse V. Karlsen May 02 '22 at 12:00
  • I have a feeling somehow this is Oracle's fault (I loathe Oracle) but I am not sure how. No I added the test trying to figure this out. The goal here to compare values from one database to another from a configurable map. I mean... if I have to, I can hard code all the options, just more code maintenance down the road. Reflection is reputably slow... but I have not seen it. I have tried converting all the bytes to unicode, to ascii, etc in a variety of ways - always the same. – Joshua Fellers May 02 '22 at 12:07

1 Answers1

0

I finally solved it. The Oracle response is using extended Ascii characters. Solution was to convert the value using encoding: Encoding.GetEncoding(1252).GetString(tProp.Select(c => (byte)c).ToArray());

Joshua Fellers
  • 111
  • 3
  • 11