ASP.NET Profile and Web Application Projects
I talked at length about the ASP.NET Provider Model pattern and the ease of implementing several built-in services you can have for free with ASP.NET 2.0 in my previous series of posts. In this post, I will be discussing a few issues I ran into using the Profile system with the Web Application project template instead of the Web Site project template as found in Visual Studio’s list of default project templates.
The crux of the issue is that Visual Studio doesn’t automatically generate the Profile proxy class object when using the Web Application project template, like it does with the Web Site project template. This proxy class can be used to obtain access to strongly-typed properties representing the custom Profile fields you specified in your Web.config. This is a very convenient way to access a user’s Profile data, both for authenticated and for anonymous users.
Let’s discuss the issue a little further and then I will present a workaround that I found and have successfully implemented in my own project.
VS Project Templates: Web Site vs. Web Application
It appears that Microsoft has tried to differentiate these two project templates as much as possible in Visual Studio 2008. In 2005, you would go to the New Project dialog window and you would see these two Web project templates side-by-side, wondering what difference it would make if you chose one over the other. However, in Visual Studio 2008, it appears they reworked this whole dialog and menu system for starting a new project so that you would never see these two project templates side-by-side. In 2008, you have more than one option in the File menu for starting a project; those options are File | New | Project and File | New | Web Site. The first option is the one that will get you to the ASP.NET Web Application template, while the second takes you to the ASP.NET Web Site project template.
Now as for the differences between these two templates, I’ll outline a few of the main differences and give a little bit of history of how these two templates came to coexist. The history in a nutshell is that Visual Studio 2005 came out with the Web Site project template to replace the old, but proven project configuration used by ASP.NET 1.x. In the opinion of many, the old template better encouraged Object-Oriented design practices. The new template had no project file for explicitly delineating what files where included in the project and namespacing was quite cumbersome, as the only painless design was to let everything pile up into one big default namespace. A few other changes involved taking ASP.NET back to compiling on the fly at the web server and also drastically changing the organization of UI template and code-behind files. It appears the intention was to closely mimic the configuration and deployment practices of popular agile languages like PHP and Ruby on Rails.
In the Service Pack 1 of Visual Studio 2005, Microsoft decided to resurrect the older project template under the name of Web Application. There is evidence to suggest that Microsoft considers this latter project template an "enterprise" project type, as compared to the casual Web Site project template. With the advent of Visual Studio 2008, it is apparent that Microsoft is committed to supporting both project types for at least a little while. For a more detailed discussion of the history and differences of these two project templates, I suggest the following blog post by Stephen M. Redd:
Web Profile Builder by Joe Wrobel
The ability to retrieve and update your custom Profile fields at design time via strongly-typed properties on the Profile proxy class is extremely convenient. Unfortunately, you get no such compiler and intellisense love if you are using the Web Application project template for your site.
In trying to find a workaround, I came across a blog post by Joe Wrobel introducing a project he worked on to solve this issue. It’s called the Web Profile Builder (here’s a link to it’s project page on MSDN Code Gallery) and it was based on a project called the Web Profile Generator, which was a Visual Studio 2005 Add-In project found on CodePlex. The latter project seems to have not been worked on in over a year and a half, nor does it seem to be compatible with Visual Studio 2008. Hence, Joe feeling the need to start up on his own project, with a few improvements on the side of course.
In Joe’s introductory post to the project, he mentions he changed the Visual Studio integration from being a plug-in to being an MSBuild Build Task. The method for incorporating the Build Task into your project is to add a line into your project file (the one with file extension .csproj). In case you weren’t aware, Visual Studio project files are just MSBuild build scripts. For details about where to put this line in the file (and about a message Visual Studio pops up when it detects you’ve mucked with the project file), be sure to check out Joe’s post on the Web Profile Builder project.
There are a couple of other things I need to point out about using the Build Task that weren’t entirely clear to me beforehand. The build task actually generates a C# code file that is intended to be included into your project; once it’s generated, you need to go to the Solution Explorer and explicitly add it as a file in your project (one way is through the Add | Existing Item menu option). One of the main things that helped me decide to use this solution and how to configure it was reading two blog posts from Anthony Grace; the second post below has a great excerpt apparently from the Web Profile Builder documentation that explains the process I outlined above in a bit more detail:
Also, it is not necessary to do the steps in the Extended Usage section of Joe’s blog post. They are optional configuration points in the Web.config where you control the className, nameSpace, directory, and fileName of the auto-generated code file. Most of the defaults are fine, but in my case I wanted the generated file to end up in an App_Code directory instead of in the root of the project folder. If you decide to add in this custom configuration, you need to be aware that you must add the following XML namespace to the configuration root element of your Web.config:
xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0"
Finally, it should be noted that if the website you are building is under source control, you will likely want to always keep this auto-generated code file checked out in order to prevent the file from having its Read-Only attribute set when it’s checked in. If you don’t have it checked out, the build will throw out a warning and the generated code file will not be regenerated if changes in your Web.config need to be propagated to it.
Conclusion
With all of this in place, you should be able to use the Profile proxy class object in your ASPX code-behind files, just as I gave examples of in my previous post about the ASP.NET Profile system. Although in my case, I mostly used the static method GetProfile from the auto-generated WebProfile class (the name the Visual Studio Build Task selects by default).
As I mentioned when I first started the ASP.NET Provider Series of posts, my next blog post will be about some advantages of using this Provider system on IIS 7 and a few issues when your ASP.NET website contains non-ASP.NET content:
