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.

note Note:
.NET 3.0 uses the .NET 2.0 framework and CLR internally so the .NET 2.0 builds of our code are also the ones to use for .NET 3.0. .NET 3.5 is also mainly .NET 2.0 based, so our .NET 2.0 dlls are fully usable on .NET 3.5 without issues.

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.
SD.LLBLGen.Pro.ORMSupportClasses assembly
LLBLGen Pro ships with three versions of this dll, one for .NET 1.0, one for .NET 1.1 and one for .NET 2.0/3.0/3.5. The version for .NET 2.0/3.0/3.5 is compiled against the latest .NET 2.0 public available build. If you are using an IDE like Visual Studio.NET v2003 or Borland C# builder, you are using .NET 1.1, and you have to use the .NET 1.1 version. If you are using Visual Studio.NET v2002, you are using .NET 1.0, and you have to use the .NET 1.0 version. If you're using VS.NET 2005 or VS.NET 2008, you can use the .NET 2.0 version. Which file to select for which version is easy: the .NET version is included in the filename: SD.LLBLGen.Pro.ORMSupportClasses.NETxy.dll for normal .NET applications, or SD.LLBLGen.Pro.ORMSupportClasses.CFxy.dll for Compact Framework applications.

For the compact framework, you've to reference the CF10 version in case you're using CompactFramework .NET 1.0, the CF20 version for CompactFramework .NET 2.0 (shipped with VS.NET 2005) and the CF35 version for CompactFramework .NET 3.5 (shipped with VS.NET 2008).

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.NETxy.dll where yourDatabase is for example SqlServer, Oracle, Firebird etc. LLBLGen Pro ships with three versions of this dll per database, one for .NET 1.0, one for .NET 1.1 and one for .NET 2.0+, unless a given database isn't supported on a given .NET platform, for example Firebird is only supported on .NET 1.1 and .NET 2.0+, Sybase ASA is only supported on .NET 2.0+. For the Compact Framework .NET 1.0, 2.0 and 3.5, there's also a build of the SqlServer DQE for these platforms.

note Note:

.NET 2.0+, MySql specific: Starting with v2.6, driver build 06262009, the MySql Driver, templates and DQE use the ADO.NET DbProviderFactory to communicate with the ADO.NET provider for MySql from CoreLab or DevArt. This has the consequence that you don't need to reference the MySql Direct provider from CoreLab or DevArt, however you have to install the provider on the target system your application will run on. This is documented in the MySql Direct provider documentation from CoreLab or DevArt, under the section 'Licensing'.

This change was necessary to provide support for the new CoreLab provider, which is now called DevArt's MySqlDirect, and also keep supporting customers who have purchased the CoreLab provider.

MySql specific: If you're using MySql, .NET 1.x and you're using v3.x of the CoreLab MySqlDirect provider instead of the v4 version, please reference the DQE dll for MySql from the MySqlDirectv355 folder in the DotNetxy folder of your .NET version in the RuntimeLibraries folder instead. This DQE is compiled against v3.55 of the CoreLab MySqlDirect provider. If you're using .NET 2.0 or higher, there's no need to do anything, see the note above.
Oracle10g ODP.NET specific: If you're using ODP.NET v10.1.0.4 instead of the newer v10.2, please reference the DQE dll for Oracle ODP.NET 10g v10.1 from the Oracle10gv10104 folder in the DotNetxy folder of your .NET version in the RuntimeLibraries folder instead. This DQE is compiled against v10.1.0.4 of the Oracle 10g ODP.NET provider. If you're using ODP.NET 11g, you should be able to use the normal ODP.NET 10g driver.
IBM DB2 specific: If you're using the IBM DB2 v8.1.2.1 provider instead of the newer v9.0.0.2, please reference the DQE dll for IBM DB2 v8.1.2.1 from the IBMDB2v8121 folder in the DotNetxy folder of your .NET version in the RuntimeLibraries folder instead. This DQE is compiled against v8.1.2.1 of the IBM DB2 provider.

The DQE assembly has to be referenced in the generated code project for SelfServicing and the DatabaseSpecific project of Adapter.
SD.LLBLGen.Pro.LinqSupportClasses.NET35 assembly
LLBLGen Pro v2.6 ships with full Linq support on .NET 3.5 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, 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 DbUtils for COM+ (SelfServicing), or the ComPlusAdapterContext class (Adapter).

This assembly is required in SelfServicing projects and in the DatabaseSpecific project of Adapter.
(Optional) The .NET data provider of the database type used.
These assemblies (if applicable) have to be referenced in the Selfservicing projects and 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.

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.

.NET 2.0 or higher: 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:

// C#
string version = SD.LLBLGen.Pro.ORMSupportClasses.RuntimeLibraryVersion.Version + "." + 
	SD.LLBLGen.Pro.ORMSupportClasses.RuntimeLibraryVersion.Build;
' VB.NET
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 (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: 2.6.08.mmdd, where mmdd is the date the assembly was released (mm for month, dd for day)
LLBLGen Pro v2.6 documentation. ©2002-2008 Solutions Design