Brian Mishler on .Net - Asp.Net Providers

How to implement a Custom Provider in a WinForms Application

Brian Mishler — Sun, 04 Feb 2007 03:51:37 GMT

Since we always see the “Provider Model” used in the context of Asp.Net applications (Membership Provider, Roles Provider, Etc.) we often think of this as something that is available only in the Asp.Net world. It was recently mentioned to me that there are no good source code examples for custom providers in the Winforms space and that the Asp.Net examples utilize the System.Web.Configuration.ProvidersHelper class to instantiate the provider.

While there are several other blogs that talk about bits and pieces of this subject, I thought I might create a start-to-finish Windows Forms Application that illustrates how one can effectively use the provider model. I wrote the solution in Vb.Net and have included it in the attached zip file.

Advance disclaimer: When I started into this, I thought to myself “of course you can do this without any of the System.Web classes” and, in fact, you totally can with just a little bit more work than I put into this. I cheated a bit by dropping in a reference to System.Web in order to gain access to System.Web.Configuration.ProvidersHelper to deserialize my provider elements, but this is only because I am lazy and was copying code from another project. That class is doing nothing fancier than standard deserialization of XML into an instance of a class. Besides: Who says you can’t reference System.web from a Winforms app?

So, consider this scenario:

You develop a Winforms Application and have some standard functionality, business rules, etc. For example, your application calls a method that returns a standard report. Knowing that down the road, each one of your customers is going to want to change the way that report works, you decide to build the reporting class using the provider model. This way, you can later build a custom DLL that implements the same interface as the reporting class (but with unique functionality) and can be installed by simply copying the DLL to the application folder and then making a change to the application configuration file (myapp.exe.config.) Every customer can get his/her own unique reporting DLL and the main application never needs to be modified.

In a nutshell, this is how you do it for an existing class:

Step 1: Create a base “mustInherit” class which has the methods (but no code implementation) of your current class. In the COM world, this is analogous to an Interface. Now, modify your class to inherit from this new base class.

Step 2: Create classes that will be used to deserialize information in your app.exe.config. These will derive from classes in the System.Configuration namespace and will include one for your configuration section, one for a collection of provider settings and one for the provider settings itself. Doing this will result in a strongly typed system for referring to your list of configured providers and their respective settings at runtime.

Step 3: Modify your main application so that rather than instantiating that existing class as you might have done before, you instead ask the configuration manager to use the information in yourapp.exe.config to load up your custom section and give you back an instance of the provider which has been dubbed as “the one to use.”

To illustrate this process, I have whipped up a very simple base provider “MyProviderBase” that exposes a single method: “GetProviderSpecificMessage()”. I then have two separate implementations: “MyFirstProvider” and “MySecondProvider”, each of which handles GetProviderSpecificMessage() in its own way. (While all of this is pretty basic stuff, the interesting part is where you enable selective usage of one or the other implementations through settings in the configuration file.) A tiny winform application, consisting of a button on a form does nothing more than load the appropriate provider and call its “GetProviderSpecificMessage” method.

With the configuration file set up to use the first provider, the output is as shown in the following message box. (Notice that defaultProvider=”MyFirstProvider” in the application configuration file shown below.)

Big note: In your solution, the file called app.config will be deployed as yourapplicationname.exe.config when you build. When you distribute the application, just drop this config file into the same folder as the exe.

Now, do nothing more than change the configuration file to set defaultProvider=”MySecondProvider” and you get a totally different result when you run the program.

For a top-down look at the implementation, I will first talk about the winForm app (which I wrote last) and then about the provider implementation. As you can see, the solution is very basic.

The WinForm Application:

Start a new Winform project and drop in a button control. In the button’s click event, get the implemented provider, call its GetProviderSpecificMessage method, and display its result in a MessageBox. Here is the code:

Imports QualityData

Imports System.Configuration

Imports System.Web.Configuration

Public Class Form1

Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click

Dim provider As MyProviderBase = GetProvider()

If Not IsNothing(provider) Then MsgBox(provider.GetProviderSpecificMessage)

End Sub

Private Function GetProvider() As MyProviderBase

' get reference to configuration section for our provider

Dim section As MyProviderSection = CType(ConfigurationManager.GetSection("myProvider"), MyProviderSection)

If Not IsNothing(section) Then

' load registered providers and get reference to default provider

Dim providers As New MyProviderCollection

System.Web.Configuration.ProvidersHelper.InstantiateProviders(section.Providers, providers, GetType(MyProviderBase))

Return CType(providers(section.DefaultProvider), MyProviderBase)

Else

Return Nothing

End If

End Function

End Class

Another big note: This is the place where I used the shared ProvidersHelper.InstantiateProviders method in the System.Web.Configuration namespace to walk through my section and instantiate each of the listed providers. I don’t know why Microsoft did not put the ProvidersHelper class into the System.Configuration assembly but it is really not such a big deal to have to get to it in System.Web. If I get around to it, I might go for extra credit and write my own InstantiateProviders method by enumerating the elements and instantiating each provider based on its type.

The Application .config file

Here is the application’s config file (mine is called WinformProviderSample.exe.config.)

<?xml version="1.0" encoding="utf-8" ?>

</configSections>

<!-- Here are one or more providers, each defined by its type "Class Name, DLL Name"

and each with settings. Within the class, MyProviderSection, these get loaded into

and are accessed by "Providers" property -->

<add name="MyFirstProvider"

type="QualityData.MyFirstProvider,MyProvider"

TheCustomSetting="This is the first provider setting value in app.config" />

<add name="MySecondProvider"

type="QualityData.MySecondProvider,MyProvider"

TheCustomSetting="This is the second provider's setting value in app.config"

TheExtraMessage="..And here is some extra information to configure the second provider!!!!" />

</providers>

</myProvider>

</configuration>

Notice that I have listed two providers: MyFirstProvider and MySecondProvider. As illustrated, the configuration file is set up to use the second.

Each of the provider elements has a name as well as a type attribute. The latter is structured as “ClassName,Assembly” where “ClassName” (QualityData.MyFirstProvider) is the fully qualified class name including the namespace and “Assembly” is the name of the assembly (MyProvider.dll) without the “.dll”. You can tell that both classes are contained in the same assembly in this example.

Notice also that each provider section can have its own set of attributes. In “MySecondProvider”, for example, the attribute “TheExtraMessage” is optionally used to pass in extra configuration information that may be used by this particular implementation.

Hopefully you will agree that this is a fairly convenient and simple deployment story.

The Provider Classes

Now let’s talk about the provider. The project: MyProvider consists of several classes which I put into a single file for brevity. Here is the code in its entirety:

Imports System.Configuration

Imports system.Configuration.Provider

Namespace QualityData

' This is the base class that defines the required methods of any implementation

Public MustInherit Class MyProviderBase : Inherits ProviderBase

' For simplicity, we will have a single method that gets implemented

' differently based on the chosen provider.

Public MustOverride Function GetProviderSpecificMessage() As String

End Class

' The following two classes are "providers" that implement the base in different ways

' Ordinarily, each of these two classes would be in its own DLL since much of the idea of the

' Provider model is to be able to ship new behavior that can be "dropped in" without replacing

' the rest of the application

Public Class myFirstProvider : Inherits MyProviderBase

Private _myUniqueMessage As String

Public Overrides Sub Initialize(ByVal name As String, ByVal config As System.Collections.Specialized.NameValueCollection)

' Override the method of Configuration.Provider.ProviderBase

' default provider name if missing

If String.IsNullOrEmpty(name) Then name = "MyFirstProvider"

' initialize base and get custom settings

If Not IsNothing(config) Then

MyBase.Initialize(name, config)

' get the setting from config file

_myUniqueMessage = config("TheCustomSetting")

End If

' default setting to something uniquely from this provider

If String.IsNullOrEmpty(_myUniqueMessage) Then _myUniqueMessage = "FIRST PROVIDER WAS HERE!!"

End Sub

Public Overrides Function GetProviderSpecificMessage() As String

' return string that has provider-specific prefix as well as data from config

Return "The First Provider says: " & _myUniqueMessage

End Function

End Class

Public Class mySecondProvider : Inherits MyProviderBase

Private _myUniqueMessage As String

Private _anExtraMessage As String

Public Overrides Sub Initialize(ByVal name As String, ByVal config As System.Collections.Specialized.NameValueCollection)

' Override the method of Configuration.Provider.ProviderBase

' default provider name if missing

If String.IsNullOrEmpty(name) Then name = "MySecondProvider"

' initialize base and get custom settings

If Not IsNothing(config) Then

MyBase.Initialize(name, config)

' get the setting from config file

_myUniqueMessage = config("TheCustomSetting")

' this second provider can have its own extra settings

_anExtraMessage = config("TheExtraMessage")

End If

' default setting to something uniquely from this provider

If String.IsNullOrEmpty(_myUniqueMessage) Then _myUniqueMessage = "#2 PROVIDER WAS HERE!!"

End Sub

Public Overrides Function GetProviderSpecificMessage() As String

' build up a return string that is specialized for this provider

Dim sb As New System.Text.StringBuilder

sb.Append("The Second provider does it differently: ")

sb.Append(_myUniqueMessage)

If Not String.IsNullOrEmpty(_anExtraMessage) Then sb.Append(" " & _anExtraMessage)

Return sb.ToString

End Function

End Class

' We will be swapping out providers through simple changes to the app's .config file

' This can go quite deep to give you a lot more control but here are the basics:

' 1) MyProviderSection, defines a configuration section for app.config

' 2) MyProviderCollection, defines the collection of providers listed within our section of .config

' This class lets the configuration manager create a strongly-typed instance of our

' section based on the information listed in the application's .config file.

Public Class MyProviderSection : Inherits ConfigurationSection

<ConfigurationProperty("providers")> _

Public ReadOnly Property Providers() As ProviderSettingsCollection

Get

Return CType(Me("providers"), ProviderSettingsCollection)

End Get

End Property

<StringValidator(minLength:=1), ConfigurationProperty("defaultProvider", defaultvalue:="MyFirstProvider")> _

Public Property DefaultProvider() As String

Get

Return CStr(Me("defaultProvider"))

End Get

Set(ByVal value As String)

Me("defaultProvider") = value

End Set

End Property

End Class

' This class lets the configuration manager create a strongly-typed collection of

' providers based on the information listed within the section for our custom provider.

Public Class MyProviderCollection : Inherits ProviderCollection

Public ReadOnly Property MyProviderBase(ByVal name As String) As MyProviderBase

Get

Dim o As Object = Me(name)

If o IsNot Nothing Then Return CType(o, MyProviderBase) Else Return Nothing

End Get

End Property

Public Overrides Sub Add(ByVal provider As System.Configuration.Provider.ProviderBase)

' check for valid type (ie, make sure the listed provider inherits from our base)

If IsNothing(provider) Then Throw New ArgumentNullException("provider")

If Not TypeOf provider Is MyProviderBase Then Throw New ArgumentException("Invalid provider type", "provider")

' add

MyBase.Add(provider)

End Sub

End Class

End Namespace

Most of this is self explanatory and hopefully the code comments will help to make it clear. Notice that we have a (mustinherit) base class that inherits System.Configuration.Provider.ProviderBase and defines the single required method “GetProviderSpecificMessage”. We have two classes that inherit from that base and override the Initialize method to load in the configuration goodies that are passed in as a NameValueCollection.

We also have a custom ConfigurationSection class that minimally extends its base by setting the defaultProvider’s defaultValue property to “MyFirstProvider”.

Finally, we implement “MyProviderCollection” which inherits from System.Configuration.ProviderCollection and contains a list of providers that derive from our custom provider base (MyProviderBase.)

Download, run and extend the source in the project and let me know if any of this is useful to you.

Brian Mishler

WinformProviderSample.zip (99.86 KB)

How to determine where a provider is configured

Brian Mishler — Thu, 27 Apr 2006 12:28:52 GMT

In an Asp.Net application, if you check the properties of the various Asp.Net providers at runtime, you will get a value that is something of a hybrid between default and custom settings. Similarly, if you check a property such as ConfigurationManager.ConnectionStrings(“LocalSqlServer”).ConnectionString, you will get a value that may originate in web.config or result from a default setting.

Why is this?

When an Asp.Net 2.0 application is loaded, the attributes (and behavior) of the various Asp.Net providers (membership, roleManager, profile and others) are retrieved from sections in machine.config (C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\CONFIG\machine.config.) If the web application includes a web.config file, the configuration sections contained therein may supplement or override the default behavior.

So how do you programmatically determine if a provider is getting its configuration from the default (machine.config) file or from an application-specific (web.config) file?

I recently had to deal with this issue in testing for various potential user problems with the Membership Manager Control. I was simulating a fairly common scenario where users might configure their AspNetSqlMembershipProvider to store passwords in an encrypted format but forget to provide a machineKey section. The machineKey section defines how to encrypt/decrypt various types of information and, if not defined in web.config, will produce autogenerated values. Anyone who has tried to go with an encrypted rather than hashed passwordFormat will have undoubtedly encountered the following message when they attempt to run the web application:

You must specify a non-autogenerated machine key to store passwords in the encrypted format. Either specify a different passwordFormat, or change the machineKey configuration to use a non-autogenerated decryption key.

This exception is thrown by the AspNetSQLMembershipProvider to force the web application developer to provide a machineKey section in web.config. This requirement is well documented and several excellent resources are available on the Internet to help you generate the elements needed to create your own custom machineKey configuration section.

So in my situation, I wanted to prevent users from changing an individual member’s passwordFormat to Encrypted if the machineKey was not specified in web.config. I would need a way to determine this at runtime.

Well, it’s easy enough to get a strongly typed MachineKeySection object. The following VB.Net method illustrates how to get an instance of the machineKeySection class for the current web project:

Public Shared Function GetMachineKeySection() As System.Web.Configuration.MachineKeySection

Static section As MachineKeySection
If section Is Nothing Then

section = CType(System.Web.Configuration.WebConfigurationManager.GetSection("system.web/machineKey"), MachineKeySection)

End If
Return section

End Function

(Note that "system.web/machineKey" is case sensitive)

And when you check the resulting instance, you will get information in fields such as decryption, decryptionKey, validation and validationKey – whether or not a machineKey section exists in web.config.

So how can you programmatically tell if machineKey contains a non-autogenerated decryption key?

The ElementInformation class is typically available as a property of sections such as machineKey and can tell you if a particular element is a collection, if it can be modified and even the line number where it is defined in its configuration file. And, of course, Microsoft gives us the IsPresent property which tells us whether or not the element actually exists in the configuration file. ElementInformation.IsPresent returns a Boolean and is easy to use as shown in the VB.Net method listed below.

Public Shared Function HaveMachineKey() As Boolean

Dim section As MachineKeySection = GetMachineKeySection() ' see above

            If Not section Is Nothing Then
               section.ElementInformation.IsPresent
            End If

End Function

The model for strongly typed configuration classes has been around since .Net 1.0 and is available for WinForms as well as WebForms applications. Custom configuration classes are relatively easy to create and provide a big step up from INI files. In the 2.0 .Net Framework, configuration classes are even easier to create and provide lots of great new capabilities. This ability to inherit and override configuration settings does a great job in supporting the provider model and features such as the ElementInformation class give the programmer all the information he/she needs to determine the source of any particular configuration section.

Brian Mishler

http://www.qualitydata.com

Asp.Net Membership Password Administration

Brian Mishler — Tue, 18 Apr 2006 01:47:20 GMT

The Asp.net membership provider was designed to allow for self-service password management but through an understanding of the configuration options as well as a combined use certain provider methods, web site administrators can effectively manage member passwords. This article briefly summarizes the various settings and methods which can be combined to administratively manage passwords in an Asp.Net membership system based on the default SQLMembershipProvider.

The following (web.config) configuration options define how the AspNetSqlMembershipProvider behaves:

enablePasswordRetrieval – Enables/disables the membership provider’s GetPassword method. Note that GetPassword will always throw an exception if the user’s password is hashed. Default value is false. Requires the password answer unless “requiresQuestionAndAnswer” in web.config is set to false.

enablePasswordReset – Enables/disables the membership provider’s ResetPassword method, which can be used to produce a randomly generated password. Default value is true. ResetPassword requires the user’s passwordAnswer unless “requiresQuestionAndAnswer” in web.config is set to false.

requiresQuestionAndAnswer – Alters the behavior of the GetPassword and ResetPassword methods to require or not require the password answer parameter. Default value is true. This method is the key for administrative management of passwords since, by turning it off, administrators can retrieve or reset passwords.

passwordFormat – Defines how passwords will be stored when membership records are created. Note that once a membership record has been created, functions such as ChangePassword and ResetPassword will continue to store the credentials in the original passwordFormat, even if web.config is changed to use a different password format.

Clear the password and password answer are stored in clear text. The passwordSalt field (in the database) is left blank.

Encrypted the password, password answer and passwordSalt are stored in an encrypted format within the database using the key information supplied in the machineKey element of web.config

Hashed the password and password answer are hashed using a one-way hash algorithm and a randomly generated passwordSalt value.

Microsoft set the default value of passwordFormat to Hashed in order to promote their secure web initiative but for many applications, this level of security is overkill and can create inconveniences in managing passwords.

Given the above information, there are a number of approaches that can be taken to administratively manage membership passwords. Note that “administrative” management implies that the administrator does not know the member’s password or password answer.

Retrieving a member’s password

The GetPassword method may be used to retrieve a member’s password and, at first glance, appears to require the password answer. By setting “requiresQuestionAndAnswer” to false in web.config, the GetPassword method can be called with an empty password answer and therefore can be effectively used to administratively retrieve a member’s password. Note that “enablePasswordRetrieval” must be set to true in web.config to enable the GetPassword method:

If password is:

Clear text Simply call the GetPassword method with the username and without the need for a password answer to retrieve the password

Encrypted Simply call the GetPassword method with the username and without the need for a password answer to retrieve the password

Hashed Not possible, however the password may be reset as described below.

In Visual Basic, you can call the shared GetPassword method as illustrated below. Note that the second parameter would be for the password answer if “requiresQuestionAndAnswer” were true in web.config.

Dim password As String = Membership.Provider.GetPassword(userName, String.Empty)

Resetting a member’s password

The ResetPassword method may be used to generate a new, randomly generated password and, at first glance, appears to require the user’s password answer. By setting “requiresQuestionAndAnswer” to false in web.config, the ResetPassword method can be called with an empty password answer to set a user’s password to some new randomly generated value. ResetPassword works with all password formats (clear, encrypted, hashed).

In Visual Basic, you can call the shared ResetPassword method as illustrated below. Note that you can pass Nothing for the second parameter, passwordAnswer.

Dim newPassword As String = Membership.Provider.ResetPassword(username, Nothing)

Changing a member’s password

In some organizations, a Customer Service department may wish to change a user’s password to a new known value, perhaps in response to a customer request. The ChangePassword method, which appears to handle this need, unfortunately requires the original user password which is usually unavailable to the site administrator. By setting “requiresQuestionAndAnswer” to false, “enablePasswordRetrieval” to true and “enablePasswordReset” to true in web.config, the ResetPassword and ChangePassword methods can be used to change a user’s password to a known value, regardless of the password format:

Clear text Call the GetPassword method with the username and without the need for a password answer to retrieve the password. Now, armed with the password, call ChangePassword to set the password to a desired value.

Encrypted Call the GetPassword method with the username and without the need for a password answer to retrieve the password. Now, armed with the password, call ChangePassword to set the password to a desired value

Changing a member’s Password Question and Password Answer

In some situations, the Customer Service department may wish to modify a member’s Password Question and Password Answer. This is easily accomplished if passwords are encrypted or maintained in clear text. For hashed passwords, however, a password-reset is also required since the provider method, ChangePasswordQuestionAndAnswer, requires the member’s password which is not retrievable. By setting “requiresQuestionAndAnswer” to false, “enablePasswordRetrieval” to true and “enablePasswordReset” to true in web.config, the member’s Password Question and Password Answer may be reset:

Clear text Call the GetPassword method with the username and without the need for a password answer to retrieve the password. Now, armed with the password, call ChangePasswordQuestionAndAnswer to set the Password Question and Password Answer to a desired value.

Encrypted Call the GetPassword method with the username and without the need for a password answer to retrieve the password. Now, armed with the password, call ChangePasswordQuestionAndAnswer to set the Password Question and Password Answer to a desired value.

Hashed Call the ResetPassword method with the username and without the need for a password answer to reset the password to a new random value. Using the newly generated password, call ChangePasswordQuestionAndAnswer to set the Password Question and Password Answer to a desired value. Optionally call ChangePassword to set the password to a more user-friendly value.

Changing the password format

As web sites mature, website administrators sometimes regret their original (sometimes unintended) choice in passwordFormat when using the AspNetSqlMembershipProvider. That is, membership passwords may be clear text when a hashed format is desired or vice versa. Microsoft’s decision to implement hashing in the default AspNetSqlMembershipProvider was wise and conservative but for many web sites with minimal security requirements, the password system can become cumbersome. By directly calling a couple of the AspNet stored procedures, it is possible to change the password format:

Note: If the passwordFormat is initially “Clear” or “Encrypted”, use the membership.provider.GetPassword method to cache the original password before calling the stored procedures.

1. Use the stored procedure aspnet Membership GetPasswordWithFormat to retrieve the current passwordSalt.

2. Use the stored procedure aspnet Membership ResetPassword to set the passwordFormat to its intended (integer) value. The stored procedure requires readily available parameter values including passwordSalt (retrieved earlier), password (empty string) and passwordAnswer (Null).

At this point, the membership record has been placed into an initialized (unusable) state and the PasswordAnswer has been lost. If the original password was hashed, then it too will be unrecoverable. The provider methods listed below and described in previous sections allow for resetting the credentials and, as they are used, the password and password answer will be stored in the new password format (clear, encrypted, hashed.)

1. Call the ResetPassword method to generate and retrieve a new random Password. Remember that the second parameter (answer) is not required if “requiresQuestionAndAnswer” is set to false in web.config.

2. Call the ChangePassword method, using the now-current password retrieved in the previous step, to set the password to a desired value. If the original password was saved at the start of the procedure, it may be restored at this point.

For originally un-hashed passwords, the preceding steps allow for a change of passwordFormat with complete restoration of the original password.

The Password Answer could have easily been retrieved from the database at the outset if it was stored in clear text. In the case of an encrypted Password Answer, a more complicated approach which involves the provider’s protected DecryptPassword method could have been used to cache the original Password Answer. If the original Password Answer were available, it could be restored with a call to the ChangePasswordQuestionAndAnswer provider method.

So, what can be done if the Password and/or Password Answer had to be sacrificed in favor of a new passwordFormat? One solution might be to reset everyone’s credentials then send them by Email. Another solution might be to place a notice onto the web site that informs users and provides further instructions. Either way, the web site should leverage the self-service membership controls which allow the member to reset his/her own credentials. The following outlines a series of steps that can be taken:

1. A new arbitrary password can be assigned using either the ResetPassword or ChangePassword provider method. Similarly, a new arbitrary Password Question and Password Answer can be assigned using the ChangePasswordQuestionAndAnswer provider method.

2. Since the user will not know his/her new credentials, ensure the Login Control includes the necessary properties (PasswordRecoveryText and PasswordRecoveryURL) to link the user to a page that includes a PasswordRecovery Control.

3. Recall that the PasswordRecovery Control is driven by the provider settings in web.config. In particular, ensure that “requiresQuestionAndAnswer” is set to false so the PasswordRecovery Control does not prompt the user for a Password Answer. Also, ensure that the SMTP setting is specified in web.config so that the Email will be sent. If the membership record uses a hashed password format then a new (random) password will be sent, otherwise the password you assigned in the previous step will be sent.

Conclusion

Armed with a little knowledge, it is possible to use the membership provider methods to perform basic administrative functions for an otherwise self-service web site. It is possible (although probably undesirable) to have a mix of clear, encrypted and hashed passwords in the same database. Depending on the passwordFormat for a particular record, varying levels of administrative control are available. For the AspNetSqlMembershipProvider, it is possible to change the passwordFormat for a particular record using a combination of built-in stored procedure calls and membership provider methods.

Microsoft has done a good job in engineering the membership provider system and has really left no security holes. The procedures outlined here utilize a combination of built-in stored procedures as well as standard provider methods to accomplish certain activities that are routinely required of site administrators.

Brian Mishler

http://www.qualitydata.com

Why the Provider Model is so important to ISV's

Brian Mishler — Fri, 14 Apr 2006 16:25:26 GMT

As an Independent Software Vendor (ISV), I make my living writing a software program and (hopefully) selling it many times. For the most part, the application meets the customer’s requirements right “out of the box” and if there is a gap, the customer is usually able to work around it. Every now and then, a potential customer will dangle the carrot out there, that if certain features are added then they’ll buy a lot of copies. Or, they would buy it if it could be integrated with their existing XYZ-system.

Now I’m not talking about the practice of accepting customer suggestions for a systematic improvement of a maturing product. I’m talking about adding appendages where they just don’t belong. Over the years, I’ve occasionally succumbed to these pressures and in some cases, the products were better off for it. Other times, the extra features were like anchors around our feet as now had customer-specific business rules in our mainstream product.

The Provider Model

I’m sure the Provider Model has been around for a while but I first heard the term “Provider” back when Microsoft was introducing its “Universal Data Access” strategy (I seem to recall this was all part of the transition to MDAC.) For the next few years, of course, we all used the “ODBC Provider” or the “SQL Server Provider” in our database applications and (at least I) did not think much more of it.

In general, the provider model is a design pattern that allows, through configuration, an alternate provider of application functionality to be substituted with requiring modification to the primary application.

(There’s probably a better text-book definition for this but my definition suits me just fine)

A few years back, I read a couple of articles on MSDN about “Providers” and proceeded to build my own for one of our products, the PocketForms Web Service. I was intrigued about the idea of letting customers easily override the default implementation of any of my web methods and figured this might provide a nice “catch all” for the occasional special-requirements customer. Back then, there was no base provider class in the .Net Framework but several good examples were available for guidance.

I found that most of the work was actually in setting up various configuration classes that would be used to manage optional user settings. The application, itself, required some fairly straight-forward design changes, mainly in creating a new “MustInherit” base class that defined the interfaces that my existing class already implemented. All-in-all, it took just a couple of days to retrofit my existing application with this new design pattern.

Fantastic Return on Investment

I must say that the investment in learning about and implementing the Provider Model has been one of the best decisions I have ever made professionally. As it turns out, most of our customers take advantage of this in one way or another. Some have custom authentication requirements, some want to do special handling with posted data and others just want to log certain activities.

Last year, we released our Sharepoint Bridge which is a “shrink wrapped” provider to make our product work with Sharepoint Portal Server and Windows Sharepoint Services and have attracted a lot of attention from organizations that wanted an easy way to push mobile data into their existing Sharepoint-based intranet. This extra capability can be customized and improved on its own product cycle without ever affecting the functionality of the primary product. And, as we upgrade our web service with additional features, our custom providers continue to work.

Now easier than ever

With the release of the .Net Framework 2.0, Microsoft included a base provider class in the framework itself. We were able to dump all of our plumbing code and simply inherit our base classes from the new System.Configuration.Provider.ProviderBase class. The various configuration (ConfigurationSection, ProviderCollection, etc.) classes have also been simplified, so we cleaned up our existing configuration code as well.

There are plenty of articles on MSDN and elsewhere on using the provider model, so it would be redundant for me to go through all that here. In a future post, I plan provide a real working example in case anyone wants a nice starter project.

Not just for Asp.Net

With the release of Visual Studio 2005, Microsoft showed off the new Asp.Net Membership System in just about every presentation they gave. Everyone was impressed with the instant login and user creation controls and when Microsoft was asked the question “what if we want to change the implementation”, they were able to point to the provider-based implementation of their Membership System. Since there is such a high adoption rate of the Asp.Net Membership System, many folks associate the term “provider” with the Role, Membership and Profile providers in Asp.Net. Many programmers will go on to assume that this means the “AspNetSqlRoleProvider”, “AspNetSqlMembershipProvider” and “AspNetProfileProvider” and lose sight of the fact that these are just the default (if not the most common) implementations of the base provider classes.

More and more ISV’s are recognizing that this model is not only useful for supporting unplanned circumstances but will also become more in demand with the increased adoption rate of Microsoft’s development platforms. The investment is minimal and the potential rewards are significant. As I evaluate new applications, I have gotten into the habit of reading the configuration files and lately have seen an increased number of “shrink wrap” programs that have some form of provider-based implementation. One good example is Telligent’s Community Server that appears to have largely been built on base provider classes. I have not seen much documentation on this but I would assume that Telligent built it this way so that organizations could swap out some of the implementation.

The provider model works well for Asp.Net (web) applications since the appropriate provider is loaded once and based on the settings in Web.Config. It also works well for WinForms applications, although a change in the application’s configuration file does not automatically cause a running application to restart and reload a different provider.

From one ISV to another…

So, if you are an ISV building solutions on the Microsoft .Net platform, you owe it to yourself to consider a provider-based implementation of your application. You’ll find you are able to satisfy many unexpected requirements and not have to saddle your application with extra features that will need to be optionally disabled in future releases. Another big benefit is the additional revenue stream you open up with new add-on products like your “Oracle Provider” or “SAP Provider”.

I love this subject and, while I have had a lot of success in actually using it, keep finding there is more to learn. Your comments are welcome.

Brian Mishler

http://www.qualitydata.com

Asp.Net Provider Model: ApplicationNames and the ApplicationID

Brian Mishler — Thu, 06 Apr 2006 02:04:54 GMT

One of the great things about the Asp.Net Membership System is that it was designed to snap into many types of enterprise and off-the-shelf applications to provide a consistent model for common tasks such as authenticating users. Several of the database tables (AspNet Users, AspNet Membership and AspNet Roles) include an “ApplicationID” column, which allows for more than one application to utilize a single database. Therefore, it is possible for two different users of two separate applications to have the same username without experiencing a conflict since the combined ApplicationID & UserName would be distinct.

A master table, AspNet Applications, includes a list of the distinct ApplicationID’s which may be in use by the various membership tables. Since this field is a “uniqueidentifier” (GUID), a separate string field called “ApplicationName” is available for looking up the ApplicationID. The following figure illustrates a record in the AspNet Applications table that maps an ApplicationName “/” to the globally unique ApplicationID.

The ApplicationName can be nearly any string (up to 256 characters) and is originally defined, not in the database, but as an attribute of each of the SQL Server providers (AspNetSqlMembershipProvider , AspNetSqlProfileProvider , AspNetSqlRoleProvider.)

The default attributes for each of the AspNet SQL Providers are defined in machine.config, which is generally stored in c:\windows\Microsoft.NET\Framework\v2.0.50727\CONFIG\machine.config. This is an important file that should never be modified so Asp.Net lets you override any of its settings by simply placing sections of the file into a web.config file within your web site.

The following is an excerpt from the <system.web> section of machine.config, which defines the System.Web.Security.SqlMembership provider as the default provider for handling membership. Notice that one of its attributes, applicationName, is set to a backslash.

<system.web>
…
<membership>
<providers>
<clear />
<add connectionStringName="LocalSqlServer"
enablePasswordRetrieval="false"
enablePasswordReset="true"
requiresQuestionAndAnswer="true"
applicationName="/"
requiresUniqueEmail="false"
passwordFormat="Hashed"
maxInvalidPasswordAttempts="5"
minRequiredPasswordLength="7"
minRequiredNonalphanumericCharacters="1"
passwordAttemptWindow="10"
passwordStrengthRegularExpression=""
name="AspNetSqlMembershipProvider"
type="System.Web.Security.SqlMembershipProvider, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
</providers>
</membership>
…
</system.web>

If you wanted to store data for more than one application within a single database or if you desired some control over the applicationName which is used in the AspNet Applications table, you can create a web.config file, in the root folder of your web site, to override the applicationName that is specified in machine.config (shown above.)

The following is an excerpt from web.config. Notice that <clear /> is used to remove any default providers (such as the one in machine.config) from memory and that the applicationName has now been set to something more interesting.

Assuming you have already been running the web application, there is likely a pre-existing record in the AspNet Applications table as well as records in the other membership (AspNet Membership, AspNet Users, AspNet Roles) tables that correspond to the ApplicationID for “/”. So guess what happens in the database the first time the application is run after changing the ApplicationName in web.config?

As shown here, a new record, along with a new ApplicationID, has been generated by the provider. All of your existing data including membership, users and roles is still stamped with the original ApplicationID and therefore inaccessible by your provider. This is not a flaw in the system or an oversight on the part of Microsoft. It is simply something you must understand if you intend to modify the applicationName attribute on your provider configuration settings.

Let’s say you have some existing membership records and wish to associate them with the new ApplicationName/ApplicationID. This is very simple to accomplish by issuing the following statements in SQL Server:

UPDATE AspNet Membership SET ApplicationID=’new-application-id’ WHERE ApplicationID=’old-application-id’

UPDATE AspNet Users SET ApplicationID=’new-application-id’ WHERE ApplicationID=’old-application-id’

UPDATE AspNet Roles SET ApplicationID=’new-application-id’ WHERE ApplicationID=’old-application-id’

(Please substitute the appropriate GUID for “new-application-id” and “old-application-id”)

The SQLMembership provider’s foreign-key constraints will prevent you from deleting the original AspNet Applications record for “/” until you have successfully modified the ApplicationID values in each of the membership tables. Assuming that you performed the suggested updates then successfully deleted the record in AspNet Applications for “/”, can you see how a new record, again with a backslash “/” in the ApplicationName field, might be re-created the next time you run the web application?

Other providers, such as the AspNetSqlRoleProvider and the AspNetSqlProfileProvider also define default behaviors in machine.config and therein, the attribute for applicationName is “/” by default. If you use roles or profiles in your web application, be sure to override the default implementation for all three AspNet providers in web.config as appropriate for your solution.

Brian Mishler

http://www.qualitydata.com