ASP.NET Run-Time Breaking Changes

<system.web> <httpHandlers> <add verb="*" path="*.misc" type="System.Web.UI.PageHandlerFactory" /> </httpHandlers> </system.web>

<compilation> <buildProviders> <add extension=".misc" appliesTo="Web" type="System.Web.Compilation.PageBuildProvider" /> </buildProviders> </compilation> 

There are limited scenarios for this API, which was essentially exposing implementation in the tool. It would enable a developer to get to an HTML DOM for the actual control's rendering in the design surface.

The API is marked for obsoletion, but it also will return null in all cases now. Developers should be checking for null.

Currently there are no known control vendors making use of this API, we have been extensively researching baszed on feedback through devlabs and evangelist contacts. The API was poorly documented in v1 and states that it is an infrastricutre support API not intended to be called by user code.

There are a number of important high-level folders that have been introduced in v2.0 that have special semantics and meaning in an ASP.NET application. Resources. Any RESX or RESOURCES files that are added to this directory are automatically compiled to .resources and embedded into an assembly for these resources. The assembly creation also ensures that satellite assemblies are created for Resourcemanager lookup. Code: Any CS, VB, J#, WSDL, RESX, XSD etc. files are automatically compiled into a top-level assembly for reference throughout the application. Data: Houses the mdb used for all providers shipped in asp.net, e.g. Profile, Roles, Personalization, Membership. Themes: Named theme folders and .skin files are located under the Themes folder. ASP.NET automatically looks for Themes under the specialized folder name. The purpose of these folders and the support they offer are:

• No compile step. The developer is not required to pre-compile these file types to assemblies that are then placed in \Bin. Therefore there is a high degree of productivity. The Visual Designer also provides instant intellisense support for these types for example, without a compile step.
• Non-browsable folders. certain folders are marked as non-browseable for security purposes.
• Simply named so that they are obvious in their intention. There is no specialized ASP.NET naming convention added to the folder syntax.

There are limited scenarios for this API, which was essentially exposing implementation in the tool. It would enable a developer to get to an HTML DOM for the actual control's rendering in the design surface.

The API is marked for obsoletion, but it also will return null in all cases now. Developers should be checking for null.

#1: Replace the this.document.<formname> with this.document["formname"] (goes off the ID. This is true for all browsers.)

#2: Use the backwards compat (enableObsleteRendering=true) in the xHtmlConformance section, which will revert to v1.1 behavior.

v1.x used client-side static script files for things like client-sifde validations scripts etc.

v2 uses embedded resources served via a handler. In v2 if a developer removes all handlers, then scenarios requiring the script will be broken. Developers need to add the handler back.

Developers will need to add the handler back into the configuration section, if they also remove all handlers previously. We do not want to add the handler back in automatically as this breaks the semantics of the control.

FormsAuthentication will no longer automatically set the expiration of the persistent auth ticket to 50 years, but use the configured timeout instead.

Forms Authentication is capable of generating 2 types of cookie based tickets: persistent (saved as cookie with expiration), and non-persistent (session cookie, dissapear when browser is closed). It supports a configured timeout for the expiration of the cookie/ticket, which reduces the window for stealing/replaying the auth ticket.

However, historically when persistent cookies were generated, the feature would hardcode a 50 year expiration timeout regardless of the timeout configured. Originally this was done to support a kind of "remember me" feature. This is, needless to say, extreme, and has 3 major problems:

• false feeling of security because of not honoring the timeout defined in the config
• inability to log users out when their accounts expire
• very large window during which the ticket can be stolen and replayed

The change is to honor the configured timeout for both persistent and non-persistent cookies, decoupling the persistant aspect from the timeout. The user can set the timeout to a larger value to support remember me functionality explicitly, or programatically generate the cookie in any way they want (see below).

To set the ticket expiration to a longer time, you can

1) Set the <forms timeout=<DESIRED TIMEOUT>">

OR

2) create and set the ticket yourself with the following 3 line code:

FormsAuthenticationTicket ticket = new FormsAuthenticationTicket(username, longer expiration date, etc); String cookie = FormsAuthentication.Encrypt(ticket); Response.Cookies.Add(new HttpCookie(FormsAuthentication.FormsCookieName, cookie));

The developer of a mobile application in v1.x would potentially utilize new adapters that were shipped out-of-band as part of the device update procedures from Microsoft (DU2, DU4). DU2 introduced a new assembly and namsepace for xHtmlAdapters. In version 2.0, the assembly is removed, but the namespace is moved to System.Web.Mobile.dll

Developers who have extended types from the adapter assembly in du2 or du4, will be required to make changes to their applications to support these types.

In v1.x, developers could have installed the following:

DU2: S.W.U.MC.A.dll with config additions
DU4: S.W.U.MC.A.dll with config additions and policy to redirect DU2 to DU4.

The adapters assembly contained Alternate adapters for exisiting framework adapters, plus a new xHTmlAdapter suite.

Extend v1.x (DU2/DU4) adapters. Documentation did not exist for these adapters, no source was shipped either. Developer will be required to:

• Recompile their assembly to link to the new version 2.0 assembly
• Modify config to map their assembly and types

Scenario: Extend v1.x adapters. Documentation did exist, source was shipped. Developer will be required to:

• Do nothing. Version 2.0 will have policy redirect for v1.x adapter assembly to v2

Scenario: No extended types: developer is required to:

• Do nothing Version 2.0 has all the mobile controls mapped to new assemblies for ALL adapters, the alternates, the xHtml adapters.

Users who included trailing spaces in URLs and relied on the fact that:

a) the framework was not encoding the spaces b) IE would trim the trailing space

The lack of correct encoding of contained spaces did not work for c-html browsers, so the encoding rules were updated for the src attribute. A user that included an extraneous trailing space in the path will now get a 404 file not found error when the URL is requested.

Where a user creates a site with a structure that in its simplest form is~/test.aspx // Uses the UC "sub/test.ascx" ~/sub/test.ascx // Simple user control with nothing special ~/sub/test.aspx // Simple page which doesn't do anything specialThen given ASP batching, "~/sub/test.ascx" and "~/sub/test.aspx" get compiled in the same assembly. When "~/test.aspx" is compiled there is a reference to the "sub" batched assembly.

~/test.aspx and ~/sub/test.aspx produce the same class name (normally ASP.test_aspx), which leads to an ambiguity.

Note that this worked in previous versions because the generated namespace was either "ASP" or "_ASP". But this was causing user confusion.

1. Turn off batching in web.config. This requires no code change and completely fixes the issue.
2. Don't use files with the same name, or use a classname attribute to make the class different.
3. Change the layout of the files. In this case, if the user control was moved to a ~/usercontrols directory, the issue would not exist.

typeof(SomeTypeInThatAssembly).Assembly.

In V2.0 attributes cannot to be specified inside a section group. The check did not exist in V1.1.

To avoid breaking existing V1.1 code, unrecognized attributes are allowed. However, an exception is thrown if any attribute starting with a prefix "config" or "lock" is specified. These two prefixes are reserved for future extensibility. So if user custom attributes start with one of these reserved prefixes, they would need to be changed.

IE and Mozilla treat the backslash as a forward slash for URL paths. The user who has hard-coded a dependency on a backslash coming through a call to this API will be broken. It is unknown why a user would be using a backslash in URL paths.

If you are looking for a '\' in the value returned from HttpContext.RewritePath, it has now been replaced with a '/'.

<configuration> <system.web> <pages enableEventValidation="true" /> </system.web> </configuration>

Developers making assumptions on the auto-generated classnames may be broken when migrating to v2.0.

There are benefits to keeping all lower case:

• Consistency
• Different machines, or file systems may genberate inconsistent classnames for given apps (copy may not retain casing)
• The v2.0 VirtualPathProvider cannot make a guaranteed assumption that the virtualPath handed to it is of the correct casing to make classname assumptions.
• Users should revert to using the classname attribute to generate their own fixed classname

<%@ Register tagPrefix="foo" Namespace="XSLTComponent" Assembly="Control" %><div id="rootid" attrA="A" attrB="B">AB<foo:control runat="server" cname="foo:control" ></foo:control></div>

In v2.0 we added a performance optimization to eliminate reading the sessionID out of the request in a few cases:

1. it must be mode=InProc, cookieless=false
2. session state is disabled
3. session state is enabled, then we delay reading the cookie until session is actually used.

So this introduced the subtle breaking change where we don't always have the sessionID cookie in the request headers.

In V1.1 the call Page.RegisterRequiresPostBack(Control control) would not throw an exception if the control was not IPostBackDataHandler, which was indeed expected, and the control's info was simply added to ViewState. But in subsequent postback, the control info in ViewState would be checked for IPostBackDataHandler and an exception would be thrown.

In V2.0 the checking of IPostBackDataHandler was added in RegisterRequiresPostBack()

The work around for display:none would be to modify the markup for design-time explicitly.

Version 2.0 now delegates static file processing back to the IIS6 static file handler via the ChildExecute mechanism. This enables very useful scenarios such as running ASP.NET authentication/authorization modules for all requests, while continuing to serve static, asp, php etc, requests from IIS.

The side effect is that any explicit script mapping that maps an extension to ASP.NET has to have a corresponding mapping inside ASP.NET in order to be processed in ASP.NET, otherwise the request to it will be passed back to IIS resulting in an infinite loop/empty response. Static files by default get mapped to the default http handler since no explicit mapping for them exists in ASP.NET, and therefore participate in this loop.

This is typically cleaner then automatically figuring out that asp.net should statically serve these extensions when a loop results:

On IIS6.0 + V2.0: the new model always passes unmapped requsts back to IIS. In *-mapped mode, this results in IIS serving the content, and in specific mode we have a loop resulting in empty responses, signifying to the customer that a config change is required.

On IIS5.1 OR IIS6.0 + V1.1: the old model is to always serve from ASP.NET, in *-mapped mode and in specific mode

typeof(SomeTypeInThatAssembly).Assembly

User who had fields in their code that differed only in casing now get compilation errors.

In v1, the CLR would arbitrarily match the first instance of the field it encountered when the name differed only by case. In version 2.0, it is now treated as an ambiguity.

Users who included trailing spaces in URLs relied on the fact that:

a) we were not encoding the spaces
b) IE would trim the trailing spaces

The lack of correct encoding of contained spaces did not work for c-html browsers, so the encoding rules were updated for the src attribute. A user that included an extraneous trailing space in the path will now get a 404 file not found error when the URL is requested.

To set the ticket expiration to a longer time, you can

1) Set the <forms timeout=<DESIRED TIMEOUT>">

OR

2) create and set the ticket yourself with the following 3 line code:

FormsAuthenticationTicket ticket = new FormsAuthenticationTicket(username, longer expiration date, etc); String cookie = FormsAuthentication.Encrypt(ticket); Response.Cookies.Add(new HttpCookie(FormsAuthentication.FormsCookieName, cookie));

When SelectedDatesCollection.SelectRange(DateTime fromDate, DateTime toDate) was called to set a range of dates to the collection, it used to only set the date part of input parameters fromDate and toDate for the selected dates.

There has been a change that the complete DateTime content is stored instead. Hence, when DateTime.Today.Now was set to SelectedDates collection (via SelectedDate property), the specific time info is included. Later in rendering, it compares to the current date that has zeroes in Hour, Minute and Second, and the comparison is false and therefore the selected date is not recognized.