The LLBLGen Pro Runtime framework supports both .NET full (.NET 4.5.2 or higher) and .NET Standard 2.0. Not all databases are supported on .NET Standard 2.0 and therefore not all DQEs are available for .NET Standard 2.0. Almost all features are supported on both .NET Full and .NET Standard, with a few differences, which are described below.
For more information about .NET Standard and how it relates to .NET Full and .NET Core, please see the Microsoft documentation section on .NET Standard.
It's recommended to use the .NET Full build of the LLBLGen Pro runtime framework on .NET Full and the .NET Standard build on .NET Core, even though .NET Full supports .NET Standard as well. If you're referencing the runtime libraries through nuget, this is automatic.
The .NET Full builds of the LLBLGen Pro Runtime Framework assemblies are found in the folder: llblgen pro installation folder\Frameworks\LLBLGen Pro\RuntimeLibraries\CompiledRuntimeLibraries. The .NET Standard builds can be found in the folder llblgen pro installation folder\Frameworks\LLBLGen Pro\RuntimeLibraries\CompiledRuntimeLibraries\Netstandard2.0.
It's recommended however you use the Nuget packages. See for more information Compiling the code.
Almost all features are supported on .NET Standard, however there are some differences and caveats, which are described below.
- Configuration of certain parts of the runtime has to be done through the RuntimeConfiguration system, instead of the .config file.
- Auto-discovery of Dependency Injection types in assemblies from disk and the current appdomain isn't available on .NET Standard. Instead you always have to specify the particular assembly/assemblies directly which is then probed for instance types. This is done through the RuntimeConfiguration system.
- Due to the fact that
System.Type(through its runtime equivalent RuntimeType) in CoreCLR v2.0 isn't marked as Serializable, the data created by binary serializing entities, contains different data on .NET core than it does on .NET full, as we had to serialize type instances as strings (the full name of the type). This means that if you binary serialize entity graphs on .NET Core and deserialize them on .NET Full, it won't work. This is a limitation of .NET Core 2.0 and by design.
System.Transactions.TransactionScope, while supported by our code, won't work at runtime as it's not implemented in SqlClient on .NET core: it will throw an exception at runtime in SqlConnection. This is a limitation of .NET Core 2.0.
- BinarySerialization is there, but the support for serializable types in .NET core 2.0 is still low. It is likely you'll run into a type that's not serializable when using it. We tried to port our code to types which are serializable so the issues don't occur with types in our runtime but we can't guarantee that code which serializes properly on .NET full will serialize properly as well on .NET core 2.0. E.g. binary serializing a TypedList / TypedView based on a DataTable, and they contain a DBNull, will fail on .NET Core, because DBNull isn't serializable on .NET Core. This is a limitation in .NET Core 2.0.
- Not all databases are supported on .NET Standard as not all databases have a usable ADO.NET Provider for .NET Standard. See below for details.
All databases supported by the LLBLGen Pro Runtime framework are supported on .NET Full. On .NET Standard not all databases have a usable ADO.NET provider so these databases are not supported. If a database receives a proper ADO.NET provider for .NET Standard, like Oracle, we'll add support for that database in an update.
The following databases are supported by the LLBLGen Pro Runtime Framework on .NET Standard 2.0:
- SQL Server, through Microsoft's own SqlClient package
- PostgreSql, through the Npgsql package
- Firebird, through Firebird Client package
- MySQL, through Devart's dotConnect for MySQL. The version required for .NET Standard/core isn't free, but there's no alternative. We can't use MySQL's own connector as it's GPL licensed.
- IBM DB2, through the IBM DB2 data server provider.