Membership.CreateUser() in a Class Library

Question

I'm in the process of moving code out of App_Code into a class library.

I create users programmatically using Membership.CreateUser.

How can I continue to do this inside my class library where there's no access to the membership provider I have configured in web.config?

Answer 1

Before I show you how the code part works - you need to understand how the settings get loaded up in this kind of scenario.

When you have a Web Application which is going to load your .dll file - and that .dll file is going to access the MembershipProvider which the application has configured - you have to make a few assumptions.

1. The Web Application has a MembershipProvider
2. The Web Application provides settings for that MembershipProvider in its Web.Config
3. The Web Application loads your .dll correctly

Because your .dll file should be included in the Web Application's /bin directory, you should be able to rely on the Web Application's configuration rather than having to supply your own.

To do this, start with what Oded mentions in his answer - create a reference to System.Web.Security within your .dll's code - then within that file you can do something like the following:

if (Membership.Provider != null) {
    Membership.Provider.CreateUser( ... );
} else {
    // Do something appropriate in a case where there is no Membership Provider
}

At this point - if the above doesn't work, it is likely because your Web Application doesn't have an appropriate provider configured.

A note on why to do it this way...

The reason you should let the Web Application provide the configuration is to comply with the principle of Separation of Concerns. The MembershipProvider is an abstract class which provides default functionality - with very little implementation.

In other words - it defines that to manage members, you need to be able to perform operations such as CreateUser() and GetAllUsers(). It also says that you should be able to configure settings, such as specifying a PasswordFormat and determining whether or not each user RequiresUniqueEmail.

What it doesn't do is tell you where to store your User information. It leaves that up to the implementor (System.Web.Providers.DefaultMembershipProvider or YourNS.YourMembershipProvider).

The Application which uses the MembershipProvider then determines what settings to provide and which implementation to use. In other words - it's the job of YourNS.YourMembershipProvider to specify how information is managed, but it is likely the Application who should determine what ConnectionString to use in its storage, etc.

So - following the pattern I outlined above allows you to provide three separate layers:

1. an application which will consume the MembershipProvider,
2. an assembly which provides the MembershipProvider implementation, and
3. an assembly which uses whichever MembershipProvider is configured - and does something with it on behalf of the application (*this is the layer you're describing in your post, I believe)

Notice that if you follow this pattern - you can now switch MembershipProviders at a later time without having to alter either of the other layers - because those layers rely on the base class of MembershipProvider - rather than relying on your specific implementation. This can be hugely valuable.

Answer 2

I solved my issue by copying the whole web.config to my app.config. I was using a console application. I thought I had copied the necessary sections but until I copied everything, the data was not getting to database