I wonder if you have a roadmap for the 2.0 version as to some of the features/changes you plan to make.

Here are some things that would be nice. Some of these are from working with other mappers.

Generated Code 1. Use new ADO.Net TransactionScope object for transactions so that they are automatically made distrubted by the system if needed. 2. Use strongy typed collections via generics. 3. Lazy loading for fields as well as objects. 4. Auto Proxy support/generation of types. 5. Built-in support for .Net 2.0 CLR nullable types. 6. LESS CODE. You seem to generate alot of code. I assume that has to do with the factory classes you create. Other generators seem to work fine by just specifiying "type(EntityName)" to that adapter/session rather than needing a factory. 7. Auto-specified prefetch paths. 8. Auto gen/update db schema. I know you've talked about this. If your meta data has enough info in it, perhaps it is something I could write myself. 9. Don't put the word 'entity' after all the entities.

UI 1. Object first design. Let me create an entity, then drag fields from the schema to the entity to map it. 2. Specify namespaces/folders in the UI for entities.

These are just a few ideas.

BOb

pilotboba wrote:

I wonder if you have a roadmap for the 2.0 version as to some of the features/changes you plan to make.

First phase is to migrate the 1.0.2005.1 functionality to .NET 2.0, with all the .NET 2.0 new features and VS.NET's new features (like debugger visualization support, databinding etc. etc.)

Then new features are added till deadline's there

Here are some things that would be nice. Some of these are from working with other mappers.

Generated Code 1. Use new ADO.Net TransactionScope object for transactions so that they are automatically made distrubted by the system if needed.

Yes

1. Use strongy typed collections via generics.

Yes

1. Lazy loading for fields as well as objects.

Not sure. The problem is the specification of these fields, plus lazy loading is often a pain, especially in disconnected scenario's and scenario's where an entity shouldn't perform data access on its own, for example in a GUI tier, where it always has to call the BL tier...

1. Auto Proxy support/generation of types.

For remoting or for webservices? For webservices this is indeed planned.

1. Built-in support for .Net 2.0 CLR nullable types.

Yes

1. LESS CODE. You seem to generate alot of code. I assume that has to do with the factory classes you create. Other generators seem to work fine by just specifiying "type(EntityName)" to that adapter/session rather than needing a factory.

No, most code is in the syncing stuff in the entities. Factories are needed, as they're much faster than instantiating via a type.

1.0.2005.1 already brings down the code a lot, and for 2.0 I will try to move a lot more to the base classes (or simply remove it because generics helps ) with a different setup. Though most code generated is generated because it's much faster to do it that way than via stored data inside an entity which is then consumed by some generic routine.

1. Auto-specified prefetch paths.

This is inflexible in most cases. I understand why you want it, 'fetch customer and always its address object as well', though in the situation where you don't want it, it's slower. I'll look into it though.

1. Auto gen/update db schema. I know you've talked about this. If your meta data has enough info in it, perhaps it is something I could write myself.

No, I'll probably never support this. Main reason is that it is not working in practise: the developer works on dev db A, and production runs on db B. The developer alters db A through the o/r mapper, probably generates migration scripts, and then db B has to be updated... but with the script? Not likely, especially if the db is large. Also, if the dev db contains a lot of data, it can be really slow to make changes.

1. Don't put the word 'entity' after all the entities.

This is done to avoid name clashes.

UI 1. Object first design. Let me create an entity, then drag fields from the schema to the entity to map it.

Thought about it, but it's much slower than pointing to the fields and say: "map an entity onto this". Or select some tables and map entities onto these tables. Slower as in: 'productivity' of the user working with the designer.

LLBLGen Pro also doesn't follow Fowler/Evans, it follows the relational model idea with entities.

1. Specify namespaces/folders in the UI for entities.

That's on the list of features to add (the list is very long, I'm not sure if I can address everything in 2.0, as we have to release in a certain timeframe: we can't release v2.0 in march 2006 for example, though we can release a new 2.0 version in march with more features (free upgrade)).

Thanks for your comments, if you have more, please post them here

Btw, about the code being generated: code is cheap, data is expensive. This is because code is shared among all instances, so not memory intensive, but data isn't.

Also, LLBLGen Pro entities have a lot of code inside themselves which isn't present in POCO classes, simply because you have to write it yourself.

Though I will try to branch out generated code to a generic set of classes, which can be as fast and tiny on memory footprint as generated code but also doesn't burden the amount of generated code. With the new query system, I've tried to make predicatefactory and sortclausefactory obsolete, which are the two biggest classes in a project. Because the no.1. rule for the query system was and still is: compiletime checking, I couldn't move to a stringbased solution, hence the necessity for entityFields classes, but these are relatively tiny and very helpful.

Otis wrote:

PilotBob wrote:

1. Lazy loading for fields as well as objects.

Not sure. The problem is the specification of these fields, plus lazy loading is often a pain, especially in disconnected scenario's and scenario's where an entity shouldn't perform data access on its own, for example in a GUI tier, where it always has to call the BL tier...

Ok, well, you have to store your specifications somewhere. How about an attribute?

Otis wrote:

PilotBob wrote:

1. Auto Proxy support/generation of types.

For remoting or for webservices? For webservices this is indeed planned.

Neither. Basically I am looking for a smaller version of the entity to perhaps put in the list collection. For example, say I have a customer entity. This entity may have 50 fields. I to query all customers in state="Florida". However, I only want a collection of proxy classes. Such that only say CustID, First Name, Sur Name, Middle Name are returned so I can provide a pick list.

I know you have typed lists. But, if you support proxy then I can use the proxy which will be replaced by a full object if I access another field. I guess this is similar to lazy loaded fields but different.

Otis wrote:

1. LESS CODE. You seem to generate alot of code. I assume that has to do with the factory classes you create. Other generators seem to work fine by just specifiying "type(EntityName)" to that adapter/session rather than needing a factory.

No, most code is in the syncing stuff in the entities. Factories are needed, as they're much faster than instantiating via a type.

1.0.2005.1 already brings down the code a lot, and for 2.0 I will try to move a lot more to the base classes (or simply remove it because generics helps ) with a different setup. Though most code generated is generated because it's much faster to do it that way than via stored data inside an entity which is then consumed by some generic routine.

It also seems to me that you should only generate Adapter code, and self-servicing would just submit themselvs to the adapter. This way, you don't really need seperate code generated for it. You just need to add CRUD methods to the base.

Also, why do you need all the constructors in the derived entities in addition to the base. Do you expect that we would modify the constructors?

Otis wrote:

PilotBob wrote:

1. Auto gen/update db schema. I know you've talked about this. If your meta data has enough info in it, perhaps it is something I could write myself.

No, I'll probably never support this. Main reason is that it is not working in practise: the developer works on dev db A, and production runs on db B. The developer alters db A through the o/r mapper, probably generates migration scripts, and then db B has to be updated... but with the script? Not likely, especially if the db is large. Also, if the dev db contains a lot of data, it can be really slow to make changes.

Here is my thought.

Your IDE stores metadata about the schema. This metadata can/should contain all information to generate the SQL db.

So, to update the schema would take the following steps...

1. Generate a tempdb using the metadata.
2. Compare that tempdb to the actual db an create a change script perhaps using SQL Compare or Db Ghost.
3. Apply the change script to the actual db.

Of course, there would be some rules you would have to follow. Like new fields must allow null or a default must be defined. The default could be temp or permanent.

Otis wrote:

PilotBob wrote:

1. Don't put the word 'entity' after all the entities.

This is done to avoid name clashes.

Name clashes with what? Can this be a name template item in the project properties? Perhaps I don't want to use the word "entity"?

Otis wrote:

That's on the list of features to add (the list is very long, I'm not sure if I can address everything in 2.0, as we have to release in a certain timeframe: we can't release v2.0 in march 2006 for example, though we can release a new 2.0 version in march with more features (free upgrade)).

Cool, is "the list" published somewhere so I don't ask for things already on the list. How about a way for users to vote for features?

Otis wrote:

Thanks for your comments, if you have more, please post them here

You can count on it.

BOb

Otis wrote:

Btw, about the code being generated: code is cheap, data is expensive. This is because code is shared among all instances, so not memory intensive, but data isn't.

True but a good point.

However the code isn't as polymorphic as it could be. Code that uses an entity needs to have that entities name in it always. I can't write the same code for my Customer that I can for my vendor even though the query would be the same basically.

Also, other mappers concrete/derived classes (I am talking two class scenerio here) are empty other than

public class MyEntity : Entity {

}

I'm not sure why all the code is needed in the concrete class when it is in the abstract class. Other mappers don't have it or need it.

You shouldn't even need to re-gen the concrete class once it is created.

It just seem really messy with all that code an generator comment blocks in there.

BOb

If LLBLGenPro generated or changed schema I would never, ever use this feature. I control my db schema with scripts, and in my opinion this old DBA practice makes life a lot easier, I am really surprised more people don't do it.

I would MUCH rather modify my master script (if early in development) or write a change script myself and just let LLBLGen do what it does best as far as generating the ORM layer. Relying on it to manage my schema is no better than relying on Enterprise Manager to manage my schema, which is bad, in my opinion, though I know 90%+ of the people reading this are doing it. No offense to anybody, of course

pilotboba wrote:

Otis wrote:

PilotBob wrote:

1. Lazy loading for fields as well as objects.

Not sure. The problem is the specification of these fields, plus lazy loading is often a pain, especially in disconnected scenario's and scenario's where an entity shouldn't perform data access on its own, for example in a GUI tier, where it always has to call the BL tier...

Ok, well, you have to store your specifications somewhere. How about an attribute?

That's inflexible, say you want in one call, 7 of the 10 fields, and in another call 8 of the 10, you're stuck with an attribute or other statically defined option. What I was thinking of, was an overload of fetch methods which accept a list of fields to fetch. This way, only those fields are fetched, not other fields. This is relatively easy to do, as the fetch logic internally also uses fields to build the query . But I've to see how well this goes. Lazy loading of data is sometimes nice, the downside is that it should get out of your way if you want it to, which is often hard because lazy loading code is not that simple.

Otis wrote:

PilotBob wrote:

1. Auto Proxy support/generation of types.

For remoting or for webservices? For webservices this is indeed planned.

Neither. Basically I am looking for a smaller version of the entity to perhaps put in the list collection. For example, say I have a customer entity. This entity may have 50 fields. I to query all customers in state="Florida". However, I only want a collection of proxy classes. Such that only say CustID, First Name, Sur Name, Middle Name are returned so I can provide a pick list.

I know you have typed lists. But, if you support proxy then I can use the proxy which will be replaced by a full object if I access another field. I guess this is similar to lazy loaded fields but different.

Ok I now see what you mean. I pressume the proxy's are generated at runtime, and after the fetch method's call parameter values, so you can tweak in your code how a proxy for that call looks like?

Otis wrote:

1. LESS CODE. You seem to generate alot of code. I assume that has to do with the factory classes you create. Other generators seem to work fine by just specifiying "type(EntityName)" to that adapter/session rather than needing a factory.

No, most code is in the syncing stuff in the entities. Factories are needed, as they're much faster than instantiating via a type.

1.0.2005.1 already brings down the code a lot, and for 2.0 I will try to move a lot more to the base classes (or simply remove it because generics helps ) with a different setup. Though most code generated is generated because it's much faster to do it that way than via stored data inside an entity which is then consumed by some generic routine.

It also seems to me that you should only generate Adapter code, and self-servicing would just submit themselvs to the adapter. This way, you don't really need seperate code generated for it. You just need to add CRUD methods to the base.

Absolutely right, for .NET 2.0, where I have to rebuild the code anyway (as a lot of code can go away thanks to generics), I'm definitely setting it up so that adapter is the code and selfservicing is a wrapper around adapter. Selfservicing was made first, adapter came 6 months after that after customer requests, hence the somewhat upside-down design of the runtime lib. A schoolbook example why Agile development doesn't work btw. I hope to correct that in 2.0

Also, why do you need all the constructors in the derived entities in addition to the base. Do you expect that we would modify the constructors?

If you have a base class with a particular constructor, and you derive a class from it, you have to have the same constructor in the base class if you want a user to use that constructor, these aren't inherited. The constructors are there to have a flexible way of initializing an entity, if you want to.

Otis wrote:

PilotBob wrote:

1. Auto gen/update db schema. I know you've talked about this. If your meta data has enough info in it, perhaps it is something I could write myself.

No, I'll probably never support this. Main reason is that it is not working in practise: the developer works on dev db A, and production runs on db B. The developer alters db A through the o/r mapper, probably generates migration scripts, and then db B has to be updated... but with the script? Not likely, especially if the db is large. Also, if the dev db contains a lot of data, it can be really slow to make changes.

Here is my thought.

Your IDE stores metadata about the schema. This metadata can/should contain all information to generate the SQL db.

It doesn't read indexes at the moment, which will change in 2.0, but with that, indeed you're correct.

So, to update the schema would take the following steps...

1. Generate a tempdb using the metadata.
2. Compare that tempdb to the actual db an create a change script perhaps using SQL Compare or Db Ghost.
3. Apply the change script to the actual db.

Of course, there would be some rules you would have to follow. Like new fields must allow null or a default must be defined. The default could be temp or permanent.

True, though step 2 is tougher than you might think, and has a disadvantage as well: what if 2 or more developers work on the team? What to do with their change scripts?

LLBLGen Pro now builds on the experience of specific tools for relational model design, which are far better in keeping a model in a db in sync with an abstract design. Also, a lot of teams have one or even more people who are dedicated responsible for the relational model, and do the change management for the database.

though, it's sometimes nice to start with a db being generated by the O/R mapper you use. We hope to address that soon with a project converter which converts an .lgp project of dbtype A to dbtype B and with special templates it should be possible to generate a DDL script to generate the database schema from that.

Otis wrote:

PilotBob wrote:

1. Don't put the word 'entity' after all the entities.

This is done to avoid name clashes.

Name clashes with what? Can this be a name template item in the project properties? Perhaps I don't want to use the word "entity"?

Initially I didn't have any suffix like 'Entity' in the classes, but it gave too much name clashes with existing classes. The problem is: people expect the code generated by a generator to be flawless and compilable in 100% of the situations, and I understand that assumption (one reason to use a code generator is that it never makes a mistake, right? ). If it turns out the code isn't compilable or hard to use because you ahve to type long namespaces etc. to avoid nameclashes, it's not a tool which helps you, but works against you, hence the suffix

I can understand you probably would have liked code like Customer c = new Customer();

Me too, though it gave too much trouble.

Otis wrote:

That's on the list of features to add (the list is very long, I'm not sure if I can address everything in 2.0, as we have to release in a certain timeframe: we can't release v2.0 in march 2006 for example, though we can release a new 2.0 version in march with more features (free upgrade)).

Cool, is "the list" published somewhere so I don't ask for things already on the list. How about a way for users to vote for features?

No, it's not public, one reason is that the competition is reading here too (bitten by that once or twice) and we want to keep the freedom of not including features if we have to cut some features due to time restrictions.

We discussed feature voting here last week actually For some features it can be an option.

Basicly there are a couple of categories of features: 1) pain point solvers 2) new functionality which makes the tool even better 3) marketing fluff

Now, category 1 is of upmost importancy and these features are addressed a.s.a.p. in next releases. Painpoints are often things which arent there and THUS you have to go through a lot of misery to get to your goal. Category 2 is a category where I place features which are nice to have but you can live without, and category 3 is the one no-one wants to think about, but sadly enough even we have to focus on category 3 sometimes.

I think voting for features in category 2 is OK, I'll see what we can do with v2.0 after category 1 stuff is done

Though I don't mind if people suggest things which are already on my list. It tells me those features are more important than others.

pilotboba wrote:

Otis wrote:

Btw, about the code being generated: code is cheap, data is expensive. This is because code is shared among all instances, so not memory intensive, but data isn't.

True but a good point.

However the code isn't as polymorphic as it could be. Code that uses an entity needs to have that entities name in it always. I can't write the same code for my Customer that I can for my vendor even though the query would be the same basically.

Also, other mappers concrete/derived classes (I am talking two class scenerio here) are empty other than

public class MyEntity : Entity { }

I'm not sure why all the code is needed in the concrete class when it is in the abstract class. Other mappers don't have it or need it.

Though you NEED the constructors you defined in 'Entity' in MyEntity as well, if you want to use them. At least in C#, I'm not aware of a loophole in this for VB.NET but I doubt it. So if 'Entity' defines a constructor which accepts a 2 field PK, MyEntity also has to have that constructor. Remember: selfservicing is serving itself, there's no 'session' or other central blob somewhere you have to drag with you all the time.

You shouldn't even need to re-gen the concrete class once it is created.

True, that's why tehre is a generator config called base-classes only

It just seem really messy with all that code an generator comment blocks in there.

Oh, I agree, no worries about that . That's why partial classes is a think they should have added in .NET 1.0. With partial classes in .NET 2.0, I can have just 1 class with the plumbing code and it's partial, so the user can add whatever code in another partial class and be done with it.

Otis wrote:

Though you NEED the constructors you defined in 'Entity' in MyEntity as well, if you want to use them. At least in C#, I'm not aware of a loophole in this for VB.NET but I doubt it. So if 'Entity' defines a constructor which accepts a 2 field PK, MyEntity also has to have that constructor. Remember: selfservicing is serving itself, there's no 'session' or other central blob somewhere you have to drag with you all the time.

Doh! You can't inheriet constructors. You know, I knew that... just didn't think of the ramifications in your case.

You are correct, I am used to the NHibernate pattern that uses a session object which is what I am passing the parameters too.

So, with the Adapter code there are no constructors?

BOb

JimFoye wrote:

I control my db schema with scripts, and in my opinion this old DBA practice makes life a lot easier, I am really surprised more people don't do it.

Hmmm... I do to. My whole schema and static data are scripts that are checked into source control.

JimFoye wrote:

I would MUCH rather modify my master script (if early in development) or write a change script myself and just let LLBLGen do what it does best as far as generating the ORM layer. Relying on it to manage my schema is no better than relying on Enterprise Manager to manage my schema, which is bad, in my opinion, though I know 90%+ of the people reading this are doing it. No offense to anybody, of course

So, you rely on a tool to generate the bulk of your BLL/DAL. You do this because it is consistent, fairly error free and well tested right? Why don't you hand code your BLL/DAL? What do you say to others that are hand coding theirs? You tell them GET LLBLGEN Pro!

But, wait, then you want to hand code all your schema and schema change scripts? Interesting that you take two opposite approaches to development.

As I said above, I also control the schema using scripts. The difference is that I rely on tools to generate the scripts for me. Why? It is consistent, well tested and accurate. The generator makes less mistakes than I do. (Yes, there are cases where I have to hand code stuff.)

So, why can you trust LLBLGen Pro which you know saves you time, but you revert to manually creating schema changes scripts?

BOb

Otis wrote:

True, though step 2 is tougher than you might think...

Which is why I would use a tool like Db Ghost or SQL Compare to do the actual compare and create change scripts. These well established tools do this exceptionally well.

Otis wrote:

, and has a disadvantage as well: what if 2 or more developers work on the team? What to do with their change scripts?

Semantics. You have the same problems of keeping generated code and schema in synch whether you use a tool to generate change scripts or do it by hand.

I am not suggesting the LLBLGen auto-matically do this. But, and add-in tool that can synch a db to the current metadata would be extreemly useful. I'm also not suggesting this is the tool that you use to ship dbupdates to your customers.

[quote]

Otis wrote:

though, it's sometimes nice to start with a db being generated by the O/R mapper you use. We hope to address that soon with a project converter which converts an .lgp project of dbtype A to dbtype B and with special templates it should be possible to generate a DDL script to generate the database schema from that.

So, this is only one step away from my suggestion. If you can generate a db from the .lgp project then I can use a tool to create a change script from that and the previous schema rev.

I guess I may have to write it myself as an add-in.

BOb

pilotboba wrote:

Otis wrote:

Though you NEED the constructors you defined in 'Entity' in MyEntity as well, if you want to use them. At least in C#, I'm not aware of a loophole in this for VB.NET but I doubt it. So if 'Entity' defines a constructor which accepts a 2 field PK, MyEntity also has to have that constructor. Remember: selfservicing is serving itself, there's no 'session' or other central blob somewhere you have to drag with you all the time.

Doh! You can't inheriet constructors. You know, I knew that... just didn't think of the ramifications in your case.

You know, your post made me doubt if I made the right decision (I found out during the development of 1.0.2005.1, that protected methods are visible through the complete inheritance chain, I was still under the assumption that a protected method in the direct supertype, became private in the subtype (as it is in C++ if I'm not mistaken) ) so I cooked up a small class set in snippetcompiler but it was indeed not the case: constructors aren't inherited.

So, with the Adapter code there are no constructors?

There are, as there are a couple of convenient constructors to set the PK directly, pass in a validator and more of that.

pilotboba wrote:

So, you rely on a tool to generate the bulk of your BLL/DAL. You do this because it is consistent, fairly error free and well tested right? Why don't you hand code your BLL/DAL? What do you say to others that are hand coding theirs? You tell them GET LLBLGEN Pro!

But, wait, then you want to hand code all your schema and schema change scripts? Interesting that you take two opposite approaches to development.

I don't think this is a valid comparison at all. On the face of it, it is clearly a much simpler task to write a CREATE TABLE statement then it is to write all of the code for a fully functional ORM layer. And, all tools that make the schema changes (Enterprise Manager, diagram tool like Visio, LLBLGenPro 2008, etc.) ultimately generate DDL, but all in different ways and some, like EM, don't allow you to easily catch it or manage it.

If I want to create a a customer table in my database, I have to go somewhere and define all the fields and constraints, I prefer to just do it in a text editor (I use Codewright, RIP now thanks to Borland ) where I can control the formatting, how constraints are named, add friendly messages that print when the script is run, etc. This is very easy to manage, and very, very clean. Early in development I define a schema script and another script with seed data, and then as I make schema changes (frequently, of course) I just run these and they drop and recreate the entire database and seed it with data. On today's hardware that typically only takes a few seconds. These scripts are great (and easy to read) documentation of the database, and easy to give to someone else. Of course at some point I have to switch to change scripts, but again it is all very manageable.

Since the ORM layer is based upon my schema, I would not want to go hand-code it when a tool like LLBLGenPro does such a good job for me. And I prefer to have it excel in that role and not worry about managing my schema (and all of the problems associated with that). In my opinion, that would just be an extra "feature" that would distract Frans from his core mission.

Remember, all such tools eventually do their work by generating DDL. DDL is simple to write and I'd rather have full control over that myself.

pilotboba wrote:

As I said above, I also control the schema using scripts. The difference is that I rely on tools to generate the scripts for me. Why? It is consistent, well tested and accurate. The generator makes less mistakes than I do. (Yes, there are cases where I have to hand code stuff.)

What tools are you referring to, exactly? I'm a little confused, because you seem to want LLBLGenPro to do this, but you are already using something else (or more than one tool?) to do it. If you can show me a good tool, maybe you can pursuade me to give up my old ways. But I've seen a lot of shops that have trouble managing their schema because different guys are going into EM to make changes or they are passing a Visio diagram around. That's the kind of chaos I want to avoid.

JimFoye wrote:

What tools are you referring to, exactly? I'm a little confused, because you seem to want LLBLGenPro to do this, but you are already using something else (or more than one tool?) to do it. If you can show me a good tool, maybe you can pursuade me to give up my old ways. But I've seen a lot of shops that have trouble managing their schema because different guys are going into EM to make changes or they are passing a Visio diagram around. That's the kind of chaos I want to avoid.

We use Db Ghost. It is designed as a Db Change management tool. We follow there recommend procedures. So, all changes are managed as script changes that are checked into source control. It eliminates the chaos you are talking about. We love it.

What I would like from LLBLGen at the least is to gen a schema from the project's metadata. If I can do that, then yes I can use Db Ghost to generate my change script.

BOb

Fran,

At my shop we are starting a new major version of our application which is the first project that we purchased LLBLGEN Pro. However, we are going to VS 2005/.Net 2.0 for this version.

Will the API in 2.0 of LLBLGen Pro be the same so if we start working with 1.0.2005.1 we will be ok. Or is the API going to be alot different? What about the project/designer?

I think you said that 1.x customers will not automatically get betas of 2.0 like we got betas of 1.0.2005.1.

Is that the case? And if so is there any possible ways to get 2.0 betas? Do you have a target release date for 2.0?

Thanks, BOb

pilotboba wrote:

At my shop we are starting a new major version of our application which is the first project that we purchased LLBLGEN Pro. However, we are going to VS 2005/.Net 2.0 for this version.

Will the API in 2.0 of LLBLGen Pro be the same so if we start working with 1.0.2005.1 we will be ok. Or is the API going to be alot different? What about the project/designer?

It's inevitable to have a different api in some area's, like generic collections, nullable types. Though the structure of the API will be the same. Adapter will be adapter, selfservicing will be selfservicing and will work the same. So migration will take actions like migrating EntityCollection to EntityCollection<T> (or similar). Under the hood things will change of course, but for the developer this is largely hidden.

The designer will be an evolution of the current designer, so same functionality as now and more functionality, some things changed to make it better, but not upside down or suddenly a completely different concept.

I think you said that 1.x customers will not automatically get betas of 2.0 like we got betas of 1.0.2005.1. Is that the case?

Yes, 2.0 betas will be given out to selected beta-testers. Beta-testers have to actually test the code, and they'll get a free license in return.

And if so is there any possible ways to get 2.0 betas? Do you have a target release date for 2.0?

We target end of 2005 for the start of the beta, but perhaps development speed is much faster and we're done earlier, though I don't think before end of 2005 is suitable.

Who gets the beta is not decided yet.

v2.0 will have the same api as 1.0.2005.1 on board as well, so vs.net 2002/3 users aren't abandoned and can also use the new features planned for the v2.x codebase.

For .NET 2.0, some things will change, though these changes will be hidden as much as possible for the developer.

We're in exactly the same boat - we're on the verge of starting a big project using .net 2.0 and LLBLGEn (thanks to Frans persuavive ways )

Anyway, I'm happy with the beta of the latest LLBLGen, so thats what we're going with for the project. We may look at re-factoring with LLBLGen version 2 as and when it appears, but for now...happy with what we have

Just to the people who are all in that same, rocky boat: during the development of v2.0 we will have tests with users who are in a live 2005 project to see how the new 2.0 api works with their own code and how much work it will be if they migrated to the new api specs. This will then be used to keep the amount of work to be done to as little as possible. The 1.0.2005.1 beta already has partial classes, which is a big gain.

It can help also to opt for adapter, as selfservicing's api will likely change more than adapter's due to the generics (EntityCollection<Customer> is the obvious choice for selfservicing (and adapter), as CustomerCollection style collections are awkward in 2.0, because it gives a lot of code and is unnecessary due to generics)