A few weeks ago Scott Guthrie (Fearless leader of IIS, ASP.NET and Visual Web Dev as he self describes in his profile at ww.asp.net J) announced a new type of project for web application development in Visual Studio 2005. This is called the Web Application project type and makes ASP.NET 2.0 behave the same way it did in the Visual Studio 2003 days. This is something we have been asking for quite some time because we believe that as an enterprise developer you need full control over the application you are building.
While test driving the latest technical preview (found here) of the web application project type I ran into a little problem using the profile API. In a Visual studio 2005 web site project you are used to the Visual Studio behavior that from your page you can get strongly typed access to the profile properties you defined in your web.config file. In a web application project you won’t find this behavior in the current bits. Because in web site projects the environment dynamically compiles the web.config defined properties into a profile class your page will be using, you get this behavior. This dynamic behavior is just what the web application project type is ruling out and gives you full control over what is compiled into one assembly. So it does not contain the dynamic generated profile class. My big question was how I could use the profile API when this behavior is missing. The answer is quite simple; you van just access the profile properties using the profile variable found in the current http context user object. See code snippet below:
ProfileCommon p = (ProfileCommon)HttpContext.Current.User.Profile;
p[“myProfileProperty“] = 5;
While this is a workable way of accessing the profile API, I would wait just a little bit before coding the profile like this. I suggested that one would like to have the same experience as with the web pages in the form of a .designer file (like in windows forms) that contains the design time entered profile information. The thing is that they already considered this as an option, but because of time constraints Scott could promise that this behavior (using a web.config.designer file )will make it to the release version of web application projects.
I certainly hope so, but I must say that I am already very happy with the fact we now get Web Application projects and full control back for building web applications. Whether this feature makes it or not to the final bits, we will use this type of project defacto for the web applications we build.