I was trying to use the Profile provider of YAF and integrate or extend it to work with the default asp.net Membership and Role Providers.

However, unless I am not understanding something, it appears impossible. The Yaf Profile provider appears tightly coupled to the YAF Membership provider. In the stored procedure yaf_profile_getprofiles, a join is done:

SELECT m.UserName, m.LastActivity, p.*
FROM [smarter].[yaf_prov_Membership] m, [smarter].[yaf_prov_Profile]

This works I'm sure for the purposes of YAF, but does this not break the idea of independant-plugable providers? Would it not make more sense keep the profile provider independant of the membership provider? i.e. duplicate the information in the profile table, thereby breaking the dependancy and use a trigger on the membership to update the profile's 'username' and 'last activity'? Or in reality, if the username and last activity date are needed, they should be retrieved from the membership, not from the profile (although I have a hunch this design is for performance reasons).

Just a comment if it helps and if I'm out to lunch.. I can accept it, no need to flame me. IMHO, if an eye is kept to making YAF easily integrated into other projects, it would be very very popular.

A couple reasons for not using the asp.net profile provider.

One is laziness/cutting corners. I thought I might be able to add my profile requirements to the YAF profile provider and use it in the main project, thereby gaining the advantages of what looks to me to be a far better designed profile provider than the ASP.NET.

The other, is I wasn't sure it would work 'out of the box' without running into hidden side-effects or faulting functionality later down the road. Since you have a custom provider, you could theoretically add functionality in a future release that the default provider won't provide.

But I might just give it try. From what you implying, if I just add the YAF profile properties to the AspNetSqlProfileProvider in the web config and it'll work? And you can promise me you won't break the API of the provider in a future release of YAF?

And thank you for the reply. I see now where you are coming from, and the issues with the microsoft design.

Thank you, that is a really easy solution. I totally forgot about the ability to 'inheret' in the config file. Obvious is code, but not so obvios in XML. I was going off the deep end tring to add yaf profile related properites directly into the default provider itself.

I had the last version of YAF 95% integrated into a custom project and when I saw this beta version was going to use the membership, role, profile providers I stopped. This version is such a treat to work with. Nicely done.