I want to make the ut for some business module. I create a class library to write ut cases. THen run NUnit.GUI and load the dll file, but the result is wrong:

becase in this file, the httpcontext is null...


public static ISession GetCurrentSession()
{
HttpContext context = HttpContext.Current;
ISession currentSession = context.Items[CurrentSessionKey] as ISession;
if (currentSession == null)
{
currentSession = sessionFactory.OpenSession();
context.Items[CurrentSessionKey] = currentSession;
}
//ISession currentSession = null;
return currentSession;
}

========================================
But when I run the NUnit, it's only a windows application and no httpcontext...

How to solve this problem?

This isn't really an NHibernate related question, but my $0.02

You have one of two choices: either remove the dependency on HttpContext from your .dll (highly recommended!) or if you cannot do that because of other constraints, then "wrap off" the areas that do depend on it so that they fall back to the CallContext.Items when HttpContext.Items is not available. Or course, the latter solution presumes that you haven't referenced other ASP.NET specific structures that have no analogue outside it.

I'm not sure where you got that code but I don't believe that it is NHibernate code. Its not a problem with NHibernate at all, its a problem with your architecture. I'm sure that you can see it wont work in NUnit because there is no HttpContext.

Sounds like you need a session manger that is smart enough to determine the appropriate context. Check out the NHibernate facility over at the castle project.

I got the codes from Hibernate manual (.pdf).

So When use NHibernate in Windows application, how to create the interface to NHiberante? No HttpContext?

That code was never intended for inclusion in a .dll. It is included as merely a suggestion for session mgmt in ASP.NET. You'd use completely different patterns for a Winforms app.

I tend to agree with jnapier, your architecture is way off. Your .dll shouldn't be doing Session management of that nature, and it should certainly not be bound to ASP.NET like that. That is something that should be done to some extent in the consuming application, mainly because the function of said application will usually dictate the optimal pattern, not the underlying domain.

It's nice that you have a separation of concerns, but you need to separate the right concerns.