Changing Membership.ApplicationName in code - thread safety

On the MSDN page for the Membership.ApplicationName property (which applies to an asp.net membership provider), it warns that although one can change Membership.ApplicationName in code, 'The ApplicationName property is not thread safe for multiple writes, and changing the ApplicationName property value can result in unexpected behavior for multiple users of an application.' They therefore recommend avoiding using it for a 'web application'.

This is because the default SqlMembershipProvider is written as a singleton. But here's my question: is it OK if all the threads in my application process are going to set Membership.ApplicationName to the same thing?

I'm thinking of having multiple applications on my IIS box, each with their own separate application pool. I want to point them to the same location, but based on the hostname, set the application provider to different things. Wouldn't this actually be OK?开发者_开发技巧 It might not be a thread-safe operation, but doesn't each application pool have its own process and therefore its own instance of SqlMembershipProvider? So, every thread that tried to set Membership.ApplicationName for a given SqlMembershipProvider instance would be trying to set it to the same thing (the provider that is appropriate for that hostname). Or am I missing something?

I guess the main question is, do ALL asp.net applications share one SqlMembershipProvider, or is a separate one created for each application pool process?

---

Each application pool would have it's own MemberShip.ApplicationName so you'd be safe.

With regard to the SQL Membership Provider the same would apply. Because each site is in its own application pool they are distinct and separate.

In fact even in the same application pool but where you had separate ASP.NET applications (i.e. you clicked on the Create Application on a folder for each of them) there would be distinct objects. This is because the unit of application isolation in .NET is the Application Domain which you could describe as a soft process boundary within a Windows process.

To answer the question in your comment, this page on the MS ASP.NET QuickStart tutorials probably explains this and is straight from the horses mouth:

Understanding Applications and State

To quote:

Each ASP.NET Framework application on a Web server is executed within a unique .NET Framework application domain, which guarantees class isolation (no versioning or naming conflicts), security sandboxing (preventing access to certain machine or network resources), and static variable isolation.