UPDATE 08/27: Found a couple of more changes
We’re using this forum post to track our Breaking Changes / Known issues in the SP1 release. Initial text is below but please feel free to link to this forum post from any blogs etc...to track these changes.
I'll also keep this blog post updated with any changes...
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: 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 it’s 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: 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.
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 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"