Hi,

LLBLGen: 5.7.0

currently on 4.7.2. Thinking to slowly start preparing the project for .NET Core migration. For that plan is to start converting the 4.7.2 class libraries to .net standard 2.0 first and then the apps as the last step. Given ORM is an integral part, decided to start from it. Documentation https://www.llblgen.com/documentation/5.7/LLBLGen%20Pro%20RTF/NetFullvsNetstandard.htm mentions that for full framework it's recommended to use the full framework version of the LLBLGen runtime, thus I'm curious whether there are some gotchas I need to be aware of that would prevent from using the ORM as .net standard 2.0... and a follow up question about

System.Transactions.TransactionScope

(in docs "Features not supported" section) - quickly tested with full and 3.1 core console apps each creating local transaction scope and then calling into a code which is mimicking the service layer (.net standard 2.0 class lib) which also has transaction scope. Seems to work or have I, perhaps, overlooked something...?

Thank you!

P.S.: for .net core app testing tried with both Microsoft.Data.SqlClient.SqlClientFactory and System.Data.SqlClient.SqlClientFactory

Findev wrote:

...quickly tested with full and 3.1 core console apps each creating local transaction scope and then calling into a code which is mimicking the service layer (.net standard 2.0 class lib) which also has transaction scope. Seems to work or have I, perhaps, overlooked something...?

Could you please elaborate more on your test? Did you actually used the LLBLGen classes and instantiate a connection and do some DB transactiosn? Could you try the same with .net core 2.0/2.1 ?

TransactionScope relies on the ability of the ADO.NET provider to bump up the transaction to a distributed transaction if there are multiple connections, which relies on MS DTS and that's not implemented in the .NET core version of SqlClient. You might not run into this, but as it's a limitation we recommend to use the net fx version for net fx.

the differences between the builds for netstandard and netfx are minimal, they're mostly around config file usage and binary serialization, as well as type discovery for DI, which uses an appdomain on netfx and that's not possible on netstandard.

If you use RuntimeConfiguration to configure your application, including specifying which DI types you might use, avoid binary serialization, the transition should be smooth.

*edit heh 5 seconds apart

daelmo wrote:

Findev wrote:

...quickly tested with full and 3.1 core console apps each creating local transaction scope and then calling into a code which is mimicking the service layer (.net standard 2.0 class lib) which also has transaction scope. Seems to work or have I, perhaps, overlooked something...?

Could you please elaborate more on your test? Did you actually used the LLBLGen classes and instantiate a connection and do some DB transactiosn? Could you try the same with .net core 2.0/2.1 ?

Yeah, it is LLBLGen code inside the

 using (var scope = new TransactionScope())

I'm not much interested in the previous version of of .net core, thus didn't really do any tests with those

Otis wrote:

TransactionScope relies on the ability of the ADO.NET provider to bump up the transaction to a distributed transaction if there are multiple connections, which relies on MS DTS and that's not implemented in the .NET core version of SqlClient. You might not run into this, but as it's a limitation we recommend to use the net fx version for net fx.

the differences between the builds for netstandard and netfx are minimal, they're mostly around config file usage and binary serialization, as well as type discovery for DI, which uses an appdomain on netfx and that's not possible on netstandard.

If you use RuntimeConfiguration to configure your application, including specifying which DI types you might use, avoid binary serialization, the transition should be smooth.

*edit heh 5 seconds apart

You mean the MS DTC? Nah, I don't have a use case for it I don't use LLBLGen's DI or binary serialization if those are the things that one needs to opt-in. As for config - yeah, that is the one that seems to require some adjustments as I have several apps and all of them rely on LLBLGen reading the config automatically Will look into that now then.

Thank you!