Differences between Core and .net Framework in client charset (NLS_LANG) and unicode string read/write

[puma]

Hi,
i would like to understand why two identical applications written one in .net Core and one in .net framework running in the same pc (same client charset NLS_LANG=ITALIAN_ITALY.WE8MSWIN1252), accessing same oracle db (19.3.0.0 same NLS_CHARSET=AL32UTF8 ), in OCI mode (Direct=False) and with Unicode=False in connection string, acts totally differently writing and reading VARCHAR2 and CLOB in UTF8/Unicode chars (es japan arabic etc).

Net Core app luckily always writes non latin strings in VARCHAR and CLOB fields with right encoding. It always connect to the server with AL32UTF8 client encoding even if i set wrong client charset on purpose by registry, environment variable or by OracleGlobalization.SetApplicationInfo.

Net Framework app instead never write VARCHAR2 and CLOB in the right way (with all combination of NLS_LANG Direct or not) except if I set Unicode=True in connection string.

So there is a way to write unicode/utf8 chars without Unicode=True settings in net framework EF app? My goal is to avoid any characterset decoding and translation at server level.
Why net framework version of the driver it's so machine dependent and core the opposite? What i have to expect in net Core migration process of my solution?
I can expect any similar quick and easy AL32UTF8 connection for net framework EF driver?
thanks

[Shalex]

You are migrating from .NET Core to .NET Framework, aren't you?
Our provider is based on the Unicode implementation of the .NET Standard (.NET Core) functionality. Although .NET Framework and .NET Standard versions of the provider are compliant, .NET Framework is indeed more dependent on client encoding, and .NET Core can make conversions you do not control. Why don't you want to use "Unicode=true;" with .NET Framework?

[puma]

No, luckily we are migrating from .net Framework to .net Core in next months but the branch is not ready yet for production.
In the meanwhile our production apps are reporting several Oracle ORA-00600 errors, probably due to CLOB storing or charset conversion. Our .net Core beta app instead seems work properly in our developing environment (same db, different schema).
According with our DBA, we would like to exclude any charset conversion at server level to test if like that we can find a workaround for our issue and evaluate also performance. So there is a way to use our actual solution (.net EF Model) without server side charset conversion? Can .net framework driver be set to use AL32UTF8 client charset? All my tests in this way failed with wrong characters stored in tables.
thanks

[Shalex]

So there is a way to use our actual solution (.net EF Model) without server side charset conversion? Can .net framework driver be set to use AL32UTF8 client charset?

Please send us the following information:
a) a small test project with the corresponding DDL/DML script
b) specify your connection string (roughly, mark confidential information with asterisks)
c) the exact (xx.x) versions of your Oracle server and Oracle client
d) NLS_LANGUAGE, NLS_CHARACTERSET, and NLS_NCHAR_CHARACTERSET parameters of your Oracle server
e) NLS_LANG setting of your Oracle client (in the registry)