I'm going to unravel the dependency because I *have to*. I don't want to and can't use the YAFMembership provider and since I have a custom profile provider, I can't use the SqlProfileProvider.

By the way, the SqlProfileProvider does work fine with YAF. That is because it stores the profile properties packed as xml (?) in the table, so it will just add the YAF profile properties into the string and save/retrieves them. It is very independant this way. The YafProfileProvider is never used when you do it this way... so if I'm not mistaken, that basically disables the caching built into the YafProfileProvider. (correct me if i'm wrong)

I've edited this post a few times, since it is hard to find an answer. I'm not sure if this is a YAF design issue, or a Microsoft Provider interface problem.

If you look at the ProfileProvider interface...

public ProfileInfoCollection GetAllInactiveProfiles( ProfileAuthenticationOption authenticationOption, DateTime userInactiveSinceDate, int pageIndex, int pageSize, out int totalRecords )

The ProfileProvider interface needs an activity date, which in YAF is stored in the membershipProvider. I don't think that is a requirement of the membershipProvider, but even the ASP Membership provider stores a lastLoginDate. If this is going to work, I'd need to add an activity date to the YafUserProfile, and base everything off of that.

On that note... I'm not going to try to unroll the dependencies... it is too much work within YAF and I don't have enought time to start breaking things. I'll just make my customProfileProvider handle the YAFUserProfile properties and be done with it. But it is a shame, because I think I'll lose the great caching that they put in the YAFUserProfile.

I've read your posts over and over and I'm confused. You keep saying you have a custom profile provider, but keep talkin about code changes to the yaf profile provider. I understand your complaint about the yaf profile provider being dependent on use the yaf membership provider, but since you're not using either one what's the problem??

Your custom profile provider should be written to handle any properties passed to it. You can implement the caching yourself, too. Yaf just uses the System.Web.HttpContext.Current.Cache to store a dictionary of the profile properties. You can do that or use the session or whatever caching mechanism you want.

Basically, the profile provider only needs it when pulling inactive profiles to define what "inactive" means

And if you read the post multiple times, you'd see that I *was* trying to use the yaf profile provider and use it in conjunction with my custom profile provider.

I was hoping I could just 'plug-in' the YAF profile provider and it would handle its own profile information.

I think you are confused about my intent. I'm trying to be helpful. I brought up this topic, to give information to others trying to follow in my footsteps, give some details of what I tried, plus point out an area/idea that could improve yaf and give the information required to do it. I even got into the code to see if it would be simple to implement, but its not.

I understand your point that *ideally* a profile provider should be able to dynamically handle whatever properties are added to it. You are basically implying that the responsibility is for my custom profile provider to add the YafUserProfile to it.

I can add the YAf properites to my provider in 15 minutes. But I was hoping not to tie my application to YAF if I didn't have to. I have spent a lot more than 15 minutes, because that goal was worth it to me.

I saw that the YAF dynamically handles properties, but if I add a one-to-many relationship like save a List<string> as a profile property, will it handle that? The microsoft provider would, but I don't think the YAF one will. The effort it takes to make a provider that handles everthing, is just not worth the effort.

TypeConverter converter = TypeDescriptor.GetConverter(propertyValue.Property.PropertyType);
if (converter.CanConvertTo(typeof(string)) && converter.CanConvertFrom(typeof(string)))
    value = converter.ConvertToString(propertyValue.PropertyValue);
else
{
    XmlSerializer xs = new XmlSerializer(propertyValue.Property.PropertyType);
    StringWriter sw = new StringWriter();
    xs.Serialize(sw, propertyValue.PropertyValue);
    value = sw.ToString();
}

Basically, the profile provider only needs it when pulling inactive profiles to define what "inactive" means

On the surface this appears to be the deal breaker in the membership-profile provider interfaces. It implies that the profile needs to get this information from the membership. I'm not sure why they would have defined 'inactive profiles' in the interface.. since it should be an inactive membership that gets its corresponding profile.

But if you think about it, it is left up to the implementers to define the contracts between the two and explicity define the requirements of each. If YAF wanted to break the dependency, they could add an activity date to the profiles and explicitly say that it needs to be manually updated, however/whenever someone wants it to be. And from what I saw, I think there would be need to store the username as well in the profile for lookup purposes.

It's not that it's the *ideal* way of doing it, it's *the* way of doing it. Anything less is a poor design.

I don't think I agree with you here. I thnk having yaf "say" that you need to manually update the last activity date in the profile would hinder integration into existing sites. It's like standards vs. non-standards. You may not agree with the standard and think your way is better, but since it's not standard, everyone else will have to bend over backwards to get their stuff to work with your stuff.

http://msdn.microsoft.co...us/library/d8b58y5d.aspx 

provider Specifies a provider specific to the property. By default, all properties are managed using the default provider specified for profile properties, but ***individual properties can also use different providers****.

http://msdn.microsoft.co...us/library/0580x1f5.aspx 

DeleteInactiveProfiles method

Takes as input a ProfileAuthenticationOption value and a DateTime object and deletes from the data source all profile information and property values where the ***last activity date*** is less than or equal to the specified date and time ..snip...

CREATE TABLE Profiles
(
  UniqueID AutoIncrement NOT NULL PRIMARY KEY,
  Username Text (255) NOT NULL,
  ApplicationName Text (255) NOT NULL,
  IsAnonymous YesNo, 
  LastActivityDate DateTime,
  LastUpdatedDate DateTime,
    CONSTRAINT PKProfiles UNIQUE (Username, ApplicationName)
)

CREATE TABLE ProfileData
(
  UniqueID Integer,
  ZipCode Text (10),
    CONSTRAINT FKProfiles2 FOREIGN KEY (UniqueID)
      REFERENCES Profiles
)

I don't think I agree with you here. I thnk having yaf "say" that you need to manually update the last activity date in the profile would hinder integration into existing sites.