Known issues for ASP.NET with .NET 3.5 SP1

  • Article

Just wanted to give a heads up on two issues that we are aware of that were introduced with .NET 3.5 SP1.

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 form’s 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 page’s declarative markup, ASP.NET will use the setting from the markup when rendering a <form /> element.

Workaround:
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>

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.

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 file’s 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"

 

Both of these issues are also mentioned here.