I'm writing a code library that needs to be reused between a Windows Forms 
application and and an ASP.NET Web application.

The library needs to do a couple of things differently depending on the type 
of application the library has been loaded for.

What is a reliable and non-hacking way for the code to make that 
determination (hosting application type)?

Using .NET 3.5

Thanks

Smithers,

    One way I know of is to set a reference to System.Web.dll and then check 
the static Current poperty of the HttpContext class.  If this returns null, 
then there is no HttpContext, and no ASP.NET.  Of course, this is only 
applicable if you are actually processing a page.  Calling this outside of a 
request pipeline in ASP.NET will still return null, so if you need this for 
one-time initialization, you might have to look for another option.


-- 
          - Nicholas Paldino [.NET/C# MVP]
          - mvp@spam.guard.caspershouse.com

"Smithers"  wrote in message 
news:emfthEQ2HHA.5160@TK2MSFTNGP05.phx.gbl...

> I'm writing a code library that needs to be reused between a Windows Forms 
> application and and an ASP.NET Web application.
>
> The library needs to do a couple of things differently depending on the 
> type of application the library has been loaded for.
>
> What is a reliable and non-hacking way for the code to make that 
> determination (hosting application type)?
>
> Using .NET 3.5
>
> Thanks
> 

Well, ASP.NET often has an HttpContext.Current, but note that 
personally I find this a bit hacky. It also doesn't work for things 
like WCF hosted in IIS. I generally prefer to use a provider model, 
where-by those bits that depend on the architecture are abstracted 
through an interface (with some mechanism to register and obtain the 
provider); in the web app I register one provider (perhaps using an 
HttpModule to configure via web.config), and in the client I register 
another.

But I guess it depends on how big the change is...

Marc