Breaking changes in LLBLGen Pro v5.7

No breaking changes were introduced in v4.0, v4.1, 4.2, 5.0, 5.1, v5.2, v5.3, v5.4, v5.5, v5.6 or v5.7

Breaking changes introduced in LLBLGen Pro v3.5

In v3.5, the following breaking changes are introduced with respect to NHibernate.

If you're using the type converter which was shipped with v3.x, your project won't load properly (missing type converter) when you load your project into LLBLGen Pro v3.5. This is caused by the fact that there's no type converter dll shipped for NHibernate anymore, as the dll had a dependency on the NHibernate dll with a specific version which made it cumbersome to use.

To solve this, you can do one of the following things:

• manually compile the NHibernate type converter sourcecode from the v3.5 sourcecode package (TypeConverters\Nhibernate folder) and place the type converter dll into the TypeConverters folder of v3.5, or use the sourcecode included in this manual.
• Copy the v3.1 typeconverter for NHibernate dll into the TypeConverters folder of v3.5.

Breaking changes introduced in LLBLGen Pro v3.1

In v3.1, a small number of breaking changes have been introduced for the supported O/R mapping frameworks. The changes specific for NHibernate are described below.

In v3.0, vs.net projects were named after the LLBLGen Pro project name. This has been changed, to make this consistent with the rest of the frameworks. Starting with v3.1, projects are named using the root namespace specified in the code generation dialog as the project name.

If your LLBLGen Pro project is called MyProject, and you specify as root namespace MyCompany.Foo, in v3.0, the vs.net projects were named MyProject.Model.csproj and MyProject.Persistence.csproj. In v3.1 they’re called MyCompany.Foo.Model.csproj and MyCompany.Foo.Persistence.csproj. This is a breaking change for existing projects, as the existing solutions refer to the old vs.net project files.

To make it easy: before generating code with v3.1, rename your vs.net projects generated with v3.0 after the root namespace specified, using the pattern: rootnamespace.Model.cs/vbproj and rootnamespace.Persistence.cs/vbproj. Do this in vs.net so the .sln file is updated automatically. After that, generate code with v3.1

If you don’t want this: set the parameter useRootNameSpaceForProjectName to false (it was set to false in v3.0’s preset, it’s now set to true by default) for the vs.net project tasks in the preset you’re using, then save it as a custom preset and keep using that preset from now on. Doing this has the side effect that the assembly name in the generated vs.net project is not correctly reflecting the RDBMS type if you use multiple RDBMS types in your project. So you have to manually alter this to work around the fact you get assemblies with the same name for every persistence project in your solution. Normally this isn’t a problem if you use just one database type in your project.