You can think of Web Parts as modular Web page blocks. Each block can be added or removed from the Web page dynamically, at runtime (see my previous post about the personalized Web Parts in the Google homepage). Code for organizing and manipulating Web Parts is built into ASP.NET 2.0. All of the functionality for adding, removing, and configuring layout is automatically handled by the Web Parts system. The programmer simply builds Web Parts and assigns them to Web Part Zones. A user can mix and match Web Parts, display them in any order, and expect the configuration to be saved between site visits. All the functionality of Web Parts, including adding, removing, and listing, is managed automatically using a WebPartManager.
The personalization provider creates the link between the Web Parts feature that consumes personalization data, and the data store that contains the user information. You can configure a personalization provider and connect it to a certain database. The personalization provider supports the persistence of Web Part configurations and layouts for each user.
In Beta 1, ASP.NET application services (like personalization) include a Access data provider, and use them by default. In Beta 2, however, this functionality is replaced by support for SQL Server 2005 Express Edition, the new version of SQL Server which combines the file-based simplicity of Access databases with seamless deployment. The developer model of using the application services stays exactly the same, but the backend implementation will now be much more robust and performant.
On my machine, I installed a Virtual PC [Windows Server 2003] with this configuration :
- Visual Studio 2005 Beta 2 (Standard Edition)
- SQL Server 2005 April CTP
What happened? Well, the webpage (containing some Web Part stuff) was fired in the browser and tried to make a connection to the data store with the default Personalization Provider [SQL Server Express] to store/retrieve the user-settings. Because on my machine there's no SQL Server Express installed, an exception was thrown. I did not want to make use of SQL Server Express. Instead I wanted to use the installed database on my machine to store personalization settings. To fix this I had to do two things ...
- Configure SQL Server to store information for ASP.NET application services
ASP.NET includes a utility for installing the SQL Server database used by the SQL Server providers called aspnet_regsql.exe. The aspnet_regsql.exe tool is located in the "\WINDOWS\Microsoft.NET\Framework\2.0" folder on your Web server. This executable will bring you to a wizard that creates the aspnetdb database. Read more here.
- Change configuration of machine.config
By default (beta 2), the default provider is still SQL Server Express. ASP.NET 2.0 provides a SQL Server-based provider named AspNetSqlProvider. Providers are registered in the
section of the configuration file under the main node .
The connectionStringName attribute defines the information needed to set up a connection with the underlying database engine of choice. LocalSqlServer is the name of an entry in the
section of the configuration file. That entry will contain the appropriate information to connect to the desired database.
I've commented out the old connectionString (SQL Server Express) and replaced it by a connection to the CTP-edition of SQL Server 2005.
At the end, my Web Part page loaded just fine! It was all about configuration. Read more on personalization in ASP.NET 2.0.