Jeff and .NET

I have to say i am not impressed at all with the stock ProfileProvider.  I would only use it for the most simple of applications.

The fact that it stores it's values in a key/pair string (or serialized form, can't remember) in an ntext column should be enough reason for anybody to ditch it and write their own custom provider.  At the very least they could have provided a sql2k5 option to use an nvarchar(max) and preserve creating profile properties in web.config, but really, using a single column which needs parsing or deserializing every time to get a single property, lame.

I agree, my limited experience using it has given me the same hackish feeling.

Its stuff like this that helped convince me that all I really wanted was my own strongly typed profile class which I load and persist the way I want.  Yes, it does "limit" things by not allowing you to just add a new member in the config file (or even programmatically), but in a real enterprise app that just isn't really going to happen anyhow.  Instead I'm much more concerned with building a scalable and performant application, and I simply want to expose some user properties as part of the built-in profile class.  So my properties are stored in a normalized database table so that they can used and versioned outside of the asp.net profile infrastructure if I see a need.  I also optimize things for my anonymous users by loading and persisting their profile information in cookies -- maybe not something you want to do, but I have that flexibility.

I believe it is calling your SetPropertyValues method because you are using a complex type object (and not a primitive type like string, int, etc).  In cases like these the Profile API can't really tell whether the object has changed since there is no standard way to tell with a nested graph of objects like this (although if you wrote an underlying provider you could diff the results with the latest serialized and determine it based on that).

There is a configuration switch in the <profile> section of web.config that allows a developer to turn off the automatic update behavior of Profile:  <profile automaticSaveEnabled="false" />.  If autosave is turned off the developer can use their own logic for dirty detection, and when necessary call Profile.Save().  This avoids you having to build a provider at all and would give you total control over the save semantics.

To answer Chris' question above, the built-in Profile Provider does persist settings as an XML blob as opposed to within a strongly-typed table.  However, you can download this Profile Provider from the web to achieve what you are after instead: http://weblogs.asp.net/scottgu/archive/2006/01/10/435038.aspx  The provider allows you to map the Profile API against either a table directly or against SPROCs (where you could implement your own shredding behavior).

For the second issue, this occurs because the LastActivityDate and LastUpdatedDate are not considered part of the profile data itself.  The profile properties are defined in the profile schema, and we didn't want to require that these two dates always existed as built-in profile properties.  Instead we consider these to be administrative information about the profile.  For convenience we added the properties to the base profile type so that developers wouldn't have to explicitly write the code to both load the profile data, and then look up these two tracking dates.  Instead we lazy load the two dates from the default provider the first time they get accessed.  Realistically though we don't expect developers to normally access these values for anything other than non-admin purposes.

Hope this helps,

Scott

P.S. The benefit of the provider model is that you can swap-in implementations of your own if you want too.  This gives you the benefit of a single API that multiple apps or app frameworks can standardize around, but also all the flexibility of customization if you want.  So I'd definitely recommend investigating how to use the built-in APIs where possible.

What does your overall profile definition look like?

And have you tried the automaticSaveEnabled="false" setting I suggested above?

I hacked this problem by editing one of the stored procs that the profile calls. Sorry I can't remember the name of the proc, but shouldn't be to hard to find it. The stored proc had an update for lastactivitydate, and by removing the update I managed to get users Gender without updating the lastactivitydate.

It seems kinda hazardous, but it hasn't caused any unwanted behaviour in our ~300 user app.

The name of the proc is "aspnet_Profile_GetProperties"

<profile automaticSaveEnabled="false" /> works as indicated by ScottGu.