I spent a good deal of time last week updating all my ASP.NET 2.0 beta 1 code samples for beta 2. A LOT of stuff changed, so I compiled the following list to help others who are going down the same path. The list is by no means comprehensive, but it does document some of the more significant changes that you need to be aware of when porting beta 1 code to beta 2.
The @ Page directive’s CompileWith and ClassName attributes changed to CodeFile and Inherits, respectively.
// Old:
<%@ Page CompileWith=”Default.aspx.cs” ClassName=”_Default” … %>
// New:
<%@ Page CodeFile=”Default.aspx.cs” Inherits=”_Default” … %>
In beta 1, a code-behind class’s base class was specified in code generated by ASP.NET. In beta 2, the base class—Page for pages, MasterPage for master pages, and UserControl for user controls—is specified in your code:
// Old:
public partial class _Default
// New:
public partial class _Default : System.Web.UI.Page
In beta, a code-behind class’s event handlers could be private and were declared that way by Visual Studio. In beta 2, event handlers should be protected rather than private.
// Old:
void Button1_Click (Object sender, EventArgs e)
// New:
Protected void Button1_Click (Object sender, EventArgs e)
In beta 1, connection strings were read from the <connectionStrings> configuration section with ConfigurationSettings.ConnectionStrings. In beta 2, they’re read with WebConfigurationManager.ConnectionStrings instead. (WebConfigurationManager is a member of the System.Web.Configuration namespace.)
// Old:
string connect = ConfigurationSettings.ConnectionStrings[“Northwind”].ConnectionString;
// New:
string connect = WebConfigurationManager.ConnectionStrings[“Northwind”].ConnectionString;
RegisterClientScriptBlock, GetCallbackEventReference, and other Page methods that deal with client-side script are now considered obsolete and are flagged as such by the compiler. Developers should call the equivalent methods in the ClientScriptManager class, which can be accessed through the Page class’s ClientScript property.
// Old:
RegisterClientScriptBlock (“MyScript”, “…”);
// New:
ClientScript.RegisterClientScriptBlock (typeof (Page), “MyScript”, “…”);
As expected, Access providers such as AccessMembershipProvider and AccessProfileProvider were removed from the product. Access has been replaced by SQL Server Express as an “official” ASP.NET data store.
The DynamicImage control was removed from the product, as was support for ASIX files. ImageField was not removed but was severely crippled. It no longer supports the DataField property, completely removing from ASP.NET 2.0 the ability to declaratively fetch and display database images.
The configuration API underwent many changes. For example, Configuration.Update changed its name to Configuration.Save and ConfigurationSection.UnProtectSection changed to ConfigurationSection.UnprotectSection. Many ConfigurationSection methods and properties such as ProtectSection and IsProtected were moved to the SectionInformation class, an instance of which can be accessed through the ConfigurationSection.SectionInformation property. In addition, you now call WebConfigurationManager.OpenWebConfiguration rather than Configuration.GetWebConfiguration to access configuration settings.
// Old:
Configuration config = Configuration.GetWebConfiguration (Request.ApplicationPath);
ConfigurationSection section = config.Sections[“connectionStrings”];
if (!section.IsProtected) {
section.ProtectSection (“…”);
config.Update ();
}
// New:
Configuration config = WebConfigurationManager.OpenWebConfiguration (Request.ApplicationPath);
ConfigurationSection section = config.Sections[“connectionStrings”];
if (!section.SectionInformation.IsProtected) {
section.SectionInformation.ProtectSection (“…”);
config.Save ();
}
<
p class=”MsoNormal”>Membership providers now support strong password policies through their MinRequiredPasswordLength, MinRequiredAlphanumericCharacters, and PasswordStrengthRegularExpression properties. By default, the SqlMembershipProvider class used by the Membership.CreateUser method (and by extension, the CreateUserWizard control) require that passwords be at least 7 characters long and contain at least one non-alphanumeric character.