«

Hi folks,
I've been asking some ASP.NET Membership questions here and there for
the past 8 days (or so) over and over again. But surprisingly, it seems
that no one takes the Membership/role providers seriously - AFAIK. I've
been in a fog for the past week, unfortunately. This is my last try to
solve the real-world problem I've been faced with when using the
ASP.NET Membership APIs or whatever they are called.

In a real-world applications, having a single UserName/Password pair in
a persistent storage (being SQLServer, Active Directory and the like)
doesn't suffice. It is in one way or another, related to some other
entities. For example, in a financial application, it's probably
related to an Employee account where each employee has got one and only
one UserName/Password assigned. Therefore, we will have another entity
to manage (besides the membership information), in this scenario,
Employee accounts.

An employee should never be inserted into the persistent layer if and
only if it's counterpart entity (membership info) is also added to the
persistent layer! i.e., either both or neither! This simply implies
that we need to do things under a given transaction.

However, there's no way to ask a Membership provider to do things
(CreateUser, for instance) under a given transaction and therefore we
cannot keep the integrity of the whole system. Unfortunately, the
Membership methods are all declared as static, therefore, developing a
new SqlMembershipProvider class is not enough since there's no way to
pass the Transaction object to the above-mentioned class.

Any help and/or idea to solve the issue would be highly appreciated,

Thank you for your time,
Mehdi

well - you can do somehting like this:

using (TransactionScope ts = new TransactionScope())
{
Membership.CreateUser(..);
DoSomethingElse(..)

ts.Complete();
}


The Membership class methods are static - not the actual provider. If you
need more advanced functionality, then membership is not designed for that
and you have to write a good old class that does your user-management. If
you need membership because you want to share the implementation between
several other technologies (SharePoint, WCF) - then you have to live with
the interface it provides or find whacky ways to pass more data into it (which
work in one environment or another and kind of defeats the purpose).



-----
Dominick Baier (http://www.leastprivilege.com)

> Hi folks,
> I've been asking some ASP.NET Membership questions here and there for
> the past 8 days (or so) over and over again. But surprisingly, it
> seems
> that no one takes the Membership/role providers seriously - AFAIK.
> I've
> been in a fog for the past week, unfortunately. This is my last try to
> solve the real-world problem I've been faced with when using the
> ASP.NET Membership APIs or whatever they are called.
> In a real-world applications, having a single UserName/Password pair
> in a persistent storage (being SQLServer, Active Directory and the
> like) doesn't suffice. It is in one way or another, related to some
> other entities. For example, in a financial application, it's probably
> related to an Employee account where each employee has got one and
> only one UserName/Password assigned. Therefore, we will have another
> entity to manage (besides the membership information), in this
> scenario, Employee accounts.
>
> An employee should never be inserted into the persistent layer if and
> only if it's counterpart entity (membership info) is also added to the
> persistent layer! i.e., either both or neither! This simply implies
> that we need to do things under a given transaction.
>
> However, there's no way to ask a Membership provider to do things
> (CreateUser, for instance) under a given transaction and therefore we
> cannot keep the integrity of the whole system. Unfortunately, the
> Membership methods are all declared as static, therefore, developing a
> new SqlMembershipProvider class is not enough since there's no way to
> pass the Transaction object to the above-mentioned class.
>
> Any help and/or idea to solve the issue would be highly appreciated,
>
> Thank you for your time,
> Mehdi

Well, thank you for being straight! The following call will end up in
MSDTC, although both connections point to the same SQL Server instance.
Right?

The other question is that whether the "MSDTC" is available on "Windows
XP Home Edition"?

TIA,
Mehdi

Dominick Baier wrote:
> well - you can do somehting like this:
>
> using (TransactionScope ts = new TransactionScope())
> {
> Membership.CreateUser(..);
> DoSomethingElse(..)
>
> ts.Complete();
> }
>
>
> The Membership class methods are static - not the actual provider. If you
> need more advanced functionality, then membership is not designed for that
> and you have to write a good old class that does your user-management. If
> you need membership because you want to share the implementation between
> several other technologies (SharePoint, WCF) - then you have to live with
> the interface it provides or find whacky ways to pass more data into it (which
> work in one environment or another and kind of defeats the purpose).
>
>
>
> -----
> Dominick Baier (http://www.leastprivilege.com)
>
> > Hi folks,
> > I've been asking some ASP.NET Membership questions here and there for
> > the past 8 days (or so) over and over again. But surprisingly, it
> > seems
> > that no one takes the Membership/role providers seriously - AFAIK.
> > I've
> > been in a fog for the past week, unfortunately. This is my last try to
> > solve the real-world problem I've been faced with when using the
> > ASP.NET Membership APIs or whatever they are called.
> > In a real-world applications, having a single UserName/Password pair
> > in a persistent storage (being SQLServer, Active Directory and the
> > like) doesn't suffice. It is in one way or another, related to some
> > other entities. For example, in a financial application, it's probably
> > related to an Employee account where each employee has got one and
> > only one UserName/Password assigned. Therefore, we will have another
> > entity to manage (besides the membership information), in this
> > scenario, Employee accounts.
> >
> > An employee should never be inserted into the persistent layer if and
> > only if it's counterpart entity (membership info) is also added to the
> > persistent layer! i.e., either both or neither! This simply implies
> > that we need to do things under a given transaction.
> >
> > However, there's no way to ask a Membership provider to do things
> > (CreateUser, for instance) under a given transaction and therefore we
> > cannot keep the integrity of the whole system. Unfortunately, the
> > Membership methods are all declared as static, therefore, developing a
> > new SqlMembershipProvider class is not enough since there's no way to
> > pass the Transaction object to the above-mentioned class.
> >
> > Any help and/or idea to solve the issue would be highly appreciated,
> >
> > Thank you for your time,
> > Mehdi

right - it will promote to DTC - so the same thing we have been doing for
years

I have no idea if DTC is available on Home Edition - but i assume.
-----
Dominick Baier (http://www.leastprivilege.com)

> Well, thank you for being straight! The following call will end up in
> MSDTC, although both connections point to the same SQL Server
> instance. Right?
>
> The other question is that whether the "MSDTC" is available on
> "Windows XP Home Edition"?
>
> TIA,
> Mehdi
> Dominick Baier wrote:
>
>> well - you can do somehting like this:
>>
>> using (TransactionScope ts = new TransactionScope())
>> {
>> Membership.CreateUser(..);
>> DoSomethingElse(..)
>> ts.Complete();
>> }
>> The Membership class methods are static - not the actual provider. If
>> you
>> need more advanced functionality, then membership is not designed for
>> that
>> and you have to write a good old class that does your
>> user-management. If
>> you need membership because you want to share the implementation
>> between
>> several other technologies (SharePoint, WCF) - then you have to live
>> with
>> the interface it provides or find whacky ways to pass more data into
>> it (which
>> work in one environment or another and kind of defeats the purpose).
>> -----
>> Dominick Baier (http://www.leastprivilege.com)
>>> Hi folks,
>>> I've been asking some ASP.NET Membership questions here and there
>>> for
>>> the past 8 days (or so) over and over again. But surprisingly, it
>>> seems
>>> that no one takes the Membership/role providers seriously - AFAIK.
>>> I've
>>> been in a fog for the past week, unfortunately. This is my last try
>>> to
>>> solve the real-world problem I've been faced with when using the
>>> ASP.NET Membership APIs or whatever they are called.
>>> In a real-world applications, having a single UserName/Password pair
>>> in a persistent storage (being SQLServer, Active Directory and the
>>> like) doesn't suffice. It is in one way or another, related to some
>>> other entities. For example, in a financial application, it's
>>> probably
>>> related to an Employee account where each employee has got one and
>>> only one UserName/Password assigned. Therefore, we will have another
>>> entity to manage (besides the membership information), in this
>>> scenario, Employee accounts.
>>> An employee should never be inserted into the persistent layer if
>>> and only if it's counterpart entity (membership info) is also added
>>> to the persistent layer! i.e., either both or neither! This simply
>>> implies that we need to do things under a given transaction.
>>>
>>> However, there's no way to ask a Membership provider to do things
>>> (CreateUser, for instance) under a given transaction and therefore
>>> we cannot keep the integrity of the whole system. Unfortunately, the
>>> Membership methods are all declared as static, therefore, developing
>>> a new SqlMembershipProvider class is not enough since there's no way
>>> to pass the Transaction object to the above-mentioned class.
>>>
>>> Any help and/or idea to solve the issue would be highly appreciated,
>>>
>>> Thank you for your time,
>>> Mehdi