It’s been a long while since I last used the ASP.NET Profile provider. It’s a shame, too, because it just works with very little development effort:
- Membership tables installed? Check.
- Profile enabled in web.config? Check.
- SqlProfileProvider connection string set? Check.
- Profile properties defined in said web.config file? Check.
- Write code to set value, read value, build and test. Check. Check. Check.
Yep, I thought the built-in Profile stuff was pure gold until I noticed how the user-based information is persisted to the database. It’s stored as xml and, well, that was going to be trouble if I ever wanted to query the profile data. So, I have avoided the super-easy-to-use ASP.NET Profile provider ever since, until this week, when I decided I could use it to store user-specific properties which I am 99% positive I’ll never need to query against ever.
I opened up my ASP.NET MVC application, completed steps 1-4 (above) in about 3 minutes, started writing my profile get/set code and that’s where the plan broke down. Oh yeah. That’s right. Visual Studio auto-generates a strongly-type Profile reference for web site projects but not for ASP.NET MVC or Web Applications. Bummer. So, I went through the steps of getting a customer profile provider working in my ASP.NET MVC application:
First, I defined a CurrentUser routine and my profile properties in a custom Profile class like so:
And then I replaced the existing profile configuration web.config with the following:
Notice that profile is enabled, I’ve defined the defaultProvider and profile is now inheriting from my custom MemberPreferencesProfile class.
Finally, I am now able to set and get profile property values nearly the same way as I did with website projects: