.NET Full vs. .NET standard

The LLBLGen Pro Runtime framework supports both .NET full (.NET 4.5.2 or higher) and .NET Standard 2.0. The LLBLGen Pro Runtime Framework build for .NET Standard 2.0 is the build to use for .NET Core 2.0+, Xamarin and other platforms other than .NET Full. 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.

Info

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.

Important!

When using .NET Standard be aware that there are no .config files: all configuration is done through code, using the RuntimeConfiguration system. This includes connection strings and other settings you might need at runtime.

Assembly location

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.

Features not supported in the .NET Standard build

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.

Databases supported on .NET Standard

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, we'll add support for that database in an update.

Important!

No ADO.NET provider is available by default, you have to add the nuget package for the particular ADO.NET provider you want to use yourself, in all cases, including SqlClient.

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.
  • Oracle, through the ODP.NET managed provider core, v2.18+.
  • Google Cloud Spanner, through the Google Cloud Spanner Data package.
Info

The ORMSupportClasses assembly build for .NET Standard has a dependency on SqlClient. This dependency is because of the SqlAzure transient error recovery strategy class which uses SqlClient types. This means that even if you're not using SQL Server, this dependency will pull the SqlClient package as a dependency into your project. This dependency is currently unavoidable as the location of the class can't be changed and the dependency can't be made optional.