.NET Full vs .NET Standard 2.0

Posts   
 
    
Findev
User
Posts: 103
Joined: 08-Dec-2014
# Posted on: 20-Jul-2020 12:09:02   

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

daelmo avatar
daelmo
Support Team
Posts: 8245
Joined: 28-Nov-2005
# Posted on: 21-Jul-2020 08:43:26   

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 ?

David Elizondo | LLBLGen Support Team
Otis avatar
Otis
LLBLGen Pro Team
Posts: 39588
Joined: 17-Aug-2003
# Posted on: 21-Jul-2020 08:43:31   

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 sunglasses

Frans Bouma | Lead developer LLBLGen Pro
Findev
User
Posts: 103
Joined: 08-Dec-2014
# Posted on: 21-Jul-2020 08:53:52   

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 simple_smile

Findev
User
Posts: 103
Joined: 08-Dec-2014
# Posted on: 21-Jul-2020 08:58:18   

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 sunglasses

You mean the MS DTC? Nah, I don't have a use case for it simple_smile 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 simple_smile Will look into that now then.

Thank you!