Generated code - Compiling the code

Preface

After you've generated code, you of course want to use the code in compiled form so you can reference it from another project and actually use it. 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.NET project file(s) into Visual Studio.NET or another IDE which can read these files and compile the project. This will automatically create a class library for you which you can use immediately. If you decide to construct the project manually, create a new library project and add all the generated classes to that project. The references you have to make are identical for VB.NET and C# and are described below.

The generated code references the following assemblies and you should add to your project references to these assemblies if they're not yet present. It's highly recommended to use the generated VS.NET projects which should automatically reference the correct assemblies. 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 VS.NET 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 VS.NET 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.

DbProviderFactory configuration

LLBLGen Pro v3 uses the DbProviderFactory system. This means that you don't need to reference the ADO.NET provider assembly in your generated code. In general the ADO.NET provider installation programs also install a definition of the ADO.NET provider's DbProviderFactory in the machine.config file of the .NET CLR used. There are two exceptions: Firebird and Postgresql. Please see the sections below for these specific databases and to setup the DbProviderFactory declaration for your own application.

It's required that the ADO.NET provider you're using is build against .NET 2.0 or higher, as it has to support the DbProviderFactory system, which was introduced in .NET 2.0.

Firebird

For firebird, please add to the .config file of your application the following lines:

<system.data>
	<DbProviderFactories>
		<!-- Firebird -->
		<add name="Firebird Client Data Provider" invariant="FirebirdSql.Data.FirebirdClient"
			description=".Net Framework Data Provider for Firebird"
			type="FirebirdSql.Data.FirebirdClient.FirebirdClientFactory, FirebirdSql.Data.FirebirdClient, Version=2.1.0.0, Culture=neutral, PublicKeyToken=3750abcc3150b00c" />
	</DbProviderFactories>
</system.data>

Be sure the version of the ADO.NET provider you use for Firebird matches the version specified. In the example below the version is '2.1.0.0'. Don't change the invariant string, that string has to be 'FirebirdSql.Data.FirebirdClient'.

PostgreSql (Npgsql)

For PostgreSql using Npgsql, please add to the .config file of your application the following lines:

<system.data>
	<DbProviderFactories>
		<!-- PostgreSql -->
		<add name="PostgreSql Client Data Provider" invariant="Npgsql"
			description=".Net Framework Data Provider for PostgreSql"
			type="Npgsql.NpgsqlFactory, Npgsql, Version=2.0.4.0, Culture=neutral, PublicKeyToken=5d8b90d52f46fda7" />
	</DbProviderFactories>
</system.data>

Be sure the version of the ADO.NET provider you use for Npgsql matches the version specified. In the example below the version is '2.0.4.0'. Don't change the invariant string, that string has to be 'Npgsql'.

SD.LLBLGen.Pro.ORMSupportClasses assembly

LLBLGen Pro ships with one version of this assembly, SD.LLBLGen.Pro.ORMSupportClasses.NET20.dll. This assembly is usable for all .NET versions supported: .NET2.0 or higher. 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.

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.NET20.dll where yourDatabase is for example SqlServer, Oracle, Firebird etc. LLBLGen Pro ships with one version of this assembly per database, which is usable for all .NET versions supported: .NET 2.0 or higher. The DQE assembly has to be referenced in the generated code project for SelfServicing and the DatabaseSpecific project of Adapter.

MySql specific: The DQE shipped with LLBLGen Pro for MySql can be used with MySqlDirect provider from CoreLab or from DevArt. 

SD.LLBLGen.Pro.LinqSupportClasses.NET35 assembly

LLBLGen Pro ships with full Linq support on .NET 3.5 or higher by using a Linq provider. This provider is defined in the assembly SD.LLBLGen.Pro.LinqSupportClasses.NET35.dll. When you generate code for .NET 3.5/VS.NET 2008 or .NET 4.0/VS.NET 2010, the generated code requires a reference to this assembly in the SelfServicing generated VS.NET project and in the Adapter DBGeneric generated VS.NET project.

System.EnterpriseServices assembly

This is an assembly of .NET and is necessary to compile the code since the generated code references COM+ specific features in the COM+ transaction variant and the ComPlusAdapterContext class (Adapter).

This assembly is required in SelfServicing projects and in the DatabaseSpecific project of Adapter. The DQE assemblies are compiled against a given version of the database specific ADO.NET provider. We try to keep this at the same version throughout an LLBLGen Pro version so users don't have to upgrade an ADO.NET provider if we ship a bugfixed set of runtime libraries. However, it can be you use a newer version of the ADO.NET provider of your database and this particular version for example doesn't work with the DQE because of assembly version mismatches. For these occasions we provide additional builds of our runtimes against different versions of the providers. These are located in general in subfolders in the RuntimeLibraries\DotNetxy\ folder.

(Optional) Type converter assemblies

If you're using a type converter in your project, you have to add a reference to the type converter assembly which contains the type converter(s) used, for example the SD.LLBLGen.Pro.TypeConverters.dll assembly in the TypeConverters folder in the LLBLGen Pro installation folder. In selfservicing, you reference this assembly in the single generated code project, in adapter you reference this assembly in the database specific project.

Compiling on the command line

If you want to compile the code from the command line, you have to follow similar steps. Be sure to specify the complete reference paths to the assemblies you have to reference. The VB.NET and C# compiler both have an option to recurse through folders, so you can include all generated source files in the build by specifying the option /recurse:*.cs for C# or /recurse:*.vb for VB.NET.

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. You have to reference the following assemblies in your project, and add Imports / using statements with the specified namespaces at the top of the code files which contain types defined in the generated code or in the ORM support classes library.

• SD.LLBLGen.Pro.ORMSupportClasses. See the remark about which version to select in the list above. Include Imports/using statements with the namespace SD.LLBLGen.Pro.ORMSupportClasses.
• SD.LLBLGen.Pro.LinqSupportClasses.NET35. Optional, for usage on .NET 3.5 and if the code was generated for .NET 3.5.
• System.EnterpriseServices. Optional. If you use ComPlus transaction functionality, you have to reference this assembly in your own code where you use the ComPlus transaction, because your class has to derive from ServicedComponent which is located in this assembly. If you do not use ComPlus transactions explicitly, you don't need a reference to this assembly. Include Imports/using statements with the namespace System.EnterpriseServices.
• System.Xml. Some new projects in VS.NET don't add a reference to System.Xml, while the reference is required if you reference the SD.LLBLGen.Pro.ORMSupportClasses assembly.

Furthermore, you have to copy the generated app.config file to the executable project which references (indirectly perhaps via another assembly) the generated code. If you are developing a web project, you have to copy the appSettings tag and its contents of generated app.config file to the web.config file of your application, inside the configuration tag. This will make sure the generated code will be able to read the connection string.

Connection Strings, .NET 2.0+ style

Starting with .NET 2.0, a .config file (app.config or web.config) can have a separate connection strings section in which you can store the connection string as well. This is supported by LLBLGen Pro. A connection string specified in the connection strings 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.

Requesting the Runtime libraries buildnumber and version number

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


The runtime libraries also use a file version attribute, which is visible when you rightclick in windows explorer on the assembly dll (one of the DQE assemblies or the ORM Support classes assembly) and select 'Properties' and after that view the Version tab. This version has the following format: 3.0.yy.mmdd, where yy is the last two digits of the year, e.g. 10 and mmdd is the date the assembly was released (mm for month, dd for day)