Generated code - Compiling the code
Preface
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.
Note: |
If you're using LLBLGen Pro with WCF RIA services, this
section applies to the generated code project(s) and the domain
service project, not for the Silverlight application, as the
Silverlight application doesn't use the generated entity classes so
you don't need to reference any of the runtime framework assemblies in the Silverlight application of your WCF RIA
services solution. |
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.
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 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.
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 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.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 VS.NET 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.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
database specific 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
database
generic generated VS.NET project.
You also have to reference this assembly in a project where you want to
write linq queries which use the generated entity classes.
SD.LLBLGen.Pro.QuerySpec assembly
LLBLGen Pro ships with its own query API, called
QuerySpec. QuerySpec
is a highly expressive query system build on top of the core lower-level
query API. QuerySpec's logic is defined in the assembly
SD.LLBLGen.Pro.QuerySpec.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
database
generic generated VS.NET project.
You also have to reference this assembly in a project where you want to
write and fetch QuerySpec queries which use the generated entity classes.
SD.LLBLGen.Pro.RiaSupportClasses assembly
LLBLGen Pro ships with full support for WCF Ria Services, a framework by
Microsoft to create rich silverlight applications with a service based
server tier. To create a service for WCF Ria Services using the generated
code, you have to reference this assembly in your project which implements
your DomainService class. .NET 4.0 or higher specific.
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.
(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. 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.
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.7.0.0, Culture=neutral, PublicKeyToken=3750abcc3150b00c" />
</DbProviderFactories>
</system.data>
NOTE: Be sure the version of the ADO.NET provider you use for Firebird
matches the version specified. In the example above the version is
'2.7.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>
NOTE: Be sure the version of the ADO.NET provider you use for Npgsql
matches the version specified. In the example above the version is
'2.0.4.0'. Don't change the invariant string, that string has to be 'Npgsql'.
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. 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
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 build number 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 and select 'Properties' and after that view the Version tab. This
version has the following format: 3.5.yy.mmdd, where yy is the last two
digits of the year, e.g. 12 and mmdd is the date the assembly was released (mm for month, dd for day)