How is encoding of strings determined in .NET?

Question

I am running the exact same code (and connection strings, etc.) on two different computer (fetched from source control).

The code queries a DB (using Dapper), and reads strings from it.

However, the behavior regarding accents is not the same.

On machine A, the DB string 'régime' is fetched as 'régime'

On machine B, the DB string 'régime' is fetched as 'r�gime' (U+FFFD).

The behavior seems to be determined at compile time (ie. if I compile the code on machine A, and run it on machine B, it reads the string correctly, and if I compile it on machine B and run it on machine A, it does not).

I am running out of ideas... Could someone point me in the right direction?

Answer 1

It turns out the two machines did not use the same version of the ADO Driver to connect to the database, off by one version.

The patch note for the new version reads:

None standard characters in DataProvider display question mark

Disabling 'Copy Local' for the reference allowed to get a consisted behavior for a single machine, no matter where the program was compiled.

Answer 2

From https://msdn.microsoft.com/en-us/library/system.globalization.cultureinfo.defaultthreadcurrentculture(v=vs.110).aspx

In the .NET Framework 4 and previous versions, by default, the culture of all threads is set to the Windows system culture

It goes on to say that in versions after 4 the app domain default culture is null. Followed by this:

Unless it is set explicitly, the value of the DefaultThreadCurrentCulture property is null, and the culture of threads in an application domain that have not been assigned an explicit culture is defined by the default Windows system culture.

Meaning if you haven't explicitly set the app domain's default culture, all threads inheriting that value will use the Windows System culture setting, regardless of .net framework version.

I suspect you did not explicitly define the culture for the thread in which problem operation runs.

In this case the culture for the thread is based on the Windows System Culture defined on the machine where it was compiled.

Try both locating the system culture setting on the two machines in question, and explicitly defining the culture for the thread.

Specific to the ENCODING part of your question:

U+FFFD � REPLACEMENT CHARACTER used to replace an unknown, unrecognized or unrepresentable character

Key here being unrepresentable due to the culture setting.