From a managed class library, I\'d like to find out whether the currently executing application is an ASP.NET web application (web forms or MVC) or not.
I have seen diff
Potentially Not reliable. MSDN implies that this will always return a new object if one does not exist already. Thus there are technically times where you can call it and have one not exist before it is called.
System.Web.Hosting.HostingEnvironment.IsHosted == true
All web environments need a context. What handler is inside that context is what tells you the type of web environment. (MvcHandler for example). Note this can be different types of handlers for the same environment - You can run MVC and web forms together for example. It just depends on what is currently being served and the pipeline it is using.
System.Web.HttpContext.Current != null
All web apps need an application ID. It is unique and does not change as application pools are restarted.
System.Web.HttpRuntime.AppDomainAppId != null
I've never seen this, though just logically I can imagine a time where the cache is not used and thus wouldn't be reliable.
System.Web.HttpRuntime.Cache != null
You're right.
checking for a web.config file (note: I don't think this is reliable)
I use something of this sort within a library. I've found it reliable.
Page page = (HttpContext.Current != null && HttpContext.Current.Handler != null) ? HttpContext.Current.Handler as Page : null;
if (HttpRuntime.AppDomainAppId != null && page != null)
{
//I'm a web forms application
}
else if (HttpRuntime.AppDomainAppId != null && page == null && HttpContext.Current != null) { throw new InvalidOperationException("I'm an MVC application"); }
else throw new InvalidOperationException("Im not ASP.Net web");
First, I agree that the question is "wrong." Your library shouldn't care. Second, as below, there's a number of heuristics but ultimately no really good way to know. Your question doesn't make it clear why you want to know or a validation for that.
That said, if it were me, I'd probably look at System.Web.HttpContext.Current if I cared about the current request, or System.Web.HttpRuntime.AppDomainAppId if I wanted a general check.
NO GUARANTEES. This is likely a bad idea.
From Stefan on the ASP.NET team:
If it’s a web app, and its running managed code, 99.9999% likelihood its ASP.NET -). If he means something different such as looking at the IIS metabase and trying to figure out if an application is really an ASP.NET app or not – then some kind of heuristics would be needed. For example, for a given application in the IIS config/metbase, get the physical root of the application – then look and see if web.config, *.aspx, *.ashx, etc… exist in the folder, or any of the subfolders. If the answer is yes, then it is likely an ASP.NET application. Unfortunately it is not sufficient to make this determination just off of configuration data stored by IIS. Every application pool has an associated CLR version, even if no managed code ever runs in the application pool. And the second ASP.NET integration with IIS is enabled on a machine, the default module/handler lists all include ASP.NET entries.
In the case of a library, the heuristic I described would be the way to go.
In present times though, what’s “an ASP.NET application” anymore? These days I can stick classic .asp, ASP.NET, static HTML, and php all into the exact same vdir structure and have it all function semi-coherently as a single "application".
I have to question your goal here: Why should the library be aware of what kind of application it is running from?
To me, it sounds like you need to split the relevant part of your library in two parts - one for use with web apps, and one for use with winforms apps. (And possibly a third part, with everything that can be used by both types of apps...)
This might be helpful:
How can I detect if my .NET assembly is running from web site or from a desktop machine?
if(HttpRuntime.AppDomainAppId != null)
{
//is web app
}
else
{
//is windows app
}