What's new/changed in LLBLGen Pro v2.6?

Below you'll find a list of changes, additions and important fixes in the 2.6 release. More things have been fixed, but these were generally small, or were fixed by a new piece of functionality. It's recommended you also browse the Migrating your code section for breaking changes.

End of life for .NET 1.x

The .NET 1.x frameworks are at the end of their lifespan. In v2.6 we still support .NET 1.0 and .NET 1.1, but the new features and changes made to the framework and documentation were largely focussed on .NET 2.0+ and often changes weren't backported to .NET 1.x. We recommend that you migrate to .NET 2.0 or higher if possible.

New functionality / changes

General

• Full Linq support with our own Linq to LLBLGen Pro provider. This provider allows you to fully use Linq in C# or VB.NET on .NET 3.5 to query your database, using Adapter or SelfServicing. We've spend a lot of time to implement as much Linq functionality as possible and have added extra extension methods to use all the LLBLGen Pro features through Linq constructs, like prefetch paths and exclude/include fields. Read more...
• .NET 3.5 support. With code changes in the runtime so it works better with Linq to Objects and with VS.NET 2008 project templates
• SqlServer CE 3.5 support. (compact framework and desktop).
• Derived table support. It's now possible to specify a complete query as a FROM clause or as a side of a relation. This feature requires support for derived tables in the database. The databases which don't support this are: Firebird 1.x and SqlServer CE 3.1 or lower. Read more...
• Dynamic relation support. It's now possible to add a relation object in code between any two entities without a lot of effort. It's also possible to add a relation between a derived table and an entity or between two derived tables. Read more...
• .Net 2.0+: Much lower memory consumption during transactions. When entities are saved, their state is preserved during the transaction they participate in so if a transaction is rolled back, the entity state is rolled back to the state before it started participating in the transaction. This consumed a lot of memory overhead in previous versions (60% of the memory taken by an entity was necessary for this state preservation). This has been brought down with 90%. (example: 500 test entities in memory occupy 1.6MB of memory. In v2.5, after save they occupy 2.4MB of memory during the transaction. In v2.6, 1.7MB, just 100KB more.)
• .NET 2.0+: EntityField/EntityField2 consume up till 20% less memory. Combined with the transaction memory reduction, the memory consumption of a set of entities which participate in a transaction right before commit of that transaction is lower than the memory the entities occupied in v2.5 without being in a transaction.
• .NET 2.0+: SqlServer CE Desktop is now easier to use. One can generate normal SqlServer code when SqlServer CE Desktop (CE 3.1 or higher) is used, as the DQE and templates work with the DbDataProviderFactory and have two new compatibility modes: SqlServerCE3x and SqlServerCE3.5. When deploying a CE Desktop application, be sure to add the DbDataProvider factory registration to your application's .config file. See CE Desktop's documentation for details about that. It's now possible to simply switch between CE Desktop and SqlServer server due to the change of a connection string and the compatibility mode setting (of course the schemas have to match). Read more...
• Support for CF.NET 3.5. LLBLGen Pro generated code is now supported on CF.NET 3.5 (SqlServer targeting projects only)

Runtime Libraries

Added

• DerivedTableDefinition class. A new class has been added, DerivedTableDefinition, which is used to specify a complete query as a FROM clause. It's the final piece of the puzzle to create any SQL query though LLBLGen Pro's query api. Read more...
• .NET 2.0+: EntityView/EntityView2 classes now have constructors which accept a Func<T, bool>. It's now possible to create an entity view from an entity collection by passing to its CTor a func instead of a predicate. (on .NET 2.0, you can use an instance of the .NET framework class Predicate<T>)
  
  Example (.NET 3.5 code):

  EntityView2<CustomerEntity> customersFromGermany = 
                new EntityView2<CustomerEntity>(customers, c=>c.Country=="Germany"); 

  
  
• .NET 2.0+: A generic DelegatePredicate<T> class. For in-memory filtering, a new generic variant of the DelegatePredicate class has been added. This generic variant accepts a Predicate<T>, which can be defined in .NET 3.5 with a Func<T, bool>. This way, you can define in-memory filtering using predicates where necessary using the DelegatePredicate<T> class.
• .NET 2.0+: String uniquing. Per DataAccessAdapter and DaoBase instance, a string cache is used to unique string value instances. When queries return multiple instances of the same string, each instance takes up memory, even though the value of the string is the same. The fetches of entities and projections are now using that cache, so if you fetch a projection (or use a Linq query which returns an anonymous type) and a string value is returned multiple times in the query, the string is actually in memory just once, and all objects reference that same instance. This is ok, as strings are immutable anyway. Strings aren’t ‘interned’ though. The cache lives as long as the DataAccessAdapter / Dao instance lives. This is done to prevent having a big string cache building up over time. The string uniquing is done using UniqueList<T> and takes almost no performance overhead. In Adapter you can pass a string cache to the DataAccessAdapter by setting the protected property StringCacheForFetcher in a method you add to DataAccessAdapter.
• .NET 2.0+: Utility routines to create empty dataset and datatable from type or hierarchy for projections. A new utilty class, GeneralUtils has a couple of routines to produce an empty dataset from a prefetch path or an empty datatable from an EntityType value or factory. These routines can be used in combination of hierarchical projections of entity collections to datasets.
• .NET 2.0+: ExcludeFieldsList and IncludeFieldsList are now added as helper classes. The class ExcludeIncludeFieldsList is a bit confusing as what it contains depends on a flag. Two helper classes are added which derive from ExcludeIncludeFieldsList (so are usable whenever ExcludeIncludeFieldsList is accepted) and which represent fields to Exclude (ExcludeFieldsList) or to include (IncludeFieldsList). The classes are empty except they set the excludeContainedFields flag to true (ExcludeFieldsList) or false (IncludeFieldsList) automatically. 
• .NET 2.0+: Setting to let the framework produce case-insensitive based hashcodes for string values in entity fields. Through a new static property on the new class EntityFieldCore: EntityFieldCore.CaseSensitiveStringHashCodes, a developer can control if the GetHashCode() method for a string typed entity field will produce a hashcode based on the case sensitive version of the string value or the case insensitive version. Default is true: case sensitive hashcodes. Set this setting to false if you work with a database which has casing differences between FK and PK values. You can also set this setting in the config file by adding a new key / value pair to the appSettings element: caseSensitiveStringHashCodes, which has as values either 'true' or 'false'.
• New EntityField/EntityField2 constructors to target derived tables. It's now possible to target a derived table with a field, by using a new constructor on EntityField or EntityField2, which accepts two strings and a type.
• .NET 3.5: New tracer: LinqExpressionHandler. A new tracer has been added for the Linq provider. Set it to 3 to obtain the Expression tree to evaluate in textual form (recommended for tracing linq queries) or to 4 to get a very verbose list of all expression handler methods visited. Only set this tracer to level 4 if you need to, as the output is very verbose.
• .NET 2.0+: QueryApiObjectTraverser class. This class is the base class for various visitors which can be used to traverse a graph of elements, like predicate expressions, relations in a relation collection etc. and to obtain information from the graph while traversing.
• .NET 2.0+: DataSourceCacheLocation.None. The datasource controls now have an option to disable caching of the fetched data. This can be useful if the data is used in a readonly fashion. State of the control (except the data) is cached in the viewstate.

Changed

• .NET 2.0+: IProjector now has a new flag, SetUsingCTorHint, which hints the projector engine how to set the destination element: via a CTor parameter (true) or otherwise, e.g. via a property setter action. This is a hint flag which is ignored in some projector engines, like the DataProjectorToDataTable and DataProjectorToEntityCollection, which always fill the destination elements via other ways than ctors. DataProjectorToValueList also ignores this flag as it's not applicable, the destination is a single value, there's no ctor to call nor property to set. Important:  Projectors for CTors have to appear in the same order as their destination parameters appear in the CTor to use.
• .NET 2.0+: IEnumerable and IEnumerable<T> implemented on various classes and in methods. To support Linq to Objects and to make traversing some collection based classes a bit easier, IEnumerable<T> and IEnumerable have been implemented on more classes to make it possible to use them in .NET 3.5 more easier.
• .NET 2.0+: ‘HasErrors’ and ‘RowError’ columns are now filtered out in design mode of DataSourceControls. TypedLists/views always had 2 extra columns in design mode of the LLBLGenprodatasourcecontrols: “RowError” and “HasErrors”. These two columns are now filtered out.
• .NET 2.0+: Adapter: RemovedEntitiesTracker is now serialized into xml/deserialized from xml. When a collection had a RemovedEntitiesTracker set and it was serialized over XML, the removedentitiestracker wasn’t serialized into the XML. This has been changed: the RemovedEntitiesTracker is now serialized with contents and deserialized back at the other end. The deserialized collection is of type EntityCollectionNonGeneric. Use the IEntityCollection2 interfaces to use the deserialized collection in your code. The collection isn’t serialized nor deserialized in selfservicing, as selfservicing isn’t recommended in distributed scenarios.
• .NET 2.0+: Adapter: FastSerializer/Deserializer now have a CTor which accepts an open reader/writer. FastSerializer/Deserializer can now be instantiated with an open reader/writer to serialize own data more easier.
• .NET 2.0+: ObjectGraphUtils.ProduceCollectionsPerTypeFromGraph now has an overload which accepts an array of collections. This overload can be used to merge graphs defined by different entity collection instances into one set of collections with entities of the same type stored per collection, effectively merging all collections together.
• .NET 2.0+: SqlServer now uses a parameterized TOP clause if in SqlServer 2005 mode. When the DQE is set into SqlServer2005 mode (mode for SqlServer 2005 and up), it will emit TOP(@param) instead of TOP(number), which could lead to more re-uses of execution plans and thus faster queries.
• .NET 2.0+: IEntityFields/IEntityFields2 now implement IList. The IEntityFields/IEntityFields2 interfaces (and the EntityFields/EntityFields2 classes) are now usable in IList scenario’s without casting. Not all methods are implemented (See the reference manual for details).
• .NET 2.0+: CreateHierarchicalProjection now re-uses DataTable instances. If a passed in DataSet in the projection routine to DataSet, contains a DataTable with the name of the entity it will be used instead of a new DataTable (though it will be cleared from data). This way it is possible to pass a pre-fab DataSet created with the utility routines for dataset creation which is then filled with projected data.
• .NET 2.0+: Typed lists and typed views now implement IEnumerable<T>. Typedlist/view classes now implement IEnumerable<T> where T is the row type of the typedlist/view. This allows developers to use Linq over a typedlist/view in memory.
• .NET 2.0+: m:1/1:1 properties now raise PropertyChanged event when changed. When you for example set the property OrderEntity.Customer to a new CustomerEntity instance, LLBLGen Pro will now raise the event PropertyChanged for 'Customer'.
• .NET 2.0+: When PK fields are synced with FK fields, all FK fields now trigger a PropertyChanged event. In previous versions, the syncing of a PK with an FK resulted in 1 PropertyChanged event on the FK side, even if the PK and FK contained multiple fields. In v2.6, for every field in the FK, a PropertyChanged event is raised.
• .NET 2.0+: Unit of work classes now unwrap TargetInvocationExceptions. The calls to directly delete/update entities or delegate calls to procs by the Unit of work classes can involve Invoke calls. If such an operation results in an exception, this exception is wrapped inside a TargetInvocationException. The UnitOfWork(2) classes now unwrap the inner exception and rethrow that exception instead of the TargetInvocationException.
• .NET 2.0+: DQEs are more clever when determining if DISTINCT is required. To efficiently and correctly fetch data, it sometimes is necessary to assure unique rows. The typical way to do so is adding 'DISTINCT' to the result query. The downside is that 'DISTINCT' adds a set of restrictions to the query which might cause a different, less efficient overall data fetch experience. The DQEs are now better capable of determining if 'DISTINCT' is required or not: if no duplicate rows are expected, DISTINCT can be omitted and therefore the restrictions of DISTINCT can be avoided.
• .NET 2.0+: Entity collections now override ToString(). An entity collection now overrides 'ToString' and returns the entity type it is set to and the number of elements in the collection. This is handy when debugging code.
• .NET 2.0+: When a property which represents a 1:1/m:1 relation is changed, PropertyChanged is raised. When you change for example myOrder.Customer to a new customer, the framework now raises the PropertyChanged event for 'Customer'.
• .NET 2.0+: SqlServer CE 3.x targeting DQEs now emit named parameters. SqlServer CE 3.x supports named parameters instead of anonymous parameters with '?'. The DQEs targeting SqlServer CE 3.x databases have been enhanced to emit named parameters now so the issues with anonymous parameters and SqlServer CE 3.5 are avoided.
• DbFunctionCall now doesn't ignore schema or catalog names specified anymore when the function name is a pre-formatted string. This doesn't normally lead to breaking code as the names were ignored previously, but just in case you passed the names, they're now having effect.
• .NET 2.0+: CancelEdit() now raises PropertyChanged events. When CancelEdit() is called (either by manual code or by a bound control) on an entity, for every field which was changed during the edit cycle, PropertyChanged is now raised. This makes bound controls reflect the reset values for the fields changed, as the fields were reset to their values prior the edit cycle was started.
• .NET 2.0+: TypedListBase, TypedListBase2 and TypedViewBase are now generic classes.
• .NET 2.0+: The default culture used for XML serialization is now set to the invariant culture. This culture is controlled by the XmlHelper.CultureNameForXmlValueConversion property or the .config file setting cultureNameForXmlValueConversion. Previously it was set to the current culture of the executing thread. If you want to use a different culture you’ve to set the property or the config setting.
• SelfServicing: Before CheckIfCurrentFieldValueIsNull is doing its checking the entity now first refetches itself if required (e.g. when it's out of sync after a save).

Drivers

Added

• SqlServer 2008 support. The 4 new types in SqlServer are now supported in the driver and runtime lib/templates.
• Sybase ASE driver now allows to set the number of return parameters for stored procedures through the designer UI, similar to the SqlServer driver. Enabled when the selection which stored procedures to retrieve is set to manual.

Changed

• Oracle drivers using ODP.NET now throw out stored procedures which have at least 1 parameter and/or return value of the type BOOLEAN. This is because ODP.NET can't deal with BOOLEAN typed parameters in stored procedures.

Designer

Added

• Extra sync option: SyncRenamedFieldElementsAfterRefresh. This option controls whether entity fields and fields mapped onto relations are synced with the database parts if SyncMappedElementNamesAfterRefresh is set to true: if the fields are manually renamed, and SyncRenamedFieldElementsAfterRefresh is set to false, the names of these fields aren’t synced. As manual renaming is tracked starting in v2.6 for entity fields and fields mapped onto relations, this feature only has effect when a field is manually renamed in v2.6.
• Option to disable hide of Browsable(false) attributes. The preference setting (and project property) HideManyOneToOneRelatedEntityPropertiesFromDataBinding, default true, controls whether Browsable(false) attributes are generated onto properties which represent fields mapped onto 1:1 or m:1 relations. If this option is set to false, these properties will show up in databinding scenario’s which could cause problems, hence the default: true.
• The designer now checks if the file to save the project to has been changed after it was loaded. When you load a project file F into the designer, and someone else changes that file after that, and then you try to save F, you'll now get a popup warning you that you'll overwrite the changes of someone else as the file you've been working on has been altered after you've loaded it into the designer.

Changed

• SqlServerAutoDetermineSProcType is now called ‘AutoDetermineSProcType’. The setting is renamed because it’s now also used by Sybase ASE. Preference/project settings don't break, they're migrated to the new setting.
• When a type converter class couldn't be loaded, the rest of the type converters in the assembly are still examined. In previous versions, when a TypeConverter derived class was found in an assembly and it couldn't be loaded, the complete assembly was ignored. In v2.6, the rest of the type converters are still examined, only the TypeConverter which couldn't be loaded is ignored.

Task performers

Changed

• The ProjectFileCreator task performer now works with <[RuntimeLibraryHintPathxy]>, where xy is the .NET version to target, e.g. 20.
• When a project is re-generated into an existing directory in which the code of a previous generation cycle is located, the cs/vbproj file(s) won’t get their rootnamespace set again. Initially when a cs/vbproj file is generated, the rootnamespace is set, and in previous versions of LLBLGen Pro, the rootnamespace name was overwritten also if the cs/vbproj file was altered in subsequential code geneneration cycles. This overwriting has been removed: if you alter the namespace after the first code generation cycle, it won’t be reset. Normally you won’t notice this unless you add classes to the generated code yourself.

Templates

Added

• .NET 2.0+, Selfservicing: Entities now have AlreadyFetchedpropertyName properties. These properties return the state of the already fetched flag which is used to determine if selfservicing should take place. If the property is set to false while the property has already been fetched, the related data is cleared (e.g. customer.AlreadyFetchedOrders = false; means customer.Orders.Clear())
• DynamicRelation class. A new class has been added, DynamicRelation, which makes it easy to create relations in code between non-related entities, entities and derived tables or between derived tables. A DynamicRelation is also required to add a derived table to a query, by setting its left side to a derived table and then adding the DynamicRelation instance to a RelationCollection.
• .NET 2.0+: IElementCreator/IElementCreator2 implementing classes. These classes are located in the FactoryClasses namespace and can be used to create various template group specific elements, like factories and dynamic relations. The implementation is mainly used by the Linq provider but can be handy in other situations as well, hence it’s added to the .NET 2.0+ batch of code (which is used by the .NET 3.5 targeting code)