How to add providers at runtime programmatically
So if you are like me, you are a fan of not reinventing the wheel. This is especially true of components like Membership, Roles, Authentication, Personalization and whatnot. While I take some issue with the choice of API and can think of many improvements that should be made, the benefits of leveraging what work has already been done instead of reinventing my own way of getting things done far outweighs any issues I find with the Provider model. One area that I cannot abide is the reliance on configuration files however. Don't get me wrong, the .Net web.config file is a great thing provided it isn't the only way to get stuff done. This holds true of configuration in general IMHO. You mustalways supply a programmatic API for configuration but if you so desire, supply an XML configuration API and in turn supply a component that understands how to interact with the specifically the System.Configuration subsystem in .Net framework. Go take a look at how the Castle team tackled configuration in Windsor. That's how you should get it done. The issue is that while the approach that the ASP.Net team took for configuration of the Provider system works for basic use cases, it totally lacks for any ability to modify or manage the Provider model at runtime. What this means is that you must set up ALL Providers in your web.config file ahead of time! This clearly doesn't work for systems wherein you need to add Providers at runtime or are unable to know the Providers at deployment time. You might be tempted to think that "hey Jimmy, yeah I get that you have to configure all these Providers in the config file but haven't you noticed that the static provider specific API class has a collection of the providers?". Yes it does. Let me show you using the Membership system one of these collections: var allProviders = Membership.Providers;
allProviders.ForEach(provider => Trace.Write(provider.GetType().Name);Yuppers there's a big fat collection of them. And you might be thinking that because this is a collection then you can simply call the Add() method and be done with it. You would think; and it woudl be wrong. You see the collection happens to be read only. Try it out yourself: Debug.Assert(Membership.Providers.IsReadOnly);But never fear, you CAN get around this, albeit in a totally unsupported fashion leveraging a wee bit of reflection, get around this problem (with 1 caveat to be explained later). So if you want to build these guys up at runtime you totally can as nothing stops you from creating new instances of a provider class. The catch is that the Provider infrastructure doesn't know anything about your newly created instance. So the question is, if I can create them and I somehowget these instances into the Provider runtime, will they work? The pleasant answer is Yes they will. Read more: Objects, Services, and the rants of a lunatic operating
So if you are like me, you are a fan of not reinventing the wheel. This is especially true of components like Membership, Roles, Authentication, Personalization and whatnot. While I take some issue with the choice of API and can think of many improvements that should be made, the benefits of leveraging what work has already been done instead of reinventing my own way of getting things done far outweighs any issues I find with the Provider model. One area that I cannot abide is the reliance on configuration files however. Don't get me wrong, the .Net web.config file is a great thing provided it isn't the only way to get stuff done. This holds true of configuration in general IMHO. You mustalways supply a programmatic API for configuration but if you so desire, supply an XML configuration API and in turn supply a component that understands how to interact with the specifically the System.Configuration subsystem in .Net framework. Go take a look at how the Castle team tackled configuration in Windsor. That's how you should get it done. The issue is that while the approach that the ASP.Net team took for configuration of the Provider system works for basic use cases, it totally lacks for any ability to modify or manage the Provider model at runtime. What this means is that you must set up ALL Providers in your web.config file ahead of time! This clearly doesn't work for systems wherein you need to add Providers at runtime or are unable to know the Providers at deployment time. You might be tempted to think that "hey Jimmy, yeah I get that you have to configure all these Providers in the config file but haven't you noticed that the static provider specific API class has a collection of the providers?". Yes it does. Let me show you using the Membership system one of these collections: var allProviders = Membership.Providers;
allProviders.ForEach(provider => Trace.Write(provider.GetType().Name);Yuppers there's a big fat collection of them. And you might be thinking that because this is a collection then you can simply call the Add() method and be done with it. You would think; and it woudl be wrong. You see the collection happens to be read only. Try it out yourself: Debug.Assert(Membership.Providers.IsReadOnly);But never fear, you CAN get around this, albeit in a totally unsupported fashion leveraging a wee bit of reflection, get around this problem (with 1 caveat to be explained later). So if you want to build these guys up at runtime you totally can as nothing stops you from creating new instances of a provider class. The catch is that the Provider infrastructure doesn't know anything about your newly created instance. So the question is, if I can create them and I somehowget these instances into the Provider runtime, will they work? The pleasant answer is Yes they will. Read more: Objects, Services, and the rants of a lunatic operating