How do I make a class library that works in ASP.NET and non-ASP.NET applications?

Question

I want to write a class library that works in ASP.NET and standalone applications. Some differences in behavior are needed when running under ASP.NET. What is the recommended way to check if the library is running in an ASP.NET application?

I can check HttpContext.Current , as it appears to reliably return null when not running under ASP.NET. However, when running on a background thread in ASP.NET, it also returns null.

Any opinions on HttpContext.Current or other solutions?

ADDED: Thanks for all the advice on how to achieve a separation of concerns. However, I would like to add that this library will not be for general-purpose use, so for my particular case I do not need a lot of flexibility. In my mind, the best so far (not mentioned in this thread) is to check the HttpRuntime.AppDomainAppId static for null as it seems to work okay even for ASP.NET background threads. However, the various solutions contributed here will surely be helpful to others with more general needs.

Answer 1

I would push all the code common to both ASP.NET and desktop applications into a core library and test this, then create libraries that sit above the core application to provide deployment specifics - your HttpContext calls for example. You can then test reliably in both scenarios, knowing you only have to test the core application block once.

With regards checking HttpContext from a background thread - this doesn't make sense and will always return null because HttpContext is defined by the asp.net request processor. If your code starts a background thread, HttpContext will be null in the new thread. Sorry about that :)

As a work around you could try adding each new session to a global collection and then call into the collection from the background thread. You'd need to be careful about synchronising access to your session collection though..

Answer 2

I think it's pretty common to separate your UI code from your application logic.

I would put all of your application logic into the shared library. Raise events from the library as appropriate. You can then handle those events in whatever app you'd like Asp.Net, WPF, etc.

If your applications needs things that might be in HttpContext, like session, you should pass those variables in as arguments to your methods so the library does not rely on HttpContext.

Answer 3

One approach you could take is to factor out the behaviors that vary between Web and non-Web applications into classes with a common interface (ie IPlatform ), then use an IOC container or dependency injection to configure your application to use the proper IPlatform implementation. However, this could be over-engineering, depending on your needs. You may want to add to your question the specific behavior you want to vary among platforms.

Answer 4

Why not, instead, have a public property that the calling code can set to tell instances of your class whether they should use the logic they intended for ASP.NET?

Accessing HttpContext when you don't really need it, along with not working right in all cases (as you've discovered), is giving that class too much reach back into its environment. Let it simply perform its job, and let the calling code tell it which set of logic to use.