Don’t spend several hours of your precious late-night development time, like me, trying to figure out why the hell your Visual Studio does not work the way Scott Mitchell’s does:
“After defining your Profile properties, the ASP.NET engine automatically creates a
ProfileCommon
class that has properties that map to the properties defined inWeb.config
(which allows for IntelliSense and compile-time type checking). This class is dynamically recreated whenever the properties defined inWeb.config
are modified and automatically works with the currently logged on user’s profile… For example, to read the currently logged on user’sHomepageUrl
property from an ASP.NET page, simply useProfile.HomepageUrl
. In fact, as soon as you type inProfile
and hit period, IntelliSense brings up the various properties. Cool, eh?”
Mine didn’t work like that. Whenever I typed profile VS just sat there looking at me like I was dumb and in fact gave me a little red squiggly underneath the word, telling me that it couldn’t make heads or tails of it. I fought with Visual Studio for a while, assuming I had forgotten an import statement somewhere, forgotten to reference an assembly, etc., but nothing I tried worked.
By 2:00 AM I was beginning to think that either Scott Mitchell was a liar or I had missed a step somewhere. I went over everything I had in place several times and I was sure that I wasn’t at fault. I started punching in Scott’s number on speed dial when I realized that I better be absolutely certain that I had all my stuff straight before calling him. Finally, I found something on forums.asp.net that mentioned ProfileCommon not being generated for Web Applications projects and that I should take a look at the ASP.NET WebProfile Generator instead. So Scott was right, but I wasn’t wrong!
The WebProfile Generator download includes source code, but more importantly includes an .msi that installs the the tool into Visual Studio 2005. Once installed you can then right-click on a web.config file, choose “Generate WebProfile” and your strongly typed profile settings will be created. How it works is that a new class is generated that inherits from ProfileBase and includes the properties identified in the profile section of your web.config. This effectively replaces the ProfileCommon class with the WebProfile class which you can instantiate with a name of “Profile” if you would like - thus giving you the exact same syntax that you would have if the ProfileCommon was autogenerated.
I did find an error in the readme that states:
To use the web profile class in a page create an accessor like this:
private Profile WebProfile
{
get { return new WebProfile(Context.Profile); }
}
I don’t know if that’s some crazy VB stuff or not, but in the C# world it should actually be “private WebProfile Profile”, where the type is WebProfile and the name you are giving it is Profile. Additionally, because you may use this quite a bit, I would recommend not placing it in every page where you need it, but instead in a BasePage class that you use as a base class for your pages.
One last note - if you make any changes to the profile properties in the web.config you will have to regenerate the WebProfile class. It’s easy enough, though, just right-click the web.config file and do the same thing you did before.