ASP.NET 2.0 product design changes between Beta 1 and Beta 2(a new message from asp.net forum)
Today the Web Platform and Tools Team is proud to announce two product design changes made directly in response and in conjunction with community feedback. The changes, detailed below are focused around two key areas. First, in September, we announced changes to the special private ASP.NET 2.0 directory naming. Based on feedback, we are revising these names. Second, we are making changes to the compilation model in order to enable ASP.NET 1.x like behavior where the .aspx file will now by default remain separate from the code-behind binary when pre-compiled (and can optionally be fully compiled into the binary). We think these changes will address significant areas of customer concern, further simplify upgrading applications between ASP.NET 1.x and 2.0, and we are excited that they will begin shipping in the next Community Technology Preview, scheduled for November. Below, please find detailed information about each of these product changes.
Any questions should be addressed to this thread...
An easier on the eyes version of this announcement can be found at:
http://msdn.microsoft.com/asp.net/whidbey/beta2update.aspx
ASP.NET 2.0 Directory Naming Changes
SUMMARY
Last month, The Web Platform and Tools team announced a change in the special directory naming of ASP.NET 2.0. In discussing this change with customers and community, we received a strong response that prompted us to reconsider the proposed syntax of application_xxx. After reviewing the feedback, re-thinking our goals, and looking at all possible options and feedback, we have decided to revise the changes in order to create a simpler and more usable syntax while also improving compatibility with existing ASP.NET 1.x applications.
BACKGROUND
ASP.NET uses a number of special directories in an application root in order to maintain application contents and data. In previous versions, only the Bin directory was used. ASP.NET 2.0 introduces seven additional protected directories that may or may not exist in the application directory structure. None of these directories are automatically created by ASP.NET 2.0 or Visual Studio 2005, nor are the directories necessarily required to exist. Each directory needs to be created either manually by the application developer, or on-demand through Visual Studio 2005 when a feature that requires it is enabled. Internal estimates predict that only 1 - 3 additional directories will be present in an average ASP.NET application.
Post alpha and beta1 releases, we have received a lot of feedback regarding conflicts between ASP.NET special directories and identically named application directories used by our customers. To avoid these issues, ASP.NET 2.0 uses a special naming convention for special directories to minimize chances of collisions with customer folders. This syntax also improves our ability to introduce additional special directories in future releases and helps to conceptually separate and group the directories used by the framework.
The original syntax, announced in September, received strong feedback from the user community primarily due to two issues: long directory names, and change of the legacy Bin directory to the new name of application_assemblies. In these final changes to the syntax, our goal is to mitigate these problems and introduce a workable directory naming solution for the Beta 2 and RTM timeframe.
DESCRIPTION OF CHANGES
This change focuses on simplifying the special directory syntax, and retaining backwards compatibility with the applications and tools written for previous versions of ASP.NET. These changes to special directory names are as follows:
1. ASP.NET 2.0 will now use “app_” prefix for ASP.NET special directories
2. ASP.NET 2.0 will continue to use the bin directory for application assemblies
The total set of special directories in the framework thus becomes:
/Bin
(formerly Application_Assemblies) stays the same /Bin
/Code
(formerly Application_Code) becomes /app_code
/Resources
(formerly Application_GlobalResources) becomes /app_globalresources
/LocalResources
(formerly Application_LocalResources) becomes /app_localresources
/WebReferences
(formerly Application_WebReferences) becomes /app_webreferences
/Data
(formerly Application_Data) becomes /app_data
/Browsers
(formerly Application_Browsers) becomes /app_browsers
/Themes
(formerly Application_Themes) becomes /app_themes
The content in all of the above directories other then app_themes will not be accessible via http requests to the server. The request blocking will be carried out in the aspnet_filter.dll ISAPI filter installed with ASP.NET 2.0 Beta 2.
ALTERNATE SOLUTIONS CONSIDERED
In selecting this solution, we considered a number of other options including using a single root directory for framework content, making the directory naming configurable, and using various other syntax elements to distinguish the framework directories.
The single root approach was rejected because it did not enable us to support directories located in arbitrary locations in the application tree, such as the localresources directory.
The ISAPI filter used by ASP.NET to protect the content in special directories form being downloadable over http is not able to read configuration (otherwise the performance of all requests for ASP.NET and non-ASP.NET content will be significantly impacted), and is limited to a single instance per machine. Because of this limitation, introducing configurable syntax would require registry-based configuration, which breaks xcopy deployment of applications and presents an administrative problem, particularly in hosted scenarios.
In defining the naming syntax of the special directories, we found that file system supported characters other then the “_” such as “$, #, .,” had incompatibility conflicts with other internal or third party products. We feel that the current syntax is an acceptable compromise given the issues it was designed to solve, and presents the least risk of breaking existing tools and applications.
Questions should be addressed to this thread.
ASP.NET 2.0 Compilation Model Changes
SUMMARY
In response to significant customer feedback, the Web Platform and Tools team has made an important change to the compilation model for ASP.NET 2.0. This change is a breaking change between Beta1 and Beta2 and will require you to make small changes to any application built using ASP.NET 2.0 Beta 1, Visual Studio 2005 Beta 1 and/or Visual Web Developer 2005 Express Edition.
These changes affect the Page directives and class derivation models. The goal is to improve the code-behind and code-separation experience and enable the partial class paradigm to be used to improve the code-behind experience while continuing to maintain a syntax and functionality that is very similar to ASP.NET 1.x. As a result, it makes upgrading of v1.x projects even easier and further reduces new ASP.NET 2.0 specific concepts. Opening a v1.x project in Visual Studio 2005 or Visual Web Developer 2005 Express Edition will upgrade the project to ASP.NET 2.0.
In short, this change enables developers to continue to pre-compile ASP.NET pages for significant performance gains while still being able to maintain the .aspx markup content separate from the binary. This is the behavior developers have experienced today and is now available by default as a result of this change. You will also continue to optionally have the option to fully compile both the .aspx markup and code into binary during pre-compilation. The default option in ASP.NET 2.0 now maintains the .aspx markup separate from the code, which is compiled into a binary.
DETAILS
The new class-derivation model enables the page to define controls without the need to have protected members created in an inherited separation file, or have explicit event definition. This removes a level of brittleness that the previous code-behind model caused because the tool was required to keep the markup declarations and code-behind file in sync. With the new partial class based implementation, this tool based sync is no longer necessary, which makes it easier to separate the work on a .aspx markup file and a code-behind file. The base class can be defined in the code file and leverages partial classes for clean wire-up.
webform1.aspx: <%@ page codefile=”webform1.aspx.cs” inherits=”WebForm1” %>
webform1.aspx.cs: public partial class WebForm1 : System.Web.UI.Page {}
1. Page directives change
The codebehind, compilewith changes to codefile and the classname changes to inherits. The Whidbey ASP.NET Runtime still supports codebehind so v1.x web applications can be moved unchanged to Whidbey.
codebehind and compilewith changes to codefile
Classname changes to Inherits
2. Partial class change
The partial class in the code-behind file. The inherits class defines a base class. This change under the hood infers the same semantics for page directives (inherits) as in v1.x. The class is required to derive from Page or UserControl for user controls or MasterPage for master pages or child class of one of these classes.
3. Events
Change events to protected or public
VB Sample: Protected Sub Button1_Click(ByVal sender As Object, ByVal e As System.EventArgs)
C# Sample: protected void Button1_Click(object sender, EventArgs e)
UPGRADING FROM V1.X TO BETA2
Before
webform1.aspx: <%@ page codebehind="webform1.aspx.cs" inherits="WebForm1" %>
webform1.aspx.cs: public class WebForm1 : System.Web.UI.Page { }
After
webform1.aspx: <%@ page codefile=”webform1.aspx.cs” inherits=”WebForm1” %>
webform1.aspx.cs: public partial class WebForm1: System.Web.UI.Page {}
When codebehind is changed to codefile it is recommended that the application dll that was previously compiled by VS, (which includes all pages in the application under bin) should also be deleted.
MIGRATING FROM BETA 1 TO BETA 2
Before
webform1.aspx: <%@ page compilewith="webform1.aspx.cs" classname="WebForm1” %>
webform1.aspx.cs: public partial class Webform1 { } // note there is no parent class
After
webform1.aspx: <%@ page codefile=”webform1.aspx.cs” inherits=”WebForm1” %>
webform1.aspx.cs: public partial class WebForm1 : System.Web.UI.Page {}
VB Sample: Partial Class default_aspx Inherits System.Web.UI.Page
You will also be able to continue to inherit from any base class to build pages, master pages or custom controls. For .ascx files use System.Web.UI.UserControl as the parent class. For .master use System.Web.UI.MasterPage. Only pages using “code behind/separation” are affected. All pages using “single page” mode do not need any change. It is recommended that the application dll that was previously compiled by VS (which includes all pages in the application under bin) should be deleted.
The classname to inherits change is required, note that classname is still a valid Page directive which can be used to define the page class name as in v1.x. The code-separation model creates 2 classes, even though the code-separation file is defined as a partial class. This model allows the v1.x compilation scenario for a code-separation file assembly and a dynamically compiled page-gen class. Page and code-behind are no longer in same class, hence code that cross references each other between page and code file might be broken e.g. a page can’t have databinding syntax using private property/method in code file any more; code file can’t use private class defined in page script block any more, etc.
文章来源:http://blog.aspcool.com/polaris/archive/2005/01/28/1791.html
Any questions should be addressed to this thread...
An easier on the eyes version of this announcement can be found at:
http://msdn.microsoft.com/asp.net/whidbey/beta2update.aspx
ASP.NET 2.0 Directory Naming Changes
SUMMARY
Last month, The Web Platform and Tools team announced a change in the special directory naming of ASP.NET 2.0. In discussing this change with customers and community, we received a strong response that prompted us to reconsider the proposed syntax of application_xxx. After reviewing the feedback, re-thinking our goals, and looking at all possible options and feedback, we have decided to revise the changes in order to create a simpler and more usable syntax while also improving compatibility with existing ASP.NET 1.x applications.
BACKGROUND
ASP.NET uses a number of special directories in an application root in order to maintain application contents and data. In previous versions, only the Bin directory was used. ASP.NET 2.0 introduces seven additional protected directories that may or may not exist in the application directory structure. None of these directories are automatically created by ASP.NET 2.0 or Visual Studio 2005, nor are the directories necessarily required to exist. Each directory needs to be created either manually by the application developer, or on-demand through Visual Studio 2005 when a feature that requires it is enabled. Internal estimates predict that only 1 - 3 additional directories will be present in an average ASP.NET application.
Post alpha and beta1 releases, we have received a lot of feedback regarding conflicts between ASP.NET special directories and identically named application directories used by our customers. To avoid these issues, ASP.NET 2.0 uses a special naming convention for special directories to minimize chances of collisions with customer folders. This syntax also improves our ability to introduce additional special directories in future releases and helps to conceptually separate and group the directories used by the framework.
The original syntax, announced in September, received strong feedback from the user community primarily due to two issues: long directory names, and change of the legacy Bin directory to the new name of application_assemblies. In these final changes to the syntax, our goal is to mitigate these problems and introduce a workable directory naming solution for the Beta 2 and RTM timeframe.
DESCRIPTION OF CHANGES
This change focuses on simplifying the special directory syntax, and retaining backwards compatibility with the applications and tools written for previous versions of ASP.NET. These changes to special directory names are as follows:
1. ASP.NET 2.0 will now use “app_” prefix for ASP.NET special directories
2. ASP.NET 2.0 will continue to use the bin directory for application assemblies
The total set of special directories in the framework thus becomes:
/Bin
(formerly Application_Assemblies) stays the same /Bin
/Code
(formerly Application_Code) becomes /app_code
/Resources
(formerly Application_GlobalResources) becomes /app_globalresources
/LocalResources
(formerly Application_LocalResources) becomes /app_localresources
/WebReferences
(formerly Application_WebReferences) becomes /app_webreferences
/Data
(formerly Application_Data) becomes /app_data
/Browsers
(formerly Application_Browsers) becomes /app_browsers
/Themes
(formerly Application_Themes) becomes /app_themes
The content in all of the above directories other then app_themes will not be accessible via http requests to the server. The request blocking will be carried out in the aspnet_filter.dll ISAPI filter installed with ASP.NET 2.0 Beta 2.
ALTERNATE SOLUTIONS CONSIDERED
In selecting this solution, we considered a number of other options including using a single root directory for framework content, making the directory naming configurable, and using various other syntax elements to distinguish the framework directories.
The single root approach was rejected because it did not enable us to support directories located in arbitrary locations in the application tree, such as the localresources directory.
The ISAPI filter used by ASP.NET to protect the content in special directories form being downloadable over http is not able to read configuration (otherwise the performance of all requests for ASP.NET and non-ASP.NET content will be significantly impacted), and is limited to a single instance per machine. Because of this limitation, introducing configurable syntax would require registry-based configuration, which breaks xcopy deployment of applications and presents an administrative problem, particularly in hosted scenarios.
In defining the naming syntax of the special directories, we found that file system supported characters other then the “_” such as “$, #, .,” had incompatibility conflicts with other internal or third party products. We feel that the current syntax is an acceptable compromise given the issues it was designed to solve, and presents the least risk of breaking existing tools and applications.
Questions should be addressed to this thread.
ASP.NET 2.0 Compilation Model Changes
SUMMARY
In response to significant customer feedback, the Web Platform and Tools team has made an important change to the compilation model for ASP.NET 2.0. This change is a breaking change between Beta1 and Beta2 and will require you to make small changes to any application built using ASP.NET 2.0 Beta 1, Visual Studio 2005 Beta 1 and/or Visual Web Developer 2005 Express Edition.
These changes affect the Page directives and class derivation models. The goal is to improve the code-behind and code-separation experience and enable the partial class paradigm to be used to improve the code-behind experience while continuing to maintain a syntax and functionality that is very similar to ASP.NET 1.x. As a result, it makes upgrading of v1.x projects even easier and further reduces new ASP.NET 2.0 specific concepts. Opening a v1.x project in Visual Studio 2005 or Visual Web Developer 2005 Express Edition will upgrade the project to ASP.NET 2.0.
In short, this change enables developers to continue to pre-compile ASP.NET pages for significant performance gains while still being able to maintain the .aspx markup content separate from the binary. This is the behavior developers have experienced today and is now available by default as a result of this change. You will also continue to optionally have the option to fully compile both the .aspx markup and code into binary during pre-compilation. The default option in ASP.NET 2.0 now maintains the .aspx markup separate from the code, which is compiled into a binary.
DETAILS
The new class-derivation model enables the page to define controls without the need to have protected members created in an inherited separation file, or have explicit event definition. This removes a level of brittleness that the previous code-behind model caused because the tool was required to keep the markup declarations and code-behind file in sync. With the new partial class based implementation, this tool based sync is no longer necessary, which makes it easier to separate the work on a .aspx markup file and a code-behind file. The base class can be defined in the code file and leverages partial classes for clean wire-up.
webform1.aspx: <%@ page codefile=”webform1.aspx.cs” inherits=”WebForm1” %>
webform1.aspx.cs: public partial class WebForm1 : System.Web.UI.Page {}
1. Page directives change
The codebehind, compilewith changes to codefile and the classname changes to inherits. The Whidbey ASP.NET Runtime still supports codebehind so v1.x web applications can be moved unchanged to Whidbey.
codebehind and compilewith changes to codefile
Classname changes to Inherits
2. Partial class change
The partial class in the code-behind file. The inherits class defines a base class. This change under the hood infers the same semantics for page directives (inherits) as in v1.x. The class is required to derive from Page or UserControl for user controls or MasterPage for master pages or child class of one of these classes.
3. Events
Change events to protected or public
VB Sample: Protected Sub Button1_Click(ByVal sender As Object, ByVal e As System.EventArgs)
C# Sample: protected void Button1_Click(object sender, EventArgs e)
UPGRADING FROM V1.X TO BETA2
Before
webform1.aspx: <%@ page codebehind="webform1.aspx.cs" inherits="WebForm1" %>
webform1.aspx.cs: public class WebForm1 : System.Web.UI.Page { }
After
webform1.aspx: <%@ page codefile=”webform1.aspx.cs” inherits=”WebForm1” %>
webform1.aspx.cs: public partial class WebForm1: System.Web.UI.Page {}
When codebehind is changed to codefile it is recommended that the application dll that was previously compiled by VS, (which includes all pages in the application under bin) should also be deleted.
MIGRATING FROM BETA 1 TO BETA 2
Before
webform1.aspx: <%@ page compilewith="webform1.aspx.cs" classname="WebForm1” %>
webform1.aspx.cs: public partial class Webform1 { } // note there is no parent class
After
webform1.aspx: <%@ page codefile=”webform1.aspx.cs” inherits=”WebForm1” %>
webform1.aspx.cs: public partial class WebForm1 : System.Web.UI.Page {}
VB Sample: Partial Class default_aspx Inherits System.Web.UI.Page
You will also be able to continue to inherit from any base class to build pages, master pages or custom controls. For .ascx files use System.Web.UI.UserControl as the parent class. For .master use System.Web.UI.MasterPage. Only pages using “code behind/separation” are affected. All pages using “single page” mode do not need any change. It is recommended that the application dll that was previously compiled by VS (which includes all pages in the application under bin) should be deleted.
The classname to inherits change is required, note that classname is still a valid Page directive which can be used to define the page class name as in v1.x. The code-separation model creates 2 classes, even though the code-separation file is defined as a partial class. This model allows the v1.x compilation scenario for a code-separation file assembly and a dynamically compiled page-gen class. Page and code-behind are no longer in same class, hence code that cross references each other between page and code file might be broken e.g. a page can’t have databinding syntax using private property/method in code file any more; code file can’t use private class defined in page script block any more, etc.
文章来源:http://blog.aspcool.com/polaris/archive/2005/01/28/1791.html
