Profiles in Asp.net

  • Thread starter Thread starter Carles Company Soler
  • Start date Start date
C

Carles Company Soler

Hello,
I'm trying to use profiles in an ASP.Net web app. I write the following code
in Web.config:

<profile>
<properties>
<add name="nombre" />
<add name="visites" type="System.Int32" defaultValue="0" />
</properties>
</profile>

Supposedly, this shoud generate some classes to work with the profile, but I
don't get any code generated. What could go wrong?

Thanks,
 
It does some tricks behind the scene to make it available. Once you have a
profile set up correctly, you should be able to see the nombre and visites
in Intellisense in Visual Studio. I believe you have to compile at least
once to see these properties. You will not see this in other methods, unless
you want to run something like Reflector on the compile assemblies. This is
a bit cryptic, until you get used to the ASP.NET compile model,which is
slightly different in a web app, website and precompiled web - just to make
things fun. They actually aren't that different, but they sure appear that
way when you look at the /bin folder.

The remainder of this post is background, which you may already know. It is
oversimplified, so it is possible I will be "corrected" since I am being
rather high level on this. I post this not only for you, but for others who
might read this.

The storage of the fields is in the ASPNET_PROFILE table, unless you have
built a custom Profile provider (in that case you can make your own
classes). It is an encrypted string in the table (PropertyValues and
PropertyValuesBinary - not 100% sure the binary is encrypted, but it is not
easy to unwind regardless). There is another string that shows where in the
string the property lies (PropertyNames). Here is an example from an R&D
example I wrote:

SecondQuestionName:S:0:1:SecondQuestionSalt:S:1:24:SecondQuestionAnswer:S:25:24

What this means:

Field Type Start Length
SecondQuestionName S=String 0 1
SecondQuestionSalt S=String 1 24
SecondQuestionAnswer S=String 25 24

Now, PropertyValues and PropertyValuesBinary are dupes of the actual user
stored information. The binary version is used by the system and is a
Microsoft thing, as mentioned. Without Reverse Engineering their stuff, you
cannot use this. But, the PropertyValues is encrypted and you can decrypt.
If you are using the Microsoft Profile objects you do not need to decrypt,
as it does it for you, but it is possible to do so if you need (in general,
this is reinventing the wheel).

The encryption is specified in the config file.

Hope this helps!

--
Gregory A. Beamer
MVP, MCP: +I, SE, SD, DBA

Subscribe to my blog
http://feeds.feedburner.com/GregoryBeamer#

or just read it:
http://feeds.feedburner.com/GregoryBeamer

********************************************
| Think outside the box! |
********************************************
 
I have learned to avoid using the default Profile provider. The main reason
is the way it stores data in the profile as a delineated blob which makes
accessing and searching Profile data icky and in some circumstances
impossible (as I recall).

It seems Scott Gu also agreed with the general furor that arose soon after
2.0 was released and a Table Profile Provider was released.

I have used the Table Profile Provider which stores data as one would expect
in respective fields and rows as opposed to a single row with all data
tossed in as if the Table were a teenager's closet. The downside seems to be
no relational model for any instance of a table lest we write our own
provider; no support for foreign keys and related tables but at least data
can now be retrieved via search.



Cowboy (Gregory A. Beamer) said:
It does some tricks behind the scene to make it available. Once you have a
profile set up correctly, you should be able to see the nombre and visites
in Intellisense in Visual Studio. I believe you have to compile at least
once to see these properties. You will not see this in other methods,
unless you want to run something like Reflector on the compile assemblies.
This is a bit cryptic, until you get used to the ASP.NET compile
model,which is slightly different in a web app, website and precompiled
web - just to make things fun. They actually aren't that different, but
they sure appear that way when you look at the /bin folder.

The remainder of this post is background, which you may already know. It
is oversimplified, so it is possible I will be "corrected" since I am
being rather high level on this. I post this not only for you, but for
others who might read this.

The storage of the fields is in the ASPNET_PROFILE table, unless you have
built a custom Profile provider (in that case you can make your own
classes). It is an encrypted string in the table (PropertyValues and
PropertyValuesBinary - not 100% sure the binary is encrypted, but it is
not easy to unwind regardless). There is another string that shows where
in the string the property lies (PropertyNames). Here is an example from
an R&D example I wrote:

SecondQuestionName:S:0:1:SecondQuestionSalt:S:1:24:SecondQuestionAnswer:S:25:24

What this means:

Field Type Start Length
SecondQuestionName S=String 0 1
SecondQuestionSalt S=String 1 24
SecondQuestionAnswer S=String 25 24

Now, PropertyValues and PropertyValuesBinary are dupes of the actual user
stored information. The binary version is used by the system and is a
Microsoft thing, as mentioned. Without Reverse Engineering their stuff,
you cannot use this. But, the PropertyValues is encrypted and you can
decrypt. If you are using the Microsoft Profile objects you do not need to
decrypt, as it does it for you, but it is possible to do so if you need
(in general, this is reinventing the wheel).

The encryption is specified in the config file.

Hope this helps!

--
Gregory A. Beamer
MVP, MCP: +I, SE, SD, DBA

Subscribe to my blog
http://feeds.feedburner.com/GregoryBeamer#

or just read it:
http://feeds.feedburner.com/GregoryBeamer

********************************************
| Think outside the box! |
********************************************
Click to expand...
 
Back
Top