Updated on August 28th to add the Virtual Path provider. Thanks, Matthew Schaad!

Introduction

This will be the first of a number of posts on ASP.NET extensibility. At this moment I don’t know exactly how many will be and I only know a couple of subjects that I want to talk about, so more will come in the next days.

I have the sensation that the providers offered by ASP.NET are not widely know, although everyone uses, for example, sessions, they may not be aware of the extensibility points that Microsoft included. This post won’t go into details of how to configure and extend each of the providers, but will hopefully give some pointers on that direction.

Canonical

These are the most widely known and used providers, coming from ASP.NET 1, chances are, you have used them already. Good support for invoking client side, either from a .NET application or from JavaScript. Lots of server-side controls use them, such as the Login control for example.

Membership

The Membership provider is responsible for managing registered users, including creating new ones, authenticating them, changing passwords, etc. ASP.NET comes with two implementations, one that uses a SQL Server database and another that uses the Active Directory. The base class is Membership and new providers are registered on the membership section on the Web.config file, as well as parameters for specifying minimum password lengths, complexities, maximum age, etc. One reason for creating a custom provider would be, for example, storing membership information in a different database engine.

   1: <membership defaultProvider="MyProvider">

   2:   <providers>

   3:     <add name="MyProvider" type="MyClass, MyAssembly"/>

   4:   </providers>

   5: </membership>

Role

The Role provider assigns roles to authenticated users. The base class is Role and there are three out of the box implementations: XML-based, SQL Server and Windows-based. Also registered on Web.config through the roleManager section, where you can also say if your roles should be cached on a cookie. If you want your roles to come from a different place, implement a custom provider.

   1: <roleManager defaultProvider="MyProvider">

   2:   <providers>

   3:     <add name="MyProvider" type="MyClass, MyAssembly" />

   4:   </providers>

   5: </roleManager>

Profile

The Profile provider allows defining a set of properties that will be tied and made available to authenticated or even anonymous ones, which must be tracked by using anonymous authentication. The base class is Profile and the only included implementation stores these settings in a SQL Server database. Configured through profile section, where you also specify the properties to make available, a custom provider would allow storing these properties in different locations.

   1: <profile defaultProvider="MyProvider">

   2:   <providers>

   3:     <add name="MyProvider" type="MyClass, MyAssembly"/>

   4:   </providers>

   5: </profile>

Basic

OK, I didn’t know what to call these, so Basic is probably as good as a name as anything else. Not supported client-side (doesn’t even make sense).

Virtual Path

The Virtual Path provider allows content to come from sources other than the filesystem (think of a ZIP file, a database, etc). That's the mechanism SharePoint uses.
In order to use it, you must implement the base classes VirtualPathProvider, VirtualFile and VirtualDirectory. Registration is done by code, typically on Global.asax.cs:

   1: protected void Application_Start(Object sender, EventArgs e)

   2: {

   3:     HostingEnvironment.RegisterVirtualPathProvider(new CustomVirtualPathProvider());

   4: }

Session

The Session provider allows storing data tied to the current “session”, which is normally created when a user first accesses the site, even when it is not yet authenticated, and remains all the way. The base class and only included implementation is SessionStateStoreProviderBase and it is capable of storing data in one of three locations:

• In the process memory (default, not suitable for web farms or increased reliability);
• A SQL Server database (best for reliability and clustering);
• The ASP.NET State Service, which is a Windows Service that is installed with the .NET Framework (ok for clustering).

The configuration is made through the sessionState section. By adding a custom Session provider, you can store the data in different locations – think for example of a distributed cache.

   1: <sessionState customProvider=”MyProvider”>

   2:   <providers>

   3:     <add name=”MyProvider” type=”MyClass, MyAssembly” />

   4:   </providers>

   5: </sessionState>

Resource

A not so known provider, allows you to change the origin of localized resource elements. By default, these come from RESX files and are used whenever you use the Resources expression builder or the GetGlobalResourceObject and GetLocalResourceObject methods, but if you implement a custom provider, you can have these elements come from some place else, such as a database. The base class is ResourceProviderFactory and there’s only one internal implementation which uses these RESX files. Configuration is through the globalization section.

   1: <globalization resourceProviderFactoryType="MyClass, MyAssembly" />

Health Monitoring

Health Monitoring is also probably not so well known, and actually not a good name for it. First, in order to understand what it does, you have to know that ASP.NET fires “events” at specific times and when specific things happen, such as when logging in, an exception is raised. These are not user interface events and you can create your own and fire them, nothing will happen, but the Health Monitoring provider will detect it. You can configure it to do things when certain conditions are met, such as a number of events being fired in a certain amount of time. You define these rules and route them to a specific provider, which must inherit from WebEventProvider. Out of the box implementations include sending mails, logging to a SQL Server database, writing to the Windows Event Log, Windows Management Instrumentation, the IIS 7 Trace infrastructure or the debugger Trace. Its configuration is achieved by the healthMonitoring section and a reason for implementing a custom provider would be, for example, locking down a web application in the event of a significant number of failed login attempts occurring in a small period of time.

   1: <healthMonitoring>

   2:   <providers>

   3:     <add name="MyProvider" type="MyClass, MyAssembly"/>

   4:   </providers>

   5: </healthMonitoring>

Sitemap

The Sitemap provider allows defining the site’s navigation structure and associated required permissions for each node, in a tree-like fashion. Usually this is statically defined, and the included provider allows it, by supplying this structure in a Web.sitemap XML file. The base class is SiteMapProvider and you can extend it in order to supply you own source for the site’s structure, which may even be dynamic. Its configuration must be done through the siteMap section.

   1: <siteMap defaultProvider="MyProvider">

   2:   <providers><add name="MyProvider" type="MyClass, MyAssembly" />

   3:   </providers>

   4: </siteMap>

Web Part Personalization

Web Parts are better known by SharePoint users, but since ASP.NET 2.0 they are included in the core Framework. Web Parts are server-side controls that offer certain possibilities of configuration by clients visiting the page where they are located. The infrastructure handles this configuration per user or globally for all users and this provider is responsible for just that. The base class is PersonalizationProvider and the only included implementation stores settings on SQL Server. Add new providers through the personalization section.

   1: <webParts>

   2:   <personalization defaultProvider="MyProvider">

   3:     <providers>

   4:       <add name="MyProvider" type="MyClass, MyAssembly"/>

   5:     </providers>

   6:   </personalization>

   7: </webParts>

Build

The Build provider is responsible for compiling whatever files are present on your web folder. There’s a base class, BuildProvider, and, as can be expected, internal implementations for building pages (ASPX), master pages (Master), user web controls (ASCX), handlers (ASHX), themes (Skin), XML Schemas (XSD), web services (ASMX, SVC), resources (RESX), browser capabilities files (Browser) and so on. You would write a build provider if you wanted to generate code from any kind of non-code file so that you have strong typing at development time. Configuration goes on the buildProviders section and it is per extension.

   1: <buildProviders>

   2:   <add extension=".ext" type="MyClass, MyAssembly” />

   3: </buildProviders>

New in ASP.NET 4

Not exactly new since they exist since 2010, but in ASP.NET terms, still new.

Output Cache

The Output Cache for ASPX pages and ASCX user controls is now extensible, through the Output Cache provider, which means you can implement a custom mechanism for storing and retrieving cached data, for example, in a distributed fashion. The base class is OutputCacheProvider and the only implementation is private. Configuration goes on the outputCache section and on each page and web user control you can choose the provider you want to use.

   1: <caching>

   2:   <outputCache defaultProvider="MyProvider">

   3:     <providers>

   4:       <add name="MyProvider" type="MyClass, MyAssembly"/>

   5:     </providers>

   6:   </outputCache>

   7: </caching>

Request Validation

A big change introduced in ASP.NET 4 (and refined in 4.5, by the way) is the introduction of extensible request validation, by means of a Request Validation provider. This means we are not limited to either enabling or disabling event validation for all pages or for a specific page, but we now have fine control over each of the elements of the request, including cookies, headers, query string and form values. The base provider class is RequestValidator and the configuration goes on the httpRuntime section.

   1: <httpRuntime requestValidationType="MyClass, MyAssembly" />

Browser Capabilities

The Browser Capabilities provider is new in ASP.NET 4, although the concept exists from ASP.NET 2. The idea is to map a browser brand and version to its supported capabilities, such as JavaScript version, Flash support, ActiveX support, and so on. Previously, this was all hardcoded in .Browser files located in %WINDIR%\Microsoft.NET\Framework(64)\vXXXXX\Config\Browsers, but now you can have a class inherit from HttpCapabilitiesProvider and implement your own mechanism. Register in on the browserCaps section.

   1: <browserCaps provider="MyClass, MyAssembly" />

Encoder

The Encoder provider is responsible for encoding every string that is sent to the browser on a page or header. This includes for example converting special characters for their standard codes and is implemented by the base class HttpEncoder. Another implementation takes care of Anti Cross Site Scripting (XSS) attacks. Build your own by inheriting from one of these classes if you want to add some additional processing to these strings. The configuration will go on the httpRuntime section.

   1: <httpRuntime encoderType="MyClass, MyAssembly" />

Conclusion

That’s about it for ASP.NET providers. It was by no means a thorough description, but I hope I managed to raise your interest on this subject. There are lots of pointers on the Internet, so I only included direct references to the Framework classes and configuration sections.

Stay tuned for more extensibility!