Known Issues / Breaking Changes for ASP.NET in .NET 3.5 Service Pack 1

With the release of ASP.NET in .NET 3.5 Service Pack 1 some breaking changes have been introduced. This post will be used to list those changes and any workarounds / fixes for these issues.

Issue: The HtmlForm action attribute is now honored when defined in declarative markup.

Reason:
3.5 SP1 added a settable Action property to the HtmlForm type. This new feature makes it much easier for developers to explicitly set the forms action attribute for scenarios where a developer wants to use a different Url than the normal postback-generated Url. However this change also means that if the action attribute has been set in an .aspx pages declarative markup, ASP.NET will use the setting from the markup when rendering a <form /> element. Symptom:

If the form action attribute was set to a page other than the page itself, for example, the action attribute was set to test.aspx on default.aspx, exception below will be thrown.

Validation of viewstate MAC failed. If this application is hosted by a Web Farm or cluster, ensure that <machineKey> configuration specifies the same validationKey and validation algorithm. AutoGenerate cannot be used in a cluster.

Workaround I:
Previous versions of ASP.NET always ignored the action attribute if it was present in the declarative markup for a <form /> element. Developers should remove the action attribute from their declarative markup to return to the original behavior where ASP.NET renders the postback Url.

Example:
Before (the action attribute was ignored by ASP.NET as dead code): <form name="form1" method="post" runat="server" action="test.aspx"></form>
3.5 SP1 (remove the action attribute to have ASP.NET render the postback Url): <form name="form1" method="post" runat="server" ></form>

Workaround II:
Instead of removing action attribute of each page on the web site, developers could also add the following code into global.asax.<%@ Application Language="C#" %><script runat="server">void Application_PreRequestHandlerExecute() { var page = Context.Handler as Page; if (page != null) page.Init += delegate { if (page.Form != null && !string.IsNullOrEmpty(page.Form.Action)) { page.Form.Action = string.Empty; } };}</script>

Issue: Dynamic Data fails on Entity Framework data models that contain 1->0..1 and *->1 database relations

Reason:
Dynamic Data fails on Entity Framework data models that contain 1->0..1 and *->1 database relations with an error like "'System.Web.UI.WebControls.EntityDataSourceWrapper' does not contain a property with the name 'Orders.OrderID'". These types of relationships occur in many databases including Northwind and AdventureWorks. The error is caused by a naming mismatch that Dynamic Data has with the wrapper objects being returned by the EntityDataSource.

Workaround:
We have a temporary fix available at: http://www.codeplex.com/aspnet/Release/ProjectReleases.aspx?ReleaseId=16367 which replaces the data model provider with one that names the properties correctly.

Issue: After installing .NET 3.5 SP1, a web site using a derived version of the UpdateProgress control may encounter the following exception: A ProgressTemplate must be specified on UpdateProgress control with ID id.

Reason:
In the .NET Framework 3.5, the UpdateProgress control enforced the requirement of a ProgressTemplate from its PreRender routine. A derived UpdateProgress control could subvert that requirement by overriding OnPreRender in the derived control, and avoiding calling base.OnPreRender. In the .NET Framework 3.5 SP1, the UpdateProgress control now uses CreateChildControls to instantiate the ProgressTemplate, causing the requirement to be enforced at a different point in the page life cycle, and preventing the OnPreRender technique from subverting the check.

Issue: Hidden files/folders inside App_Browsers are not ignored

Reason:
3.5SP1 does not honor the fact that _vti_cnf is Hidden and it still tries to read it and parse the file inside that folder.. which results in this error.

Workaround:
At the moment the workaround is to simply delete _vti_cnf folder however we are still investigating a fix for this issue.

Issue: After installing .NET 3.5 SP1, a web site using pageBaseType now encounters the following compilation error: Make sure that the class defined in this code file matches the 'inherits' attribute.

Reason:
The behavior you are seeing is the original behavior of ASP.NET 2.0. When the .NET Framework 3.5 and Visual Studio 2008 were introduced, a bug was introduced that affected certain pageBaseType scenarios that unfortunately were not intended. It seems as if you might have run into one of these scenarios. In the .NET Framework 3.5 SP1, the bug was fixed and these scenarios no longer occur; pageBaseType again works the same as in ASP.NET 2.0, as requested by customers. Unfortunately, this means that customers who have relied on the unintended behavior that was introduced in the .NET Framework 3.5 will now encounter problems when they run their applications.

We are now evaluating creating a HotFix for these scenarios and providing workarounds for customers to help with this issue.

Here are some details about the issue; we will post a more detailed description soon. The mismatch is caused by the class in the code file not being assignable to the pageBaseType that is defined in the web.config file. The sequence that occurs is this:

- During code generation for a page (MyPage.aspx) in a Web site, ASP.NET creates a separate class from the class that is defined in the code-behind file source (MyPage.aspx.cs). The web.config files pageBaseType value can be used in cases where you want all pages to have certain properties. It applies to all pages, not just to pages that do not have code-behind files.

- If MyPage.aspx has a CodeFile attribute and therefore inherits from a class that is defined in MyPage.aspx.cs, the class defined in MyPage.aspx.cs must extend the pageBaseType class.

Workarounds:
1. If the pageBaseType class (for example, MyBasePage) is not needed for all pages, you can remove it from the web.config file, or;

2. Where pages do require the pageBaseType value, modify the classes in the code-behind files to extend the base type. In the filename.aspx.cs code-behind file, make sure that the class inherits from the pageBaseType that is specified in the web.config file (for example, public partial class CodeFileClass : MyBasePage instead of public partial class CodeFileClass : System.Web.UI.Page).

3. An alternative workaround will allow you to add the following attribute to your page directive:

CodeFileBaseClass="System.Web.UI.Page"