How to parse PropertyName PropertyValue data?

Question

Hello,

Two web applications I'm working with are using the ASP.NET membership and each have areas for user information which use this Property name/value storage method in the database.

Here is an example:

PropertyNameValues

publicEmail:S:0:19:yahooIM:S:19:0:timezone:S:19:2:commonName:S:21:4:birthdate:S:25:81:signatureFormatted:S:106:0:gender:S:106:1:fontsize:S:107:1:signature:S:108:0:dateFormat:S:108:15:enableEmoticons:S:123:4:webLog:S:127:0:enablePostPreviewPopup:S:127:5:location:S:132:12:bio:S:144:0:webAddress:S:144:0:interests:S:144:0:icqIM:S:144:0:aolIM:S:144:0:language:S:144:5:occupation:S:149:0:msnIM:S:149:0:

PropertyValues

[email protected]<?xml version="1.0" encoding="utf-16"?>
<dateTime>0001-01-01T00:00:00</dateTime>20ddd, MMM d yyyyTrueFalseTest Testing-US

I can see the jist of how it works, name values show at what length in the property value string to begin grabbing and when to end - but is there an existing function to split these apart into an array or something?

Thanks!

Answer 1

It looks like you're referring to the ASP.NET Profile system.

Within the code-behind of an aspx page, just use Profile.publicEmail, Profile.yahooIM, etc. There's an automatically generated class that parses that out for you. See the linked article for more details.

Answer 2

How this works depends on if you are using a "web site" or a "web application" project type. If you are using a regular asp.net web site project, you will have a dynamically generated Profile object you can use to fetch user properties from.

If your application is MVC or a Web Application Project though, you will have to make your own profile object. I recommend you grab the web profile builder. This tool creates the ProfileCommon object that is needed to get at the profile data.

In general, I personally have found through repeated exposure that the Profile provider system supplied in asp.net is quite dreadful for storing actual user information (the kind of stuff you are using it for). The profile provider mechanism is great for stuff like user preferences (stuff usually called personalization) such as "always show details" or "I prefer the green background". The reason is that the profile system only makes the profile data easily accessable within the request of the one user. If you have admin tools that need to read from multiple user's profiles, you will find that performance will quickly degenerate, and getting at the profile data is actually quite difficult.

For these reasons, I recommend that you consider not using the profile system for the kind of data you are storing there. You will be a lot better off rolling your own tables and objects to store and fetch this particular kind of info. But if you never need to access the data for more than one user at a time, the built-in profile stuff is alright.