ASP.NET Profile sure has some weird quirks

When you read a property from your Profile provider, you'd think that it will only call the provider's GetPropertyValues method, right? Well as it turns out, it's calling the SetPropertyValues as well, on every call. I can't for the life of me figure out why it would do that.

Then, when I was looking a little deeper, I found that the framework will call FindProfilesByUserName whenever you try to hit Profile.LastActivityDate or Profile.LastUpdateDate. The SQL provider does this and it looks for just one record in one page (the method is intended to do paged data calls). So what happens if your provider looks for partial matches, which is kind of the point if you're worried about getting pages of data?

The more I get into this stuff, the more hackish it seems. I think Membership and Profile are great ideas, but the implementation leaves a lot to be desired. 


  • 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 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.

  • Performant is not an adjective, it's a noun. :) Sorry, just one of my pet peeves.

    I agree with everything you're saying. However, the reason I wanted to use these API's on my forum project is because the single biggest issue for people who need to integrate is there's no other common API. I'd like to see ASP.NET appeal to more of the audience currently interested only in PHP or Ruby or whatever. I want to put something out there that says, "Hey, you can integrate this into your own site with just some config changes."

    Perhaps I should be rolling things my way instead, and have people write a provider through my own API. That wouldn't be my first choice.

  • Nope... I've got one line on Page_Load looking at a string. That certainly shouldn't be triggering a save by your description.

  • 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"

  • works as indicated by ScottGu.

Comments have been disabled for this content.