There are some points from one of the discussions around:

First: If team uses microsoft's team foundation server instead of SubVersion they don't like that every file is rewritten every time project is generated althought code has not changed in the file.

TFS marks the file as changed what's really annoying. Maybe opinion to generate project such way that only changed files would be replaced would help.

Second: They (and me too) would welcome, if there would be and easier way in to map EntityField to an enum In Designer. I think it's now possible with Custom Types but i'm not sure. Predicate expressions (and Linq Queries) like (MyEntity.CodeSomething == SomeEnum.Value) looks much cooler than MyEntity.CodeSomething == (int)SomeEnum.Value.

And it would provide better support for Intelli Sense as well as guarantee that EntityField can have only values from allowed range.

Not life-important but it would make things easier.

Third: project file is binary file what complicates source control in larger teams. If two users made some changes to the same file, is there any option to merge or compare projects? Some kind of diff report between two project would be great. Something similar to the one we get after refreshing catalog.

Liero wrote:

There are some points from one of the discussions around:

First: If team uses microsoft's team foundation server instead of SubVersion they don't like that every file is rewritten every time project is generated althought code has not changed in the file.

TFS marks the file as changed what's really annoying. Maybe opinion to generate project such way that only changed files would be replaced would help.

Please switch off emitting time in the output in the Project properties ('TdlEmitTimeDateInOutputFiles') That should fix your problem.

Second: They (and me too) would welcome, if there would be and easier way in to map EntityField to an enum In Designer. I think it's now possible with Custom Types but i'm not sure. Predicate expressions (and Linq Queries) like (MyEntity.CodeSomething == SomeEnum.Value) looks much cooler than MyEntity.CodeSomething == (int)SomeEnum.Value.

This is added in v3. Enum support is transparent in the designer in v3. You can define typeImports files which define where enum types should be harvested from and you then can define type shortcuts to easily map a field type to an enum without a type converter.

And it would provide better support for Intelli Sense as well as guarantee that EntityField can have only values from allowed range. Not life-important but it would make things easier.

That's then guaranteed indeed.

In v2.6 you can use enums through type converters, though it's less easy, as you first have to write the type converter.

Third: project file is binary file what complicates source control in larger teams. If two users made some changes to the same file, is there any option to merge or compare projects? Some kind of diff report between two project would be great. Something similar to the one we get after refreshing catalog.

v3 has an xml based project file, which is designed to be easily mergable (so everything is stored at the same place) and easily readable (so not xml as with SOAP xml exported files, but normal xml files). So that would indeed solve your problem. We know the binary project file format is a pain, we tried in the past to create a merge tool for this, but this turned out to be too complex. With the xml project file you don't have this problem.

A lot of other things nhibernate users don't like is also addressed like model first (oh and v3 will support nhibernate out of the box, you can easily switch your project from one framework to the other).

Just a few months patience and beta starts

Those enums in point 2. will make life indeed easier.