"Steven Cheng[MSFT]" wrote:

> Hello MrGrundh,
>
> As for the "Membership.ApplicationName" property, it does be an read/writer
> property and is not threadsafe ( can be accessed by concurrent threads).
> Actually this property is associated with the underlying MembershipProvider
> instance(SqlMembershipProvider, your custom membershipprovider ....) which
> is configured and used in your ASP.NET application. When you change this
> property, you're actually changing the property on the underlying
> membershipProvider instance.
>
> From the document of this property below:
>
> =========================
> Because a single default membership provider instance is used for all of
> the requests served by an HttpApplication object, you can have multiple
> requests executing concurrently and attempting to set the ApplicationName
> property value. 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. We recommend
> that you avoid writing code that allows users to set the ApplicationName
> property, unless you must. An example of an application where setting the
> ApplicationName property may be required is an administrative application
> that manages membership data for multiple applications. Such an application
> should be a single-user application and not a Web application.
> ==========================
>
> #Membership.ApplicationName Property
> http://msdn2.microsoft.com/en-us/library/system.web.security.membership.appl
> icationname.aspx
>
> We can find that this property should be constant for a single provider
> instance during the applciation's lifecycle , but only configured at
> intilization time. In other words, you should configure it either in
> web.config for the provider or at an initialize period(such as
> Application_Start) in the application. The only scenario we should change
> it in application code is that we're developing an Application
> administrative interface which need to manage users in multiple application.
>
> So what's the detailed application logic in your case? Are you developing
> an administrative interface which manage users in multiple application or
> you just have limited number of applications to separate different group of
> users?
>
> If you do need to manage membership users across multiple
> applications(different applicationName) and your application will be
> accessed by concurrent users, a recommended way is to configure a separate
> provider for each application and use them respectively.
>
> For example, you can add the following two providers in web.config for two
> applications:
>
> <add name="myApp1" type="System.Web.Security.SqlMembershipProvider,
> System.Web, Version=2.0.0.0, Culture=neutral,
> PublicKeyToken=b03f5f7f11d50a3a"
> applicationName="myApp1"
> ........................" />
>
> <add name="myApp2" type="System.Web.Security.SqlMembershipProvider,
> System.Web, Version=2.0.0.0, Culture=neutral,
> PublicKeyToken=b03f5f7f11d50a3a"
> applicationName="myApp2"
> ........................" />
>
>
> Then, in your application's code you can use the below code to manipulate
> users in the specified application:
>
> =========================
> string appname = txtAppName.Text;
>
> MembershipProvider membership = Membership.Providers[appname];
>
> if (membership != null)
> {
> membership.CreateUser(....)
> }
> else
> {
> //invalid application name
> }
> =====================
>
>
> Please feel free to let me know if you have any further questions on this.
>
> Sincerely,
>
> Steven Cheng
>
> Microsoft MSDN Online Support Lead
>
>
>
> ==================================================
>
> Get notification to my posts through email? Please refer to
> http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
> ications.
>
>
>
> Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
> where an initial response from the community or a Microsoft Support
> Engineer within 1 business day is acceptable. Please note that each follow
> up response may take approximately 2 business days as the support
> professional working with you may need further investigation to reach the
> most efficient resolution. The offering is not appropriate for situations
> that require urgent, real-time or phone-based interactions or complex
> project analysis and dump analysis issues. Issues of this nature are best
> handled working with a dedicated Microsoft Support Engineer by contacting
> Microsoft Customer Support Services (CSS) at
> http://msdn.microsoft.com/subscriptions/support/default.aspx.
>
> ==================================================
>
>
>
> This posting is provided "AS IS" with no warranties, and confers no rights.
>
>