(c/p of newsitem) After 5 months of development and 1 month of beta testing, it's finally here: LLBLGen Pro v1.0.2005.1. Packed with new features and enhancements and a free upgrade for all our customers.

Please go to the Full Version section in the customer area: http://www.llblgen.com/pages/secure/upgrades.aspx to download the full installer to upgrade to the new version. We also updated all the archives for the separate parts, the documentation and the examples.

Note: The documentation contains a Migrating Your Code section, be sure to read that section if you're planning to upgrade your code to v1.0.2005.1. Normally, upgrading should be painless, though in some cornercases you have to make some changes. The breaking changes are discussed in that section.

Full list of changes: Drivers Changed

* All type enums are now public
* Firebird driver is now build against v1.7a of the Firebird.NET provider
* Sqlserver's driver now always reads the @@IDENTITY sequence as well, so users can set entity field sequences to @@IDENTITY instead of SCOPE_IDENTITY() if they want to. This is required for entities mapped onto views and which are used with instead-of triggers. The driver now also signals calling code that the user can select a sequence, so in the designer a user can now select a sequence for a field in an entity, this isn't disabled anymore for projects targeting SqlServer.

Added

* SqlServer driver: support for Xml types in SqlServer 2005
* Oracle drivers using ODP.NET: support for XMLType types in Oracle 9i/10g

Runtime Libraries Changed

* Adapter: Catalog name overwriting at runtime has been reworked. You can now pass in a CatalogNameOverwriteHashtable which contains all the name value pairs and the setting what to use. Internally the DataAccessAdapter uses this setting as well. Name overwriting is now done by the DQE at fieldname construction, not when the fieldpersistenceinfos are retrieved. Wildcard can be used. SQLServer specific
* Structure of DQE's: they're now instance classes, no longer classes with static methods.
* Reworked recursive save pipeline using topology sorting of a directed graph: first queues are constructed, then the save actions are started on these queues. This both gives faster recursive saves, but also keeps the transaction shorter (in time), as it's started later (selfservicing has same starts, adapter starts the transaction later). Originally, the recursive save routine saved the entities while traversing/building the tree.
* UnitOfWork classes now use the new recursive save pipeline elements to construct first queues to process before starting the actions on these queues. When a unitofwork(2) object is serialized, it first determines the real elements to save, which makes serializing unitofwork(2) objects very efficient, as only the elements which will take part of a persistence action are serialized into the UnitOfWork(2) serialized data.
* Adapter: serialization / deserialization of entities is now much faster and the data produced is up to 60% smaller.
* Selfservicing: Multi-entity fetch logic now calls OnFetchComplete() after an entity was succesfully fetched and filled with data. Post-fetch initialization logic should be placed inside a method which overrides OnFetchComplete().

Added

* Inheritance support (3 types of inheritance)
* Multi entity on single target mapping
* Type converter technology for converting values transparently from one .NET type to the other .NET type and vice versa, to be used in Entity/View fields and predicates. For example, it offers the ability to map boolean fields directly on non-boolean/bit types in the database, or for example to map an XmlDocument object onto a string type.
* Ability to not map a field in a table / view to a field in an entity
* Polymorphic query support including filtering on entity type
* Compact framework .NET 1.1 support
* SQL CE support
* Prefetch path fetches in combination with paging
* Adapter: Schema name overwriting settings at runtime for multiple schema name overwrites. You can pass in a SchemaNameOverwriteHashtable which contains the from-to namepairs and the setting what to do. Wildcard can be used. SQLServer, Oracle, DB2 specific.
* MySql: Update entities directly with multi-entity filter has been added.
* FieldBetweenPredicate now also handles field BETWEEN value AND field, field BETWEEN field AND value, field BETWEEN field AND field
* ORMInheritanceInfoException exception, meant for errors determined during query execution, for example when the inheritance info data is out of sync with the data in the db, which occurs for example when the type has to be determined of the row retrieved from the db and the discriminatorvalue is unknown.
* Prefetch path optimization with a user definable threshold when to switch from one method to the other.
* Support for Cross joins.
* Overload to DataAccessAdapter.SaveEntity, which accepts recurse and refetchAfterSave but not a predicate.
* SelfServicing: EntityCollectionBase.DoNotPerformAddIfPresent flag to signal if EntityCollectionBase.Add() should check if the entity to add is already in the collection (default, true) or not (false).
* Adapter: New overloads for FetchTypedList and FetchTypedView which are simpler to use (e.g. accept a typedlist/typed view and don't require you to retrieve the fields info / relations info first.
* EntityCollectionBase(2) now has 2 properties (ConcurrencyPredicateFactoryToUse and EntityValidatorToUse) which will set these properties of any new entity created in a collection fetch to the values stored in these two properties. Also done when AddNew() is called in a databinding scenario.
* OnBeginEdit(), OnEndEdit(), OnCancelEdit(), OnTransactionCommit() and OnTransactionRollback() as protected virtual methods to EntityBase(2).
* Adapter specific constructor to EntityRelation class.
* SqlServer: inserts into a table with solely an identity field are now possible. (INSERT INTO table DEFAULT VALUES)
* Prefetch path optimization through caching of PK hashes.
* UnitOfWork(2) now offer a way to construct the insert/update queues prior to actually committing them. These queues aren't reset after a commit so can be used to fine-grained control over the elements participating in the unitofwork.
* Native .NET 2.0 builds for the ormsupport classes and various DQE's. The ORM support classes build doesn't use ICustomTypeDescriptor on the entity classes, which should enable design time databinding on .NET 2.0 for the time being. (winforms).
* Polymorphic prefetch paths: fetches of supertypes can be performed with prefetch paths which refer to related objects of subtypes and which will load only the subtype's related objects into the subtype instances (if available).
* SortClause.CaseSensitiveCollation. This flag will apply UPPER() (or db specific equivalent) to the field to sort on, to make case sensitive database installations be able to sort case insensitively.
* Adapter: OnBeforeTransactionCommit, OnAfterTransactionCommit, OnBeforeTransactionRollback and OnAfterTransactionRollback added to DataAccessAdapterBase as public virtual methods.
* Adapter: New constructor to RelationPredicateBucket which accepts an IPredicate to ease the construction of filters for Adapter.

Designer Changed

* The regular color in the logviewer is now green instead of maroon. Errors are now much easier to spot.
* Custom entity relation editor: the checkbox for auto-detect m:n relations is now only checked if the refresher preference to hide m:n relations automatically is set to false.
* Custom entity relation editor: the name of the field mapped onto the relation to create is now initially set with the name of the related entity.
* Relation nodes of an entity are now sorted ascending in project explorer
* Fields mapped onto relation nodes of an entity are now sorted ascending in project explorer.
* It's now possible to select a sequence for a field which is in an entity mapped onto a view and mark it as identity for sqlserver.

Added

* New preference setting: AddNewFieldsAfterRefresh, which controls if newly found target fields are added as new fields or are added to the list of unmapped fields.
* New preference setting: HideManyToManyRelationsOnCreation, which controls if newly created m:n relations should be marked 'hidden' by default.
* Multiple entities can now be mapped on a single target.
* Entity list viewer for proper overview which entity is mapped onto which target.
* New preference setting: AutoAssignTypeConverterToNewField, which controls if a newly added field (for example in a new entity) gets a matching type converter assigned to it automatically, based on the type conversion definitions defined in the project.
* Plugin which toggles the hide flag on m:n relations. If a relation can't be made unhidden (because one of the two relations it's build on is hidden), it's not marked unhidden.
* Plugin which applies selected Type Conversion Definitions to selected elements, to quickly set type converters on existing projects.
* Option (ManuallySelectRenamedTargetsAfterRefresh) added which will cause the refresher to pop up a dialog (if not unattended) in which the user can select which target to select for a given entity, if the target couldn't be found by the refresher, for example in the case when the target has been renamed.
* Option (LazyLoadingWithoutResultReturnsNew) added to set the flags for the _entityReturnsNewIfNotFound flags in Selfservicing to a value specified in the designer. This makes it easy to set this flag once for all generated entities. Selfservicing specific.
* Context menu to Relations treeview in Entity Editor for easy removal of custom relations and toggle actions on relations.
* Typed list relations can now also have the join hint for a Cross join.
* Typed list designer now has 'Field index' in the column list of the fields in the select list. Use shift-click on the column headers to sort on multiple columns.
* Entities mapped onto views can now have nullable fields.
* Entity hierarchy visualizer.

Task performers Added

* Lpt templates can now be bound to templateid's which are included in TDL templates. This greatly enhances the scope of the include templates as with lpt templates (with <% %> syntax and template code in C#/VB.NET) it's possible to access the complete project object graph. This is completely transparent, just bind a .lpt template to a template id which is included in a TDL template and it will be called.

Templates Added

* Two new overloads to ResultsetFields.DefineField() for each typed view, which accept an alias for the field.
* New method in entity classes: TestCurrentFieldValueForNull(index), which returns true if the current value of a field represents null/undefined. This is for example the case for a field of a new entity which hasn't been changed, or a field in a non new entity which hasn't been changed or which has been set to null/Nothing.
* Support for partial classes in VS.NET 2005 scenario's: all classes are generated as partial classes (C#) if a VS.NET 2005 generator scenario is chosen. VB.NET 2005 classes can already be extended with partial classes without having the generated classes defined as 'Partial'.

Congratulations on completing the run of such an amazing version 1 product, Frans! You've put together a package that has been solid from the beginning, with a value that has seemingly increased 100% with each successive release.

PK-FK synching, Adapter, recursive saving, units of work, savepoints, dynamic lists, custom code regions, and now inheritance support...the list seems endless! You've made my life and, I presume, thousands of other developer's lives a much easier story.

Thanks for such an incredible product. I can't wait to see what you have in store for version 2!

Jeff...

jeffreygg wrote:

Congratulations on completing the run of such an amazing version 1 product, Frans! You've put together a package that has been solid from the beginning, with a value that has seemingly increased 100% with each successive release.

PK-FK synching, Adapter, recursive saving, units of work, savepoints, dynamic lists, custom code regions, and now inheritance support...the list seems endless! You've made my life and, I presume, thousands of other developer's lives a much easier story.

Thanks for such an incredible product. I can't wait to see what you have in store for version 2!

Jeff...

Certainly made my life a thousand times easier! 1.0.2005.1 came at JUST the right time. Actually, it came about two hours early because the site was down until a few minutes ago. I've been trying to hit the server ever since!

I second that!! LLBLGen simply rules! A day doesn't go by without me thinking how freaking great this tool is and how much time it has saved our development team.

My favorites of this release: 1) Serialization speed improvements 2) Multiple catelog hashtable 3) Inheritence (I will love this one more and more as I refactor code...) 4) Recursive save speed improvements

Keep up the great work!

Thanks all for your very kind and great words

Now let's hope the site keeps up

It's ok about the server, I'm going to wait to download it until after the first hotfix...

Fantastic

You get 5 out of 5 Fish Sticks from me!

Thanks guys!

I've been busy all day with new code for the website, it's now fully cached and the file streamer now should now no longer make IIS/ASP.NET leak memory. (BinaryWrite() leaks memory apparently, it's never regained... ).

Tomorrow first thing I'll be looking into the first glitches in 1.0.2005.1

I'm curious, did you use Response.WriteFile() instead?

http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q306654

acradyn wrote:

I'm curious, did you use Response.WriteFile() instead?

http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q306654

Yes. I tried numerous things, even my own buffer writer with 16kb chunks. It turns out the Response object leaks memory if you pass in a managed object. So all you can do is pass in a filename, and then it gets freed after the user moves away from the page.

Clearly a firm memory leak in asp.net, but what can you do... closing a stream, nothing works.

How do you know it leaks memory?

I've been using BinaryWrite to download pdfs and no one's mentioned the server running out of memory yet.

Notice that the worker process gets recycled (unless configured otherwise) if it starts to consume too much memory...

sami wrote:

Notice that the worker process gets recycled (unless configured otherwise) if it starts to consume too much memory...

Exactly I've done a lot of tests, almost a full day, and all kinds of different ways to send a file to the browser, and the only one which did work was passing the filename to WriteFile(). All others leaked memory that didn't get reclaimed.

(edit) and what do you know! I ran into TransmitFile this morning. Undocumented in the MSDN, but it seems to work great:

            Response.Clear();
            Response.BufferOutput = false;
            Response.AddHeader("Content-Type", "application/unknown");
            Response.AddHeader("Content-Disposition", "attachment; filename=" + filename);
            Response.AddHeader("Content-Transfer-Encoding", "Binary");
            Response.TransmitFile(completePathFilename);

be sure to set buffering to false. No memory consumption at all

Its news to asp.net 2.0 and is in the new documentation.

http://msdn2.microsoft.com/en-us/library/system.web.httpresponse.transmitfile

Ian wrote:

Its news to asp.net 2.0 and is in the new documentation.

http://msdn2.microsoft.com/en-us/library/system.web.httpresponse.transmitfile

Yes, it's been added to .NET 1.1 with SP1 I believe. There is an issue with Win2k3 SP1 and TransmitFile I read in the KB, so for now WriteFile will do.

Notice that the worker process gets recycled

How does one notice this? Is it just a case of noticing that a page request every so often will take a long time?

Users following a recycle can notice slow access times, also, I suppose that asp.net caches are rebuild after recycling, which could generate some database load for example.

Otis, how did you notice that there was a memory leak?

Ian wrote:

Otis, how did you notice that there was a memory leak?

My ISP told me So I had to fix it, so I tested all kinds of solutions for this locally. I then found out indeed it had a memory leak, because response.binarywrite() doesn't free the buffer.

When is version 2 due out ?

What will be the best upgrade path for version 2 ? v1.0.2004.2 => v1.0.2005.1 => v2.0.2005.1 OR v1.0.2004.2 => v2.0.2005.1

PaulMckenzie wrote:

When is version 2 due out ?

The plan is to have a beta starting at the end of 2005

What will be the best upgrade path for version 2 ? v1.0.2004.2 => v1.0.2005.1 => v2.0.2005.1 OR v1.0.2004.2 => v2.0.2005.1

The first. v2.0 builds on top of the functionality of v1.0.2005.1

Excellent, Thanks... We will look at moving up to v1.0.2005.1.

First off, congratulations on your new release and thanks for a great product! I just downloaded the demo and am looking forward to using it.

My concern, however, is your upgrade policy. Your FAQ page states that minor version upgrades are free, but I didn't see anything about major version upgrades. I'm a little hesitant to plunk down my $270 USD for v1.0.2005.1 when v2.0 is only a few months away.

Will there at least be a reduced cost upgrade available?

My apologies if this has been covered before.

Charlie

Charlie wrote:

First off, congratulations on your new release and thanks for a great product! I just downloaded the demo and am looking forward to using it.

My concern, however, is your upgrade policy. Your FAQ page states that minor version upgrades are free, but I didn't see anything about major version upgrades. I'm a little hesitant to plunk down my $270 USD for v1.0.2005.1 when v2.0 is only a few months away.

Will there at least be a reduced cost upgrade available?

My apologies if this has been covered before. Charlie

It's a question we get often . Customers of the 1.0.200x.y codebase will have a 3-4 month period to upgrade to v2.0 for 49$ per developer. The license model will change for v2.0, from department license to per developer license. The license is for the designer, so if your team has one person operating the designer, you need 1 license.

v2.0 will have support for .net 1.x and .net 2.0. v1.0.2005.1 will be supported as well for the current customers. No new features will be added to 1.0.2005.1, but bugfixes will be released if necessary.