Compiling the generated code

This section describes how to compile the generated code for C# and VB.NET, which references to add and how to use it in your own projects.

Compiling

The easiest way to compile the generated code is to load the generated Visual Studio project file(s) into Visual Studio or another IDE which can read these files and compile the project. The generated Visual Studio.NET projects by default have the proper references set up.

If you're upgrading to a newer version of LLBLGen Pro, it's recommended to check whether your project indeed references the correct runtime libraries, as Visual Studio sometimes may point to previous versions if they're still installed on your system. After you have generated the code and checked whether the right references are available in your Visual Studio project, you can compile the code into a working assembly. This assembly can then be referenced from your business logic project and other projects which want to use the generated functionality.

Nuget

Most assemblies are available on Nuget as well as shipped with the designer installer. With every new build of the installer we ship, we also make sure the assemblies on nuget will be updated.

Please use the URLs below for visiting the package pages on nuget:

• https://www.nuget.org/packages/SD.LLBLGen.Pro.ORMSupportClasses/
• https://www.nuget.org/packages/SD.LLBLGen.Pro.ORMSupportClasses.Web/
• https://www.nuget.org/packages/SD.LLBLGen.Pro.DQE.Access/
• https://www.nuget.org/packages/SD.LLBLGen.Pro.DQE.DB2/
• https://www.nuget.org/packages/SD.LLBLGen.Pro.DQE.Firebird/
• https://www.nuget.org/packages/SD.LLBLGen.Pro.DQE.MySql/
• https://www.nuget.org/packages/SD.LLBLGen.Pro.DQE.OracleMS/
• https://www.nuget.org/packages/SD.LLBLGen.Pro.DQE.OracleODPNET/
• https://www.nuget.org/packages/SD.LLBLGen.Pro.DQE.PostgreSql/
• https://www.nuget.org/packages/SD.LLBLGen.Pro.DQE.Spanner/
• https://www.nuget.org/packages/SD.LLBLGen.Pro.DQE.SqlServer/

Dependencies

The DQE packages come with a single DLL, the DQE dll, and have a dependency on the ORMSupportClasses package. The ORMSupportClasses package contains both the .NET 4.5.2+ build and the .NET Standard 2.0+ build.

The DQE dlls don't depend on any ADO.NET provider assembly as they all use the .NET DbProviderFactory system and don't need the using project to reference an ADO.NET provider.

The ADO.NET provider has to be present on the system. On .NET Framework a valid factory definition in either machine.config or in the application's .config file has to be present. Most ADO.NET provider installers take care of that for you. Additionally you can use the RuntimeConfiguration system. The RuntimeConfiguration system is required for .NET Standard as there's no machine.config on .NET Standard/core.

Google Cloud Spanner and DbProviderFactory

If you're using Google Cloud Spanner and your project uses .NET Framework you have to specify the DbProviderFactory using the RuntimeConfiguration to configure the DbProviderFactory at runtime. See the Google Cloud Spanner specific features section for an example how to do that.

.NET Core, what to use?

If you're confused about .NET Standard, .NET Framework and .NET Core, please read this article by Microsoft explaining the relationships. In short, use the .NET Framework build for .NET Framework, and use the .NET Standard build for .NET Core. See for more information about the .NET Standard build of the LLBLGen Pro Runtime framework .NET Framework vs. .NET Standard.

SQL Server: Microsoft.Data.SqlClient or System.Data.SqlClient

There are two ADO.NET providers for SQL Server: the original System.Data.SqlClient and the new Microsoft.Data.SqlClient. If you're using .NET Framework and our runtime, by default the System.Data.SqlClient is used. If you want to use Microsoft.Data.SqlClient instead, you have to configure the DbProviderFactory using the RuntimeConfiguration system as the DbProviderFactory of Microsoft.Data.SqlClient isn't registered with the machine.config.

If you're using .NET Core / .NET Standard it's recommended to use Microsoft.Data.SqlClient if you want to use the latest features of SQL Server, like e.g. always encryption. As the LLBLGen Pro Runtime Framework on .NET Standard/Core always requires you to register the DbProviderFactory through the RuntimeConfiguration system, you can specify the DbProviderFactory of Microsoft.Data.SqlClient there instead of the one from System.Data.SqlClient.

Adapter and Google Cloud Spanner

For Adapter, the generated Database specific project requires a reference to the Google Cloud Spanner Data nuget package. This is essential as the generated code uses a type from that package to implement query batching. SelfServicing doesn't support query batching so it doesn't require the reference to the ADO.NET provider package.

Available assemblies

Below a brief description of each runtime library assembly is given and when it should be referenced.

SD.LLBLGen.Pro.ORMSupportClasses assembly

LLBLGen Pro ships with two versions of this assembly, one general assembly compiled against .NET 4.5.2, and one compiled against .NET Standard 2.0+ Both assemblies are called SD.LLBLGen.Pro.ORMSupportClasses.dll. The .NET Standard one is located in the CompiledRuntimeLibraries\Netstandard2.0 folder. The ORMSupportClasses assembly is referenced by all generated code projects, and you also need to reference it from any project which uses the classes from the generated code. This assembly contains the LinqSupportClasses and QuerySpec code as well.

When you generate code for .NET Framework (.NET 4.5.2 or higher), the build against .NET 4.5.2 is referenced, and you should reference that one from your own code as well. When you generate code for .NET Standard 2.0+, the version from the .Netstandard2.0 folder is referenced, and you should reference that version in your code as well.

SD.LLBLGen.Pro.ORMSupportClasses.Web assembly

LLBLGen Pro ships with a specific ORM Support Classes assembly for web development: SD.LLBLGen.Pro.ORMSupportClasses.Web.dll. This assembly contains the DataSourceControls for two-way databinding in webforms. It also contains the designers for these controls; adding the controls from this assembly to the Visual Studio toolbox allows you to drag/drop DataSourceControls onto webforms. When your web application uses the LLBLGen Pro datasource controls, you have to reference this assembly from the Web project.

SD.LLBLGen.Pro.DQE.yourDatabase assembly

All SQL is generated by a Dynamic Query Engine or DQE in short. These engines are database specific and each supported database has its own assembly: SD.LLBLGen.Pro.DQE.yourdatabase.dll where yourDatabase is for example SqlServer, Oracle, Firebird etc.

LLBLGen Pro ships with two versions of this assembly per database: one compilied against .NET 4.5.2 and one against .NET Standard 2.0+, except for the databases which aren't supported on .NET Standard. See Databases supported on .NET Standard for details. The .NET Standard one is located in the CompiledRuntimeLibraries\Netstandard2.0 folder. The assembly compiled against .NET Framework (.NET 4.5.2) references the ORM Support classes assembly built against .NET Framework as well. The assembly compiled against .NET Standard 2.0+ references the ORM Support classes assembly built against .NET Standard.

The DQE assembly has to be referenced in the generated code project for SelfServicing and the database specific project of Adapter. You only need to reference the DQE assembly of the database types which are used in your LLBLGen Pro project: e.g. if your project in the LLBLGen Pro designer targets SQL Server, you only need to reference the SQLServer DQE assembly. 

SD.LLBLGen.Pro.ODataSupportClasses assembly

LLBLGen Pro ships with full support for WCF Data Services, the OData implementing framework by Microsoft. To create a WCF Data Service service using the generated code, you have to reference this assembly in your project which implements your Data Service class. .NET 4.0 or higher specific. The ODataSupportClasses are compiled against the WCF Data Services Server assembly available from nuget.

(Optional) Type converter assemblies

If you're using a custom type converter in your project, you have to add a reference to that type converter assembly which contains the type converter(s) used. In SelfServicing, you reference this assembly in the single generated code project, in adapter you reference this assembly in the DBSpecific project. LLBLGen Pro doesn't require a type converter dll for the built-in system type converters. 

DbProviderFactory configuration

LLBLGen Pro uses the DbProviderFactory system of .NET. For .NET Framework, in general installers for each ADO.NET provider make sure the DbProviderFactory is registered in machine.config. It's not enough to reference an ADO.NET provider package from nuget, you have to use an installer. For PostgreSql, Npgsql provides this installer on GitHub in the Releases section.

For Google Cloud Spanner, you always have to use the Runtime Configuration system to setup the DbProviderFactory. See the Google Cloud Spanner specific features section for an example how to do that.

.NET Standard 2.0+

If you're targeting .NET Standard 2.0+, you have to specify the DbProviderFactory to use manually through code, as there's no machine.config file on .NET Standard. See RuntimeConfiguration - Dynamic Query Engine configuration for more information.

Using the compiled assembly/ies in your own projects

When compilation of the generated code was successful, you can reference the compiled dll from your project, which holds the code using the generated classes, or reference the generated code projects directly. Furthermore, you have to copy the generated app.config file to the executable project which references (indirectly perhaps via another assembly) the generated code.

Connection Strings

A .config file (app.config or web.config) can have a separate connection strings section in which you can store the connection strings. A connection string specified in the ConnectionStrings section in the config file is read first. If a connection string with the name specified in the generated code is found there, that connection string is used. If it's not found, the appSettings section is consulted.

.NET Standard 2.0+

If you're using the .NET Standard 2.0+ build of the runtime, there's no .config file support and you have to use the RuntimeConfiguration system to specify the connection strings to use in your application. To learn what your connection string looks like and what key it should us, consult the generated app.config file.

Requesting the Runtime libraries build number and version number

You can request the version of the runtime libraries you're currently using in your code using:

string version = SD.LLBLGen.Pro.ORMSupportClasses.RuntimeLibraryVersion.Version + "." + 
                    SD.LLBLGen.Pro.ORMSupportClasses.RuntimeLibraryVersion.Build;

Dim version As String = SD.LLBLGen.Pro.ORMSupportClasses.RuntimeLibraryVersion.Version & "." & _ 
                            SD.LLBLGen.Pro.ORMSupportClasses.RuntimeLibraryVersion.Build

The runtime libraries also use a file version attribute, which is visible when you rightclick in windows explorer on the assembly dll and select 'Properties' and after that view the Version tab. This version has the following format: 5.x.y, where x is the minor version number, e.g. 2, and y is the revision number of the LLBLGen Pro build. LLBLGen Pro uses SemVer versioning, starting with v5.0