The changes from v1.2 to the current one (v2.0) are:

• Now using NHibernate 2.0.0 CR1.
• Fixed a bug that caused the provider to look for the configuration settings only in the nhibernate config section. If you configured NHibernate using the hibernate-configuration section, it didn't work.
• Fixed a bug that prevented hashed passwords to work without supplying a password answer.
• Some code refactoring/clean up.
• Removed all FXCop warnings.
• Changed the mapping generation for the NHCustomMembershipProvider. In NHiberante 2.0.0 CR1, it is not possible to create mappings programatically as before, so now a xml document with the mapping is created.
• Fixed a bug in ChangePassword and ResetPassword methods that made the stored password answer useless if the provider was using hashed format with password salt.

From some questions/emails I've got, it seems that some people aren't using the provider the way it was designed. There is no need to modify the code in the provider to support custom fields for your Users or Roles. I have created a sample that uses all the fields in the membership provider and adds some custom fields to show how the provider should be used. The sample also uses the CreateUserExWizard control in order to create an user.

As always, feedback is welcome. It has been tested only in SQL Server 2005. Let me know if you try it in other databases.

The binaries and source code can be downloaded here

One of the tools I’m using is NDepend (http://www.ndepend.com/). It is a cool application that can be used for a lot of things, as will be detailed later.

To use NDepend you have to feed it with a set of assemblies. After that, it will analyze those assemblies and their reference assemblies. If the PDBs of the assemblies are available it will use them so more data is analyzed, although the PDBs are not needed for NDepend to work.

After the analysis has been completed, NDepend looks like this:

I have used version 1.1 of Spring.NET Framework (http://www.springframework.net/) for the sample. As you can see the application has a beautiful GUI. I’ll talk a bit about the main windows of the tool:

• Metrics: this window gives a graphical high level view of the project. You can see a lot of ellipses and some of them that are made of smaller ellipses. The big ellipses are types of the project. If a big ellipse is made of several smaller ellipses, those smaller ellipses are the methods of the type. The types of the same namespace are distributed in the same rectangular region, separated by a small yellow line. The assemblies are separated by a thicker yellow line.

By watching this window you can get an idea of which assemblies contain more code, which types are big, which types have a lot of methods, etc. The window was in “Method Level”. The available levels are Assembly, Namespace, Type, Method and Field.

• Class Browser: this is where the assemblies of the project and its referenced assemblies are shown. You can expand the assembly up to the field level. While you hover over an item in most windows, the Metrics window gets updated highlighting the hovered item.

What it’s really cool about the Class Browser is that for the referenced assemblies, only the namespaces, types, methods and other items that are used by the project are shown.

• Info: When you hover over an item the information about it is displayed here, with some metrics if applicable. There are a lot of metrics so it can take time to interiorize them and judge their value appropriately.

• Dependencies: this window is a bit intimidating at first but like a lot of things, with a bit of effort you can master it. The window displays very important information of the dependencies in a matrix form. As in other windows, the detail level is selectable, from the assembly level to the field level.

A cell can have 3 colors. Blue means that the associated item in the top header uses the associated item in the left header. Green means that the associated item in the left header is using the associated item in the top header. Black means a cyclic dependency. The blue and green cells express the same dependency using opposite points of view.

You can see a diagram of the dependencies clicking on a cell. For example, if you click in the cell corresponding to System.Web.Extensions and System.Web you get this:

To read more about the theory of dependencies take a look here:

ttp://www.theserverside.net/tt/articles/showarticle.tss?id=ControllingDependencies

• CQL Queries: CQL stands for Code Query Language and it is a central piece of NDepend. Being able to ask questions about the code is great. If you like using the Analyzer window in Reflector you’ll love this. You can create new queries and modify the existing ones.

I have presented the main NDepend windows, but the main question is: what you can do with NDepend?

There are several uses that I can think of:

• It is an excellent tool to check differences between different builds of an assembly. You can use it as a diff tool, as it will show in the Class Browser which types, methods, etc have been added, removed or changed. This information is also available for CQL Queries, with the power that it implies.

• It can be used to understand code. When you are thrown with code that you have no clue about how it works you have several options to accomplish that task:

1. Look at the source code directly.
2. Make some diagrams from the source code (for example, using View Class Diagram in Visual Studio).
3. Use NDepend.

These methods are not exclusive, and probably you’ll use a combination of them to understand how the code works. However, the abstraction level is higher when you use NDepend is higher than when you use a Class Diagram (and a Class Diagram is a high level view compared to raw source code).  I’d use NDepend to have a global vision of the main assemblies, type most used, dependencies between namespaces, more complex methods, etc. and then focus my attention in the most important parts of the application, going to a lower level of detail.

• It can be used in the refactoring process, to see the impact of a change, and to keep dependencies to a minimum, in order to have a project that is easier to understand and maintain.

• Integrating NDepend in the software development process. IMHO this is a key point, as using NDepend regulary will certainly improve the quality of the software that is being developed.  NDepend can generate a report of a project. A sample report is available here:

http://www.ndepend.com/SampleReports/OnNUnit/NDependReport.html

There are a lot of sections in the report, but I’ll concentrate on the section called “CQL Queries and Constraints”. That section is really important as it shows a list of items that can be problematic or don’t follow the standards of your company (methods with a lot of lines of code, very complex methods, poorly commented methods, types or methods or properties or fields with incorrect naming conventions, etc). This way the project leader can make periodic checks of those problems and report them to the people that are responsible for them.
This also allows you to know more the people you’re working with. Some developers don’t comment code, others like to make very long methods, and others tend to write complex logic that is difficult to understand by others. With the review of the report, they can be instructed so the resulting code and comments is better and more uniform.

However, there are times where a method with more than 30 lines of code is necessary. Or a method with a cyclomatic complexity of 25 is needed. So it is up to the project leader to review the suspicious method and inform the developers of the problem or simply acknowledge that it is necessary.

Unfortunately, NDepend does not provide built in support for this level of detail of project management. I have been told that in a future version it will provide hooks so custom scenarios like the exposed above are fully supported.

So, after what I have said about NDepend, you can be thinking, is it for me? Well, that depends on a lot of factors. I know a lot of companies that have no interest in achieving high quality products and that they only care about having a project done as soon as possible. If the maintenance of that project is a nightmare, well, that is another problem for another moment. However, there are some companies that actually spend time and effort to produce excellent products, so they may be interested in what NDepend can add for them.

I have used NDepend in several projects that are widely used when learning about it, and I found something curious:

The image shows that almost all of the NHibernate code has a big dependency cycle. I wish them good luck making the transition to ASTs.

To finish this post, I have to say that I have received a free professional version of NDepend. This has not conditioned my post about it. If I think it was a useless product I will not have posted about it.

Due to lack of time I haven’t been able to make a sample website showing a complete usage scenario for my NHibernate custom Membership and Role providers. However, as there are nearly 100 downloads per month and there is some people using it I’m uploading a new version. The changes from the latest release are:

• Fixed an important bug that didn’t prevent locked out users from login in.
• Added a CreateUserWizardEx control that allows creating a user with extra information in an easy way.
• Added auto unlock support.
• Fixed some minor bugs/typos.

I’ll detail a bit the new features. The standard CreateUserWizard control generates an event before creating the user (CreatingUser) and one after the user has been created (CreatedUser). Somewhere between these two events the control calls the CreateUser method of the membership provider. The CreateUserWizardEx control extends the CreateUserWizard that ship with ASP.NET 2.0. It is supposed to be used when you want to insert a user in the system without using the CreateUser method of the membership provider (for example, because you want to store more data in the database).
 
The CreateUserWizardEx control adds a CreateUserEx event. You should handle this event, retrieve all the information for the new user and make the insert in your users table manually (as the provider interface can’t handle extra data). This event will be generated after all the password checking and generation have been made, so you only have to insert the user in the database. When you handle this event, you’ll be passed an instance of the CreateUserExEventArgs class. This class has 3 properties: EncodedPassword, EncodedPasswordSalt and EncodedPasswordAnswer that are useful if you’re not storing the sensitive data in plain text. After the CreateUserEx event is generated, the CreatedUser event is also generated.

There is one little problem with the CreateUserWizardEx control. Because quite a bit ASP.NET classes (especially controls) haven’t been designed with extensibility in mind, it is impossible to override some of the behavior of the CreateUserWizard control to achieve the desired result. In this particular case I can’t make the control to skip the CreateUser call to the membership provider in any way without rewriting the full control (the CreateUserWizard is one of the lengthiest controls in ASP.NET this is not an option). So the only solution without compromising medium trust scenarios is to ignore the CreateUser method calls in case you plan to insert the users manually. To do this you have to set the provider attribute ignoreCreateUserMethod to true. If the CreateUserWizard control is ever rewritten with extensibility in mind this hack could be removed, but I don’t think that will happen anytime. I posted about similar lack of extensibility problems here.

The auto unlock feature is useful if you use locking. If a user fails entering the password several times in a predefined period of time (specified by the maxInvalidPasswordAttempts and passwordAttemptWindow properties) his account gets locked out. However, you need human interaction in order to unlock the user.

If the auto unlock feature is enabled, when a locked user tries to log on the system, if the data supplied is correct and a certain period of time has passed since the account was locked out, the provider automatically unlocks the account. To enable auto unlocking you have to specify enableAutoUnlock="true" in the web.config. The provider property autoUnlockMinutes controls the minium period of time to wait since the last failed login to be able to auto unlock an account. The default is 30 minutes. Note that setting this value too low can make the security benefits of having a lockout feature disappear.

I’m thinking in adding some code to enforce single user log on for the next version as time permits (don’t expect this to be implemented in 2007).

As always, feedback is welcome. As the previous version, it has been tested only in SQL Server 2005. Let me know if you try it in other databases.

You can download the providers here.

Ayende has apologized for the way he resolved a NHibernate bug I reported. I’m glad he has changed his mind. I feel a lot of respect for people that can admit a mistake.
 
He also commented about the NHibernate limitations I pointed out. As he knows what the NHibernate team is working or is planning to work on, it is a very interesting read.
 
Regarding points 2 (old design) and 5 (hierarchical queries), it seems that they’re planning to make manipulations at the AST level, leaving the SQL generation as late as possible. This seems as a very powerful change so I hope to see that change flowing through the core to improve things.

It seems that point 3 (more events in IInterceptor) will be addressed by some changes that are being performed by Fabio Maulo. Cool!

I think I was wrong with point 1 (being too tied to the Java version) as Ayende explains.
 
Regarding point 4 (no paging support in some nontrivial scenarios), I think that paging when you retrieve an associated relationship eagerly should be supported. However, if the subselect problem is fixed (so not all rows from the association are retrieved), that certainly makes it less important. I was also referring to the limited paging support for SQL Server 2000. However, I’m lucky to not be using SQL Server 2000 anymore…

To sum up, the things the NHibernate team is planning for the future have made my NHibernate interest grow up a lot since my rant about it.

Ayende also mentions to try to fix bugs when you found one. I can’t agree more, however, in my personal case, I have to spend about 3 hours a day to make exercises for my back in order to be able to work with the computer without too much pain. That means that my free time is really limited and probably away from the computer :-(

NHibernate is a popular and free ORM tool. It is based on the java version, called Hibernate, which is also very popular in the Java world.

However, NHibernate (I’m talking about version 1.2.0 GA here) has some limitations. Some of them that are in the top of my head at the moment:

1) It is heavily tied to the java version (Hiberante), so a lot of the request and/or enhancements are ignored. If the java version is not going to add it, probably it will not be added to NHibernate.
2) Hibernate was started in 2001, and was designed to overcome a lot of the ORM problems. During these years, it has solved a lot of those problems, but other still remain and they can’t be fixed without heavily changing its design.
3) Even if it is extensible, the IInterceptor interface does not expose all the events that can be interesting to capture (For example, events after loading, updating or deleting data). The only way to handle that at the moment is to implement the ILifecycle interface by the entity itself, losing entity transparency.
4) No paging support in some nontrivial scenarios.
5) There is no support for retrieving all the data at once for hierarchical queries.

Let’s see a simple example:

Imagine that I have some orders with their respective order items. I want a customer to be able to see all orders he has placed on the system, with their associated order items. As a customer can have a lot of orders, only 10 orders will be displayed per page.

ISession session = SessionFactory.OpenSession();
ICriteria criteria = session.CreateCriteria(typeof(MyOrder));
criteria.SetFirstResult(0);
criteria.SetMaxResults(10);
criteria.AddOrder(new Order("Id", true));
IList<MyOrder> orders = criteria.List<MyOrder>();

Using lazy fetch mode, NHibernate does:

Gets the first 10 orders using a single select statement.

Gets the order items for the first 10 orders using one select statement for each order.

Using subselect mode, NHibernate does:

Gets the first 10 orders using a single select statement.

Gets the order items for ALL the orders using a single select statement.

To clearly see what NHibernate does when using the join (eager fetch) mode, imagine that all orders have 3 order items.

In that case, what NHiberante does is a left outer join of the order and orderitems table, returning the first 10 rows of that join. That means that NHibernate returns only 4 orders, the first three with 3 order items each one, and the last one only with one order item. Take a look at the code, I was asking for 10 orders, and only got 4, and the fourth is not filled with its three order items, only with one!

I added this as a bug in the NHibernate bug tracker, and I received a quick reply of its main developer, Sergey Koshcheyev, confirming me that NHibernate wasn’t able to perform that query right because of the inner join, and didn’t know if it should raise an error in that case or not. Nearly the same time Ayende Rahien closed the case because that was the “expected behavior” because that is what is happening on the DB side and that there wasn’t any way to get the data I was asking for.

That response is completely wrong:

1) I’m asking NHibernate to get 10 orders and specifying a fetch strategy so what I should get is 10 orders. Depending on the fetch strategy NHibernate may perform one select, several selects, a join or whatever it needs to, but at least I expect to get 10 orders (if there are present in the database table).

2) It is possible to retrieve the proper data, and I added an example of how to do it in the bug report.  If NHibernate can’t handle it, that is another story…

You can take a look at my bug report and its resolution here and decide yourself if this was a good resolution or not:

http://jira.nhibernate.org/browse/NH-1123

If you have read Ayende’s blog you'll know that he has complained several times about how Microsoft Connects resolve some bugs (I agree that he is right and that they should be fixed), but after his bug resolution, it seems a bit ironical to see him complaining about that…

I see NHibernate as a great product (and free) but as its codebase was started in 2001, it has get old. I will continue to use it but I’m evaluating other alternatives (any suggestions (even if they are not free)?).

Searching out there, I found a project that has really impressed me: SqlAlchemy. This is the philosophy of the project:

SQL databases behave less and less like object collections the more size and performance start to matter; object collections behave less and less like tables and rows the more abstraction starts to matter. SQLAlchemy aims to accommodate both of these principles.

SQLAlchemy doesn't view databases as just collections of tables; it sees them as relational algebra engines. Its object relational mapper enables classes to be mapped against the database in more than one way. SQL constructs don't just select from just tables—you can also select from joins, subqueries, and unions. Thus database relationships and domain object models can be cleanly decoupled from the beginning, allowing both sides to develop to their full potential.

SqlAlchemy first release was in 2006. The first version did support what Nhibernate is not able to do:

http://www.sqlalchemy.org/docs/03/adv_datamapping.html#advdatamapping_limits

So it seems that it is possible after all…

I’m very impressed with SqlAlchemy. However, SqlAlchemy currently is only available for python. I hope it works properly with IronPython 2.0 (whenever it is released). Although a C# version using C# 3.0 features would be a killer.

You can see an example of the power of SqlAlchemy here:

http://spyced.blogspot.com/2007/01/why-sqlalchemy-impresses-me.html

For more information about SqlAlchemy visit:

http://www.sqlalchemy.org/

I have updated my Membership and Role provider that use NHibernate for data access. The changes are minimal. Now I'm using NHibernate 1.2.0 GA and a minor fix. The instructions and the code can be found here

This will be my last post until I return from London. Excuse me if I'm unable to reply to non critical emails in the next few days.

Usually, the built-in providers for ASP.NET do not integrate very well with existing applications. The membership provider has a very complex structure that in most cases is not needed at all. The following diagram shows most of the tables and relations for the built-in ASP.NET providers:

The membership related tables are selected in red and the role related tables are selected in blue. The default membership and roles provider have support to store data for multiple applications using the aspnet_Applications table. I think this table was introduced because some portal frameworks like dotnetnuke needed the ability to store membership and role data for multiple users in a single store because they support multiple portals. If you don't need this scenario (and most applications do not need it), this only complicate things.

Also, the built-in providers use tables that are not part of your application tables, and some of those tables have quite a few columns, and probably some are not needed by your application.

If you do not use SQL Server, you can not use the default providers, so that is a big showstopper.

To overcome all of this problems I have created a custom membership and role provider that use NHibernate and can be easily integrated with existing or future applications using your own tables.

The reference book about providers is:

Professional ASP.NET 2.0 Security, Membership, and Role Management.

I suggest you to read it if you really want to get deep into providers as it is an excellent book.

The NHCustomMembershipProvider uses NHibernate to do all membership related database operations so it should work on all databases supported by NHibernate. The membership data will be stored and retrieved from a table configured in the provider section in the web.config so you can map it to an existing table like users. The column names for your user table can also be configured in the provider section. The cool thing about the provider is that it adapts its behaviour to the number of columns supported by your data store. For example, if you use the provider and map it to your users table where you only have the membership data for userId, userName, password and email, it will work without any problem. If your data store supports more advanced options of the membership provider like account lockout, password question and answer, password salt or last activity date, that advanced functionality will be automatically available, but it is not required.

The provider knows what functionality to offer based on the number of columns that are mapped to your data store. To support account lockout when the user do not supply a valid password after some tries in a predefined period of time you need to map the isLockedOutColumn, failedPasswordAttemptCountColumn and failedPasswordAttemptWindowStartColumn to columns in your data store.

The default configuration for the provider is to use integer identities or sequences for the user identifier, but that can be changed using the userIdType and idGeneratorClass properties in the provider configuration section.

If you use the provider with an existing user table, probably you will create the users manually without using the CreateUser method from the membership provider. The provider exposes the methods CheckPasswordPolicy, ValidatePassword, EncodePassword and GenerateSalt to allow manual creation of the user in case you need it, without sacrifying password strength.

To finish with the custom membership provider lets see an example. If you want to use the membership provider with a table like this (that has columns for all supported functionality):

The configuration section for the membership provider will be something like this:

   
The column sizes are optional but it is a good practice to fill them.

The built-in provider raises events after a succesfully or a failed login. However, ASP.NET 2.0 does not allow to create or raise built-in health monitoring events, so I had to use reflection in a private method in order to raise the same events. That means that the provider will not run in medium trust if it is not installed in the GAC if you want to raise the system events. As this can be a showstopper to some people I have added an option to disable system events generation (raiseSystemEvents).

The provider reads the config section and programatically generates a mapping for the specified columns in the ConfigureNHibernate method. The provider expects that you have configured NHibernate in the web.config to work. If you need extra configuration for the provider you can inherit from the provider and use override the ConfigureNHibernate method, modifying the Configuration object that the base class returns.

The NHCustomRoleProvider is also configurable in order adapt to your own tables. It only needs a Users table with id and user name columns, a roles table with id and role name columns, and a join table used to store the information for the many-to-many relationship between the users and roles.

For example, if we the previous user table with the following tables (FKs omitted for brevity):

The configuration section for the role provider will be something like this:

Note that the id columns in the join table need be named as in their respective tables in order to work.
   
Programatically creating the mapping using the CreateMappings for something more complex than a single table seems to be something very tied to the NHibernate implementation so I opted to create a XmlDocument with the mapping read from the configuration settings as it seems to be the best thing to do in complex cases.

One of the problems I faced with the NHCustomRoleProvider is that some times I wanted to save or delete data from one side of the many-to-many relationship but in some cases I wanted to use the other side. If you know a bit of NHibernate you know that the inverse attribute controls what side of the relationship has to be used in order to have changes persisted. As I was generating the mapping dynamically I created two session factories, one with the inverse set to true on one side and the other with the inverse in the other side. That way I open a connection in the session factory that has the mapping with the inverse in the side of the relationship I want.

I'd appreciate usage feedback, suggestions, bug reports, etc. I have only tried these providers with NHibernate 1.2.0 GA and the MsSql2005Dialect so let me know if it works in other configurations.

Please do not store the providers in your server. Link to this page instead. Updates to the providers will be posted in this page.

History

v1.0 - 08/04/2007

v1.1 - 21/06/2007

• Now using NHibernate 1.2.0 GA
• Some minor fixes

v1.2 - 12/10/2007:

• Fixed an important bug that didn’t prevent locked out users from login in.
• Added a CreateUserWizardEx control that allows creating a user with extra information in an easy way.
• Added auto unlock support.
• Fixed some minor bugs/typos.

For more details about the features introduced in version 1.2 take a look here.

v2.0 - 01/08/2008:

For more details about the features introduced in version 2.0 and a sample of its usage take a look here.

NHCustomProviders_bin.zip (67 KB)
NHCustomProviders_source.zip (122 KB)