Skip to main content

ASP.NET Run-Time Breaking Changes

 
Short DescriptionRemoved Bindable attribute from web controls
Affected APIsNASeverityLowCompat Switch AvailableNo

DescriptionWeb controls can decorate a property with the Bindable metadata attribute to indicate that the property should be displayed in a design-time databindings picker; such as the databindings dialog in Visual Studio .NET. In v1.x; many ASP.NET Web Control properties were displayed in this dialog that were not used in common databinding scenarios. In v2.0; these properties are no longer decorated with the Bindable attribute; and no longer appear in the Databindings design-time dialog. This affects design-time scenarios only. All properties; whether marked Bindable or not; are bindable at run time.

User ScenarioIt is highly unlikely that user code will ever use these values directly—they will consume SystemColors.ButtonFace or SystemPens.ButtonFace. Beyond color translation at design time there are literally one or two places where this class is referenced across the whole of Windows Forms—we use SystemColors and SystemPens. KnownColors is an artifact of the way we create the System* set of static classes. It is also used for design time serialization support. Except for the Color API to translate to and from KnownColors there are no APIs that take KnownColor.

Work AroundNone
 

 

 
Short DescriptionAdRotator respects height/width values in the advertisement schema whereas v1 AdRotator did not.
Affected APIsRendering changeSeverityLowCompat Switch AvailableNo

DescriptionThe AdRotator points to an XML-format data file for advertisements, e.g. "<Ad><ImageUrl>ad.gif</ImageUrl></Ad>". The schema of this file may be extended by the user to include custom properties, "<Ad><Foo>custom</Foo></Ad>". These custom properties are exposed in a dictionary passed to the AdCreated event args, e.g. args.AdProperties["Foo"]. We extended the default schema of the file to include <Height> and <Width> properties, for sizing an advertisement banner image. Because we did not support this behavior in v1, the user may have been supporting a similar feature through custom properties, altering the ad rendering manually in the AdCreated event. The potential for breaking change exists if the user code interpretation of <Height> and <Width> are somehow different from the AdRotator v2s default behavior (to size the ad image). We believe the chance of this is very unlikely.

User ScenarioDoes not affect existing user code; only rendering

Work AroundCan customize/undo the AdRotator's default rendering in the AdCreated event.
 

 

 
Short DescriptionValid values required for COM security attributes
Affected APIsnone (config only) SeverityLowCompat Switch AvailableNo

DescriptionInvalid values for the COM security attributes were silently accepted in the <processModel> section prior to 2.0(the default values were used instead). This is not a great behavior because it allows someone to typo a value and think they've changed the COM security context when they haven't; which could result in lower than expected security. This change throws when values are misconfigured. Since <processModel> can only exist in machine.config; this is version specific and would require manual copying to 2.0(it's rarely changed at all; though).

User ScenarioIf a user had misconfigured invalid values in this section prior to 2.0, it would silently fall back to the default values. In 2.0, it throws an exception when invalid values are presented. This section can exist only in machine.config (which is version specific) so it would require someone to copy incorrect config from a previous version into 2.0.

Work AroundConfigure a correct value or use defaults
 

 

 
Short DescriptionThrow an exception when process identity does not have read access to the metabase.
Affected APIsN/ASeverityLowCompat Switch AvailableNo

DescriptionASP.NET requires read access to the metabase in order to execute the request. If a custom identity does not have required access, we will throw this exception during request processing.

User ScenarioUser configures a custom account for process identity, which does not have read access to the metabase.

Work AroundUse aspnet_regiis -ga to grant required metabase access/ACLs to the desired account.
 

 

 
Short Description When mapping custom extensions to an existing ASP.NET builtin handler, it is now necessary to configure a build provider for that extension.
Affected APIsConfigurationSeverityLowCompat Switch AvailableNo

DescriptionWhen mapping custom extensions to an existing ASP.NET builtin handler, it is now necessary to configure a build provider for that extension. In version 2.0, the ASP.NET build system requires a build provider to handle compilation. The builtin build providers can be reused but they need to be specified.

User ScenarioIf an application maps a private file extensions (say .misc or .foo or whatever) to an existing ASP.NET handler type (say, the page handler), then it is now necessary to provide configuration that tells ASP.NET how to compile that file type. e.g.
<system.web> <httpHandlers> <add verb="*" path="*.misc" type="System.Web.UI.PageHandlerFactory" /> </httpHandlers> </system.web>
In v1, this would work as is. In version 2.0, they also need to register a BuildProvider. e.g.
<compilation> <buildProviders> <add extension=".misc" appliesTo="Web" type="System.Web.Compilation.PageBuildProvider" /> </buildProviders> </compilation> 
Types mapped to the static file handler or star mapped types are not impacted by this, only compiled types.

Work AroundAdd a configuration directive to tell ASP.NET how to compile that file type.
 

 

 
Short DescriptionMove WebFormDesigner class to new assembly and make internal.
Affected APIsMicrosoft.VSDesigner.WebForms.WebFormDesigner::(all)SeverityLowCompat Switch AvailableNo

DescriptionIn VS 2005 the WebFormDesigner class has been removed.

User ScenarioSomeone found the undocumented public class in microsoft.vsdesigner.dll and used it. It is possible that someone derived from WebFormDesigner to create a customized designer using the undocumented methods we made available to the mobile web form designer.

Work AroundNone
 

 

 
Short DescriptionThe V1 model of using view links is no longer used in version 2.0. It is therefore not even possible to recreate the potential object that was previously available. There are currently no known Control vendors making use of this API. It was poorly documented in v1.x.
Affected APIsSystem.Web.UI.Design.ControlDesigner.DesignTimeElementViewSeverityLowCompat Switch AvailableNo

Description

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.


User ScenarioIf a control designer author made use of the view link, they could get access to an object that represents the design-surface visual representation of the control.

Work AroundThere is no workaround
 

 

 
Short Description a relic config attribute from V1.0 beta releases has been removed from 2.0 as part of the new object model for config APIs
Affected APIs configuration system, no programmatic APIsSeverityLowCompat Switch AvailableNo

DescriptionAn obsolete undocumented configuration attribute is being removed from the section. Because the attribute was never documented, tested, or fully implented, we don't believe this will impact anyone.

User ScenarioThis configuration attribute has never been documented or described and was not fully implemented. However, it was accepted by the configuration system. If someone had reverse engineered the code and discovered that it existed and configured it, that app would now throw.

Work Aroundremove the attribute from config
 

 

 
Short DescriptionIgnore "remove" and "clear" directives in
Affected APIsConfigurationSettings.GetConfig, HttpContext.GetConfigSeverityLowCompat Switch AvailableNo

DescriptionThis change only affects web.config and application.config files that remove a section handler declared in a parent configuration file.

User ScenarioThis change will cause web applications that replace a named configuration section handler with another handler to get a ConfigurationException when attempting to access the section.The original intent of the <remove> and <clear> directives was to allow a web.config file to declare a name for a new section handler, overriding a declaration in machine.config that may conflict with it. This would work if no component in the application required the configuration information provided by the previous user of that name. It could be useful if I deployed an application with a custom configuration section, and then another application modified machine.config and declared a different configuration section handler for the same name. I could fix my app by issuing a <remove> directive for that name in web.config, and then redeclare the handler.Unfortunately, this feature has unfortunate side-effects: * Components that require the configuration information provided by the old handler may get a type of configuration object that they don't expect, leading to an exception when accessing the object. There may be security issues if an exception occurs where not anticipated. For example, we have not examined what would happen if an exception occurred when accessing the configuration information in "system.web/trust" if the type of the information was not as expected. * If the type of the return configuration object is a public type, then a redeclared handler could subvert security restrictions in a parent handler. For example, suppose the type of the configuration information for "system.web/sessionState" was public (it is not). The handler enforces a "lockAttributes" collection, which optionally prevents child config files from overriding certain attributes, such as connection strings. If the handler was replaced, it could prevent the implementation of lockAttributes.* There are bugs in the current implementation of configuration that do not respect when the configuration handler for a name has changed. For example, IConfigurationSection.Create will pass the result of a parent section, even if the type of the handler is different

Work AroundThe workaround is to choose a different unique name for the handler, so that removing a previous handler isn't necessary.
 

 

 
Short DescriptionThe build provider mechanism requires a file name extension. Therefore it makes sense that an exception be thrown on no file extension files. In v1 this was possible and the page was assumed as an ASPX. There potentially could be a security issue here for unsuspecting users receving unknown file types.
Affected APIsN/ASeverityLowCompat Switch AvailableNo

DescriptionThe build provider mechanism requires a file name extension. Therefore it makes sense that an exception be thrown on no file extension files. In v1 this was possible and the page was assumed as an ASPX. There potentially could be a security issue here for unsuspecting users receving unknown file types.

User ScenarioFiles with no extension are no longer compiled and assumed to be ASPX

Work AroundAdd an extension to the file and an entry in the build providers for the same
 

 

 
Short DescriptionNo cache control HTTP headers for static requests through ASP.Net
Affected APIsNoneSeverityLowCompat Switch AvailableNo

Description Requests to ASP.Net that mapped to static content are now executed via EXEC_URL, which may cause cache control HTTP headers to not be in the response. The browser's caching of content is typically not affected by this change.

User ScenarioIf user mapped static files to ASP.Net or did a Context.RewritePath to redirect the request to a static file, in version 2.0 the response would be missing the cache control HTTP headers. This occurs because in version 2.0, if possible, we do an EXEC_URL on the request, letting IIS's static handler take care of it rather than the one written by us. Note that this typically doesn't affect the client's (i.e. IE's) ability to cache the data locally, since their heuristics for static file caching are not affected by this change. Users should typically see no functional change.

Work AroundNone
 

 

 
Short DescriptionSome directories have special meaning in a web application in version 2.0
Affected APIsNoneSeverityLowCompat Switch AvailableNo

Description

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.

User ScenarioIf developers migrate a v1.x application that already contain these named folders, then significant issues may arise: through naming conventions, newly compiled types and potential double type references, Folders no longer being browseable, if the folder was merely an application's subfolder with no special meaning

Work AroundFolders in a v1.x application that have these names from the app-root should be renamed to avoid any conflict.
 

 

 
Short DescriptionProcessModel shutDownTimeout previously accepted bogus values. Now it expects correctly formed values.
Affected APIsProcessModelSection.ShutDownTimeoutSeverityLowCompat Switch AvailableNo

DescriptionProcessModel shutDownTimeout previously accepted bogus values. Now it expects correctly formed values. The field previously would accept values like shutDownTimeout="99:999:9999" which really have no meaning. Now the configuration system reports this as an error.

User Scenario If the user has bogus data in this field, it will now generate an error stating the information is bad.

Work AroundSpecify a valid value in HH:MM:SS format
 

 

 
Short DescriptionAdded default behavior to encode \n in response headers and configuration option to disable it.
Affected APIsAll APIs that allow arbitrary strings to be inserted in response headers.SeverityLowCompat Switch AvailableNo

DescriptionA number of attacks have recently been published that take advantage of response splitting by injecting the CR-LF pair into the headers. A mitigation is to automatically encode the \n character when found in header body. This behavior will be enabled by default (the breaking change) and can be turned off via the new configuration setting.

User ScenarioAny scenario which involves writing values containing new line character into reponse headers and the client/intermediate server expects the newline to be present. This is not a common scenario.

Work AroundSet <httpRuntime EnableHeaderChecking=false ... /> for the application
 

 

 
Short DescriptionWhen a developer or admin uses the <remove assembly="*"/> in previous versions this acted like a clear all, rather than the removal of the * assembly (Bin assemblies). This leads to inconsistency in the new design as <add assembly="*"/> is unbalanced, especially in the new configuration APIs.
Affected APIsConfiguration APIs are new to version 2.0,SeverityLowCompat Switch AvailableNo

DescriptionWhen a developer or admin uses the <remove assembly="*"/> in previous versions this acted like a clear all, rather than the removal of the * assembly (Bin assemblies). This leads to inconsistency in the new design as <add assembly="*"/> is unbalanced, especially in the new configuration APIs.

User ScenarioSee description

Work Arounduse
 

 

 
Short Description AdRotator respects height/width values in the advertisement schema whereas v1 AdRotator did not.
Affected APIsRendering changeSeverityLowCompat Switch AvailableNo

DescriptionThe AdRotator points to an XML-format data file for advertisements, e.g. "<Ad><ImageUrl>ad.gif</ImageUrl></Ad>". The schema of this file may be extended by the user to include custom properties, "<Ad><Foo>custom</Foo></Ad>". These custom properties are exposed in a dictionary passed to the AdCreated event args, e.g. args.AdProperties["Foo"]. We extended the default schema of the file to include <Height> and <Width> properties, for sizing an advertisement banner image. Because we did not support this behavior in v1, the user may have been supporting a similar feature through custom properties, altering the Ad rendering manually in the AdCreated event. The potential for breaking change exists if the user code interpretation of <Height> and <Width> are somehow different from the AdRotator v2s default behavior (to size the ad image). We believe the chance of this is very unlikely.

User ScenarioDoes not affect existing user code; only rendering.

Work AroundCan customize/undo the AdRotator's default rendering in the AdCreated event.
 

 

 
Short DescriptionThe V1 model of using view links is no longer used in 2.0.
Affected APIsSystem.Web.UI.Design.ControlDesigner.DesignTimeElementViewSeverityLowCompat Switch AvailableNo

Description

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.


User ScenarioIf a control designer author made use of the view link, they could get access to an object that represents the design-surface visual representation of the control.

Work AroundNone
 

 

 
Short DescriptionWhen very long paths are passed to Server.MapPath, they now fail with an InvalidOperationException instead of a PathTooLongException.
Affected APIsSystem.Web.HttpServerUtility.MapPathSeverityLowCompat Switch AvailableNo

DescriptionAn application that was passing an invalid long path to MapPath in version 1.1 would get a PathTooLongException bubbled up from the BCL. In version 2.0, there is a native code implementation for WebHost that fails the invalid path. The HostingEnvironment then throws an InvalidOperationException, which results in a 500

User ScenarioAn application that was passing an invalid long path to MapPath in version 1.1 would get a PathTooLongException bubbled up from the BCL. If the exception was unhandled, the response status code would be 414. In version 2.0, there is a different exception and the status code is 500.

Work AroundIn either release, it's an error condition and any global exception handling mechanisms will be treated identically.
 

 

 
Short DescriptionRequesting page from application where a 'location' path is used to incorrectly define the auth mode for a subdirectory results in config error. The entire web.config file is validated on first request to app.
Affected APIsnoneSeverityLowCompat Switch AvailableNo

Descriptionweb.config file at the app level that has invalid config inside <location> tags pointing to child vdirs, will fail validation at the app level. In v1.1 requests to the app succeeded and only requests to the child vdir failed.

User Scenario web.config at the app level with <location> tags for child vdirs is now completely validated when requesting the app.

Work Aroundnone
 

 

 
Short Description Expired URI-based session ids will not be reused for new sessions. Turn session id regeneration on by default.
Affected APIsnoneSeverityLowCompat Switch AvailableNo

DescriptionSee above/below

User Scenario When a user clicks a URL, or a bookmark, containing a session id whose session has previously expired, his new session will not reuse the same id. This is only important when the application somehow tracks users by session ids, and relies on the fact that the same user will reuse the same link later. This is a flawed scenario in the first place, because the user is not guaranteed to reuse that link, and the cookie is a session cookie and never gets reused anyway after the browser is closed.

Work Around Turn off session regeneration in the <sessionstate> configuration to revert to old behavior.
 

 

 
Short DescriptionFormsAuthModule accepts valid tickets in the query string only when enableCrossAppRedirects="true"(which is not the default setting
Affected APIsNoneSeverityLowCompat Switch AvailableNo

DescriptionBecause of the various problems of putting the ticket in the querystring, we changed to the standard app-modifier based mechanism for URL-based auth tickets (as used by all other ASP.NET 2.0 features). However, for a particular scenario where the login page is in another application AND cookieless mode os used, we support reading the ticket from the querystring (and therefore support this scenario). This is also a security decision, due to the injection problems with URL-based session ids.

User ScenarioWhen using MobileFormsAuthentication in v1.1, users may have put the forms authentication ticket in the querystring and MobileFormsAuthentication would have automatically picked up the ticket from the querystring. In order to support the querystring tickets, cookieless mode must be configured (by default its on only for mobile devices that dont support cookies based on browser caps) AND enableCrossAppRedirects must be set to true.

Work AroundSet enableCrossAppRedirects to true.
 

 

 
Short DescriptionFormsAuthentication cookie not available to client side script to prevent XSS
Affected APIsNoneSeverityLowCompat Switch AvailableNo

DescriptionThe HttpOnly bit of the FormsAuthentication cookie will be set automatically, so that compliant browsers will not make the cookie available to client side scripting.

User ScenarioIf a user had a client side script that manipulated the forms authentication cookie, it will no longer have access to the cookie. We are not aware of any customers that do this&;$151;it is mostly done only by cross-site scripting exploits against which this change is made.

Work AroundWrite a custom module that copies the forms authentication cookie into another cookie, and clears the HttpOnly bit so it can be manipulated by client script.
 

 

 
Short DescriptionSet HttpOnly property of session state cookie to true. Session id cookie not available to client side script to prevent XSS.
Affected APIsemptySeverityLowCompat Switch AvailableNo

DescriptionThe HttpOnly bit of the SessionId cookie will be set automatically, so that compliant browsers will not make the cookie available to client side scripting.

User Scenarioempty

Work AroundWrite a custom module that copies the session id cookie into another cookie, and clears the HttpOnly bit so it can be manipulated by client script. Or, write a custom session id manager that does not set the HttpOnly bit.
 

 

 
Short DescriptionStatic file no longer served when mapped to aspnet isapi
Affected APIsnoneSeverityLowCompat Switch AvailableNo

DescriptionVersion 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 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.

User Scenario If a user has an existing version 1.1 application set up on IIS6 that maps particular static file extensions to asp.net isapi, these extensions would no longer be served. If the user has *-mapped all extensions to ASP.NET, they will continue to work, however.

Work AroundCreate specific mappings in ASP.NET handler configuration to StaticFileHandler for all specific mappings in IIS6 scriptmaps.
 

 

 
Short DescriptionTrailing spaces to an advertisement file are no longer trimmed under custom account
Affected APIsnoneSeverityLowCompat Switch AvailableNo

DescriptionThe Control used to call mappathsecure; due to security review the API is implementign a more secure algorithme/checking which does not allow trailling spaces. As a result this breaking change is seen by the AdRotator: "System.Web.HttpException: The AdRotator ID could not find the AdvertisementFile or the file is invalid."

User ScenarioIf a developer derfines trailing spaces after the file (ex "ad1.xml ") then version 2.0 throws an exception.

Work AroundNo workaround out of the box, developer will need to remove trailing spaces.
 

 

 
Short Description"Server unavailable" when app is mapped to UNC share and aspnet is running under custom account
Affected APIsN.ASeverityLowCompat Switch AvailableNo

DescriptionWhen an application is mapped to a UNC share and the application is running under a custom account then Asp.Net fails with a 'Server Unavailable' error. This will happen if the custom account doesn't have adequate metabase permissions. The app domain doesn't get created in such case leading to the error. The User needs to run the following command line: 'aspnet_regiis -ga <user>' to grant the required access to the custom account.

User ScenarioApplication mapped to UNC and running under a custom account fails on version 2.0 if the user doesn't have permissions on the metabase.

Work AroundRun 'aspnet_regiis -ga <user>' from the framework install dir.
 

 

 
Short DescriptionThe form's name attribute is no longer rendered to the response for XHTML compliance. The form's ID is and continues to be generated.
Affected APIsnoneSeverityLowCompat Switch AvailableNo

DescriptionThe form's name attribute is no longer rendered to the response for XHTML compliance. The form's ID is and continues to be generated.

User ScenarioWhere the developer specifically wrote javascript code for use on the client only, and referenced the form by name directly, this code will now fail to execute., e.g. this.document.<formname>

Work Around

#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.

 

 

 
Short DescriptionControls using doPostBack script for posting cause script errors in v1.2 if HttpHandlers are cleared except PageHander (for*.aspx). Same functionality worked in v1.1
Affected APIsSystem.Web.dllSeverityLowCompat Switch AvailableNo

Description

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.


User ScenarioIn v1.1 if a web.config had the following entry and the page contained a control that relies on doPostBack function—the page would work fine and postback will happen in a normal way but if such a web config was used on v1.2 and a page was browsed which had a linkbutton on it—the linkbutton will not post and a script error will be seen. This is because in v1.2 we rely on the WebResource handler to provide with the required .js file which contains the actual script.

Work Aroundnone
 

 

 
Short DescriptionFormsAuth should not leave tickets around for 50 years
Affected APIsunkSeverityLowCompat Switch AvailableNo

Description

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).


User Scenariosee above

Work Around

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));

 

 

 
Short Descriptionthe class differences in MIT assemblies between v1.1DU4 and current v2.0
Affected APIsDU2/DU4: Assembly: System.Web.UI.MobileControls.Adapters.dl, DU2/DU4: NS: System.Web.UI.MobileControls.Adapters and System.Web.UI.MobileControls.Adapters.XhtmlAdaptersSeverityLowCompat Switch AvailableNo

Description

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.


User Scenario

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.

Work Aroundcheck scenario
 

 

 
Short DescriptionSpaces in urls are encoded in V2.0 while they weren't in V1.1.
Affected APIsNoneSeverityVery LowCompat Switch AvailableNo

DescriptionIf image paths with trailing spaces are not found correctly after upgrade, the src property of the control needs to be updated to remove the unnecessary space.

User Scenario

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.


Work Aroundremove spaces in urls where they are not needed
 

 

 
Short DescriptionCompiler error thrown when there is more than one Default.aspx in a site
Affected APIsNoneSeverityVery LowCompat Switch AvailableNo

Description

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.


User ScenarioSee description

Work Around
  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.
 

 

 
Short Description"display:none" CSS attribute in a control designer's design-time isn't honored by Venus in V2.0.
Affected APIsNoneSeverityVery LowCompat Switch AvailableNo

Description"display:none" CSS attribute in a control designer's design-time isn't honored by Venus in V2.0.

User ScenarioIf a custom control vendor/developer uses this style attribute in design-time markup it will not be honored.

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

 

 
Short DescriptionDuring the UnLoad phase of the control lifecycle, children of the control are nulled out as part of the Dispose semantics for cleaning up resources. This is a subtle change from V1.1 behavior where garbage collection was the means of cleanup.
Affected APIsSystem.Web.UI.Control.UnLoadSeverityVery LowCompat Switch AvailableNo

DescriptionChild controls are removed from the control collection during UnLoad.

User ScenarioASP.NET page developers who cached actual control instances themselves and attempted to re-use them on subsequent requests find that the children of the control are no longer present.

Work AroundNo recommended workaround. The recommendation would be to instantiate a new instance of the control.
 

 

 
Short DescriptionIn V2.0 GetCustomAttributes() is called on the webpage's code behind files, causing attribute constructors to be executed, which did not happen in V1.1.
Affected APIsNoneSeverityVery LowCompat Switch AvailableNo

DescriptionIn V2.0 custom (code)attributes on controls are queried and therefore instantiated. Users need to ensure that they have written custom attributes following good design patterns.

User ScenarioIf a custom control vendor/developer created a custom attribute and adorned pages or controls with the attribute, the page framework in V2.0 will be inspecting that attribute. Developers who make assumptions about the constructor of the attribute not being called in such cases will be affected.

Work AroundAvoid throwing in the constructor.
 

 

 
Short DescriptionASP.NET is now using dymanic assemblies.
Affected APIsNoneSeverityVery LowCompat Switch AvailableNo

DescriptionIn V1.x, ASP.NET did not use dynamic assemblies that were generated and loaded into the app-domain; however, in V2.0 it does.

User ScenarioSee description

Work AroundA developer should instead be using typeof() to obtain a type reference from the assembly, and then use that to get the assembly information, rather than the codeBase.
typeof(SomeTypeInThatAssembly).Assembly.
 

 

 
Short DescriptionIn V2.0 attributes are not allowed to be specified inside a section group of a config file. There was no such check in V1.1.
Affected APIsNoneSeverityVery LowCompat Switch AvailableNo

Description

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.


User ScenarioSee description

Work AroundNone
 

 

 
Short Description<location> path attribute cannot end with any of '.', '/', or '\'.
Affected APIsNoneSeverityVery LowCompat Switch AvailableNo

DescriptionIn V1.1, a user can put <location path="app/"> in the config file. The config system won't complain about the trailing forward slash, but the problem is that the config settings inside this location tag actually won't get applied in a request to that path.

User ScenarioSee description

Work AroundNone
 

 

 
Short DescriptionTyped Data Set referenced through namespace in other schema file definition, is not mapped to DataSet type as expected. error CS0029: Cannot implicitly convert type 'myDataSet' to 'System.Xml.XmlElement'
Affected APIsN/ASeverityVery LowCompat Switch AvailableNo

DescriptionAfter updating a web reference user may see the following compile error: error CS0029: Cannot implicitly convert type 'myDataSet' to 'System.Xml.XmlElement'.

User ScenarioRunning application will not be affected, the situation only arises after re-generating sources using xsd.erxe tool with /c switch on schemas that represent typed DataSet structures.

Work AroundEdit the generated code replace XmlElement with the proper class name.
 

 

 
Short DescriptionHosted AppDomain returns a NullReferenceException at HostingEnvironment.get_HasHostingIdentity()
Affected APIsHttpRuntime.AppDomainAppIdSeverityVery LowCompat Switch AvailableNo

DescriptionThe AppDomainAppId is used in several places for controlling synchronization of shutdown, etc. for hosting the HttpRuntime. A scenario in V1.1 where it was not set correctly managed to process requests in this scenario correctly. Because of several changes, including this bug fix, hosting the runtime without correctly initializing the runtime no longer works.

User ScenarioHosting the runtime requires correctly initializing the appdomain. This user is essentially trying to take advantage of internal implementation details instead of using the prescribed method for hosting, as demonstrated in the Cassini sample.

Work AroundNone
 

 

 
Short DescriptionHttpContext.RewritePath changes '\' to a '/' when set in pathinfo.
Affected APIsHttpContext.RewritePathSeverityVery LowCompat Switch AvailableNo

DescriptionWhen rewriting an inbound URL, the backslash character is converted to a forward slash when in previous versions it was not.

User Scenario

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 '/'.


Work AroundNone
 

 

 
Short DescriptionRemove the DirectoryEntry.Password {get;}
Affected APIsDirectoryEntry.Password {get;}SeverityLowCompat Switch AvailableNo

DescriptionFrom security review/threat modeling, it was recommended that password {get; } be removed.

User ScenarioThe user relies on DirectoryEntry to retrieve the password, after he sets it.

Work AroundThe user should store the password after setting it rather than relying on the getter.
 

 

 
Short DescriptionThe title element on aspx pages with a runat server tag was instantiated as a HtmlGenericControl in v1.1, in v2.0 it has its own type HtmlTitle but this doesn't derive from HtmlGenericControl and thus the compat break.
Affected APIsN.A.SeverityVery LowCompat Switch AvailableNo

DescriptionIn v1.1 if users added a runat server attribute to html elements not mapped to any particular type, these would get instantiated as HtmlGenericControl. In v2.0, some of these much used Html elements were promoted to have their own types; HtmlTitle is one of them. As it doesn't derive from HtmlGenericControl, there is a compatibility break.

User ScenarioUser declared the following: <title runat="server" id="title1" /> on the aspx page and had a codebehind which declared the control as protected HtmlGenericControl title1; for use in the code behind

Work AroundChange the codebehind to use the HtmlTitle class instead of the HtmlGenericControl class
 

 

 
Short DescriptionEvent Validation feature affects pages containing self-closing IFrames
Affected APIsN.A.SeverityVery LowCompat Switch AvailableNo

DescriptionIn v2.0, a new feature was added for security against fraudulent postbacks. The feature validates the events being raised. As part of the validation the framework posts encrypted data which is part of the __EVENTVALIDATION hidden field. The hidden field is generated as the last element on the form. If the form contains self closing IFrames then any content on the page after the IFrame is assumed to be part of the IFrame and is thus not posted back during posting the page. As the __EVENTVALIDATION doesn't get posted, the server thows a 'Invalid postback...' exception.

User ScenarioAn aspx page which contains self-closing IFrames and posts to the server

Work AroundAdd the following configuration setting in app web.config
<configuration> <system.web> <pages enableEventValidation="true" /> </system.web> </configuration>
or use explicitly closed IFrames using <IFrame>...</IFrame> syntax
 

 

 
Short DescriptionTrace functionality is carried over to a page being transferred to using Server.Transfer if the initial page had trace enabled.
Affected APIsN.A.SeverityVery LowCompat Switch AvailableNo

DescriptionDevelopers can use the tracing feature to get information on intrinsics and also detailed information about the page events being raised, their timing and the page control tree. Users can enable tracing either in config by a global setting, which will cause trace information to be generated for each page, or on each page via a page directive attribute 'Trace'. In v1.1, if a page had tracing enabled and navigated to another page using Server.Transfer(URL), the transferred page would not displaye the trace info unless it had trace enabled. This behavior has changed in v2.0 and trace information gets displayed on transferred page, irrespective of whether trace was enabled or not.

User ScenarioTrace is enabled on a page which transfer to a second page

Work AroundNone
 

 

 
Short DescriptionCustom textbox control overriding the ReadOnly property for the TextBox and not handling the property implementation to guard against access of the property before it was set, will fail with null ref exception
Affected APIsSystem.Web.UI.WebControls.TextBoxSeverityVery LowCompat Switch AvailableNo

DescriptionIn v2.0, the textbox control additionally inspects the ReadOnly property in the SaveTextViewState method to decide whether textbox text should be saved to viewstate. If a customer had overridden the ReadOnly property in a custom textbox but the implementation was not always returning valid values, the control will fail on v2.0

User ScenarioUser has a custom textbox control which overrides ReadOnly but doesn't always return valid values

Work AroundImplement the ReadOnly property such that it returns valid values
 

 

 
Short DescriptionResponse.WriteFile throws exception if the length to be written is specified as -1
Affected APIsSystem.Web.HttpResponseSeverityVery LowCompat Switch AvailableNo

DescriptionThe Response.WriteFile(file, startPos, length) method is used to output file contents from the input file onto the response stream based on startPos and length. In v1.1, if the length arg was specified as -1 then nothing was written out to the response stream, now an argument exception is thrown.

User ScenarioThere won't be any viable usage of passing -1 as the length to the WriteFile method. To output the entire contents ofthe file 0 is passed in as length.

Work AroundNone
 

 

 
Short DescriptionList controls throw argument out of range exception if the SelectedIndex property was set to less than -1 and the items collection was empty
Affected APIsSystem.Web.UI.WebControls.ListControlSeverityHighCompat Switch AvailableNo

DescriptionIn v1.1 if the SelectedIndex for a list control was set to less than -1 but the items collection was empty, no error would occur. If the list did contain items and selected index was < -1 then the exception would occur. In v2.0, an Argument out of range exception is thrown irrespective of whether the list contained items or not, if the SelectedIndex property is set to < -1.

User ScenarioIf the user sets the SelectedIndex to < -1 when the list control is empty, an exception will occur.

Work AroundEnsure that SelectedIndex property is only set to valid values
 

 

 
Short DescriptionExtra '>' in web config / machine config files are ignored in v1.1 but throw ConfigurationException in v2.0
Affected APIsN.A.SeverityVery LowCompat Switch AvailableNo

DescriptionIf the web.config or machine.config contained extra '>' in elements then these were ignored in v1.1 but throw the following exception in v2.0 - '[ConfigurationErrorsException]: The configuration section cannot contain a CDATA or text element.'

User ScenarioIf a user has misconceivedly added an extra '>' to the config elements they will receive Configuration error on running their app on v2.0

Work AroundRemove the extra '>'
 

 

 
Short DescriptionClassnames auto-generated for pages/user controls in v1.1 took the casing structure of the filename. In v2.0, this is standardized to lower case
Affected APIsN/ASeverityVery LowCompat Switch AvailableNo

Description

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

User ScenarioAs described

Work AroundUse the classname attribute on declarative page types
 

 

 
Short DescriptionThe browser capability "platform" changed from "WinNT" to "W2K3Server" from v1.1 to v2.0 for Internet Explorer running on 2003 Server.
Affected APIsHttpBrowserCapabilities.PlatformSeverityHighCompat Switch AvailableNo

DescriptionWhen v1.1 shipped, we identified all available Windows platforms at that time and reported them through the "platform" capability. e.g. "WinXP" is the capability value when IE on XP Professional is browsing the server. For other Windows platforms that weren't available, the "platform" capability would be "WinNT" as we didn't know what version they were. In v2.0, since 2003 Server was available, we updated the platform capability from "WinNT" to "W2K3Server" so it could be specifically identified, like any other available Windows platform.

User ScenarioWe are breaking the case when a control or page developer does a specific action based on the platform capability and when the page request is coming from Windows 2003 Server.

Work AroundUse .browser file in App_Browsers folder to override and restore the old value in version 1.1.
 

 

 
Short DescriptionCalendar's ID generated in the markup is now including naming container in v2.0, where it didn't in v1.1.
Affected APIsNone on the server side. Only the id of the Calendar control in the markup is changed when it is in a naming container.SeverityMediumCompat Switch AvailableNo

DescriptionIn v1.1 Calendar's ID rendered in the markup didn't account for naming container. We fixed that to support multiple naming containers that have Calendar controls with the same id.

User ScenarioDeveloper who used the v1.1 Calendar id value in javascript when the Calendar control was in a naming container.

Work AroundChange the client-side javascript to identify the Calendar.ClientId
 

 

 
Short DescriptionHttpContext is a sealed class. If users created their own wrapper to expose this and returned their wrapped instance as the Context property for pages / usercontrols, their apps would fail unless they implemented the new properties on HttpContext.
Affected APIsSystem.Web.HttpContextSeverityLowCompat Switch AvailableNo

DescriptionHttpContext is a sealed class. If users created their own wrapper to expose this and returned their wrapped instance as the Context property for pages / usercontrols, their apps would fail unless they implemented the new properties on HttpContext. HttpContext defines the Profile property in v2.0 and there is dynamically generated code for Page and user control classes which references this property.

User ScenarioHttpContext is a sealed class. If users created their own wrapper to expose this and returned their wrapped instance as the Context property for pages / usercontrols, their apps would fail unless they implemented the new properties on HttpContext.

Work AroundAdd the new property to their wrapper.
 

 

 
Short DescriptionOut-of-band mobile adapter dlls shipped in device updates were consolidated to the core System.Web.Mobile dll.
Affected APIsAffected namespace and classes System.Web.UI.MobileControls.Adapters.XhtmlAdapters System.Web.UI.MobileControls.Adapters.Updates.Xhtml.SR System.Web.UI.MobileControls.Adapters.AlternateChtmlPageAdapter and AlternateHtmlPageAdapter The classes were moved to System.Web.Mobile.dll except the alternate page adapters where the code was consolidated to their original page adapters in System.Web.Mobile.dllSeverityMediumCompat Switch AvailableNo

DescriptionWe shipped two out-of-band dlls via web releases (DU2 and DU4) for device updates of mobile controls to add more device support. They introduced new assemblys and namsepaces for Xhtml adapters, resource strings for Xhtml adapters and a couple updated Chtml and Html page adapters. In v2.0 we consolidated the classes from the out-of-band dlls into the single System.Web.Mobile.dll, and did not include the dlls that were shipped in web releases (since they are no longer needed)

User ScenarioA developer of a mobile application in v1.0 or v1.1 would potentially utilize the new adapters from out-of-band device update. He/She, who has extended types from the adapter assembly in DU2 or DU4, will be required to recompile their application or have policy config to map to the DU assemblies to have their applications continue to run without recompile.

Work AroundFor applications that had extended the out-of-band adapter classes, they can simply recompile or add policy config to map to use the old DU assemblies.
 

 

 
Short DescriptionAn XML control may fail to handle an XML file that contains a DTD. It checks invalid characters in content while it didn't do so in v1.1.
Affected APIsSystem.Web.UI.WebControls.XmlSeverityMediumCompat Switch AvailableNo

DescriptionThe .NET Framework used to use XmlTextReader (directly or indirectly through some XML APIs) to parse XML and XSL contents. In v2.0, this changed to use XmlReader, which has some differences in terms of parsing characteristics. By default, the BaseURI, ProhibitDTD and CheckCharacters settings are different than the XmlTextReader. Therefore, an Xml control could throw an exception when parsing a simple xml file which references a local DTD using relative paths because the ProhibitDTD setting is false by default for XmlReader.

User ScenarioHaving an Xml control display the content of an Xml file that references a DTD file using a relative path.

Work AroundRemove the DTD reference in the referenced Xml file or use a full path when referencing the DTD
 

 

 
Short Descriptionv2.0 config system doesn't allow the same sections to be defined twice in the same config file.
Affected APIsConfig system will throw when the section is requested.SeverityMediumCompat Switch AvailableNo

Descriptionv2.0 config system doesn't allow the same sections to be defined twice in the same config file. In v1.1 the second of the duplicate section is ignored. In v2.0 we detect the problem and throw.

User ScenarioConfig file has a section defined twice.

Work AroundRemove the duplicate section from the config file.
 

 

 
Short DescriptionIf control tag contains properties which are not defined, a parse exception occurs during ParseControl()
Affected APIsTemplateControl::ParseControl(string content)SeverityMediumCompat Switch AvailableNo

DescriptionIn V1.0/V1.1 we weren't throwing an exception when a user calls ParseControl to parse an invalid control declaration. On the other hand, putting the same control declaration directly on the page as below, it would throw the exception as expected.
<%@ 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>

User ScenarioUses Page.ParseControl(content) to parse an invalid control declaration, for example, with non-matching attributes

Work AroundThe workaround for users is to either (1) implement IAttributeAccessor on their control, so our parse knows how to handle the extra attribute, or (2) have their control derive from HtmlControl or a WebControl that already implements HtmlControl.
 

 

 
Short DescriptionNullReferenceException from user code when databinding a control that is inside a customized UserControl
Affected APIsContainer reference that is autogenerated inside the databindnig templates.SeverityMediumCompat Switch AvailableNo

DescriptionThe container reference in V2.0 will skip UserControl and points directly to the containing Page, In V1.1 this points to the UserControl. This is designed this way since the use of UserControl is simply to provide a file template, it's not meant to be the target of databind.

User ScenarioIn a customized usercontrol that is marked with ParseChildren=false, users have code in the user control that expects the Container reference to point to the usercontrol. For example: <%# Container.FindControl("HiddenControl1").ClientID %>')

Work AroundUse the full clientID instead, this works both in V1 and V2.0<%# Page.FindControl("UserControl1$HiddenControl1").ClientID %>')
 

 

 
Short DescriptionRequest.Cookies[0] throws ArgumentOutOfRangeException on first request when the browser has no cookies
Affected APIsHttpRequest.CookiesSeverityVery LowCompat Switch AvailableNo

Description

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.


User ScenarioIn v1.1 we always read the session cookie from the request, now we have an optimization which will skip this, so this cookie will not always be present.

Work AroundActually try to use the session before accessing the cookie, and the cookie will be found in the Request.Cookies collection
 

 

 
Short DescriptionPage.RegisterRequiresPostBack(Control control) throws an exception if the control is not the expected IPostBackDataHandler.
Affected APIsPage.RegisterRequiresPostBack(Control control)SeverityMediumCompat Switch AvailableNo

Description

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()


User ScenarioSee above

Work AroundThe no-op call of RegisterRequiresPostBack() in Render stage should be removed
 

 

 
Short DescriptionRadioButton.UniqueGroupName failed to be updated correctly if the RadioButton GroupName was changed after it was called once
Affected APIsSystem.Web.UI.WebControls.RadioButtonSeverityMediumCompat Switch AvailableNo

DescriptionBetween v1.1 and v2.0 we optimized the UniqueGroupName getter to only evaluate if it was null (Nothing). Now if the user had some groupname set for radiobuttton which was changed on postback, we end up writing the wrong value out for the name attribute during Render [the stale UniqueGroupName]. In such a situation if the radiobutton is posted back we end up losing its checked state.

User Scenariosee description

Work Aroundnone
 

 

 
Short DescriptionDisplay:none style is not honored at design-time
Affected APIsNoneSeverityMediumCompat Switch AvailableNo

DescriptionSee above

User ScenarioIf a custom control vendor/developer uses this style attribute in design-time markup it will not be honored..

Work Around

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

 

 

 
Short DescriptionAn entire web.config file is validated on the first request to the application
Affected APIsnoneSeverityMediumCompat Switch AvailableNo

Descriptionweb.config file at the app level that has invalid config inside tags pointing to child vdirs will fail validation at the app level. In v1.1 requests to the app succeeded and only requests to the child vdir failed

User Scenarioweb.config at the app level with tags for child vdirs is now completely validated when requesting the app

Work Aroundnone
 

 

 
Short DescriptionStatic files are no longer served when mapped to isapi
Affected APIsNoneSeverityMediumCompat Switch AvailableNo

Description

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


User Scenario If a user has an existing V1.1 application set up on IIS6 that maps particular static file extensions to isapi, these extensions would no longer be served. If the user has *-mapped all extensions to ASP.NET, they will continue to work however

Work AroundCreate specific mappings in ASP.NET handler configuration to StaticFileHandler for all specific mappings in IIS6 scriptmaps.
 

 

 
Short DescriptionDuring the Unload phase of the control lifecycle, we null out the children of the control as part of the Dispose semantics for cleaning up resources. This is a subtle change from version 1.1 behavior where garbage collection was the means of cleanup. The control class was re-factored during version 2.0.
Affected APIsWeb.UI.Control.UnLoadSeverityMediumCompat Switch AvailableNo

DescriptionChild controls are removed from the control collection during Unload.

User ScenarioASP.NET page developers who cached actual control instances themselves and attempt to re-use them on subsequent requests find that the children of the control are no longer present

Work AroundNo recommended workaround. The scenario of re-using controls across page instances is not tested. The recommendation is to instantiate a new instance of the control
 

 

 
Short DescriptionCustom attributes on Control are queried and instantiated
Affected APIsnoneSeverityMediumCompat Switch AvailableNo

DescriptionCustom attributes on Control are queried and therefore, instantiated. Ensure you have written custom attributes following appropriate design patterns.

User ScenarioIf a custom control vendor/developer creates a custom attribute, and adorns pages or controls with this attribute, then the engine will be inspect the attributes. Developers who make assumptions in the constructor of the attribute will be affected.

Work AroundDevelopers need to ensure that their constructors are written to avoid throwing. This will cause the page or control to fail.
 

 

 
Short DescriptionIn v1.x, ASP.NET did not use dynamic assemblies that were generated and loaded into the appdomain
Affected APIsnoneSeverityMediumCompat Switch AvailableNo

DescriptionIn v1.x, ASP.NET did not use dynamic assemblies that were generated and loaded into the appdomain. In V2.0 it does

User ScenarioIn the example, the code simply searches for an assembly, based off the CodeBase, which throws on dynamic assemblies. Any code which does this could be affected when loading dynamic assemblies

Work AroundA developer should instead be using typeof() to obtain a type reference from the assembly, and then use that to get the assembly information, rather than the codeBase.
typeof(SomeTypeInThatAssembly).Assembly
 

 

 
Short DescriptionOnly one section allowed in machine.config
Affected APIsn/aSeverityMediumCompat Switch AvailableNo

DescriptionIn V1.1 we allow 2 sections in the machine.config file. In V2.0 we no longer allow 2 sections

User ScenarioV1.1 Webservices config section used to be able to process multiple elements. Another section that had relaxed rules is : on V1.1 and tags could appear multiple times.

Work Aroundmake sure sections or elements within sections are unique
 

 

 
Short DescriptionFields differing by case now throw an ambiguous reference exception
Affected APIsSystem.WebSeverityMediumCompat Switch AvailableNo

DescriptionDue to the approved CLR breaking change for handling fields whose names differ only by case, we now throw an ambiguous reference exception.

User Scenario

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.


Work AroundRename the duplicated fields.
 

 

 
Short DescriptionSpaces in URLs are now encoded
Affected APIsThe HTML src attribute was not being encoded for server controls.SeverityMediumCompat Switch AvailableNo

DescriptionSpaces in URLs are now encoded. They were not previously encoded in V1.1. If image paths with trailing spaces are not found correctly after upgrade, the src property of the control needs to be updated to remove the unnecessary spaces

User Scenario

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.


Work AroundRemove spaces in URLs where they are not needed.
 

 

 
Short DescriptionHosting the runtime without correctly initializing the runtime no longer works.
Affected APIsHttpRuntime.AppDomainAppIdSeverityMediumCompat Switch AvailableNo

DescriptionThe AppDomainAppId is used in several places for controlling synchronization of shutdown, etc. for hosting the HttpRuntime. A scenario in V1.1 where it was not set correctly managed to process requests in this scenario correctly. Hosting the runtime without correctly initializing the runtime no longer works

User ScenarioA user is referencing AppDomainAppId for controlling synchronization of shutdown.

Work AroundNone
 

 

 
Short DescriptionWhen rewriting an inbound URL, the backslash character is now converted to a forward slash.
Affected APIsHttpContext.RewritePathSeverityMediumCompat Switch AvailableNo

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

User ScenarioIE and other browsers 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.

Work Aroundnone
 

 

 
Short DescriptionIn v2.0 if a developer removes all handlers, then scenarios requiring any client-side static script will no longer function.
Affected APIsnoneSeverityMediumCompat Switch AvailableNo

Descriptionv1.x used client-side static script files for things like client-side validations scripts etc. V2.0 uses embedded resources served via a handler. In v2.0 if a developer removes all handlers, then scenarios requiring the script will no longer function

User Scenario Developers 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.

Work AroundNone
 

 

 
Short DescriptionFormsAuthentication will no longer automatically set the expiration of the persistent auth ticket to 50 years, but use the configured timeout instead
Affected APIsFormsAuthentication.RedirectFromLoginPage, GetRedirectUrl, SetAuthCookie (non-compile breaking change of the API behavior).SeverityMediumCompat Switch AvailableNo

DescriptionForms Authentication is capable of generating 2 types of cookie based tickets: persistent (saved as cookie with expiration), and non-persistent (session cookie, disappear when browser is closed). It supports a configured timeout for the expiration of the cookie/ticket, which is now used.

User ScenarioIn V1.1, when a persistent FormsAuth cookie is issued, it will expire after 50 years. The 'Expires' attribute of the cookie should be set to a configurable value: the value of the forms/timeout attribute, when the ticket is persistent. The default value is 30 minutes.

Work Around

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));

 

 

 
Short DescriptionConfig and lock are reserved names that shoudn't be allowed as a name of a property or element. We are throwing an exception if these names are used as the name of a section as well as the name of an attribute.
Affected APIsN/ASeverityMediumCompat Switch AvailableNo

Description"config" and "lock" are reserved names that shouldn't be allowed as a name of a property or element. We are throwing an exception if these names are used as the name of a section as well as the name of an attribute.

User ScenarioIn the config file, any attribute or section whose name starts with "config" or "lock" will cause an error.

Work AroundRename them to remove "config" or "lock".
 

 

 
Short DescriptionSelectedDate isn't recognized on the UI when it is not set with a DateTime that has zeroes for the hour, minute and second.
Affected APIsSystem.Web.UI.WebControls.Calendar.SelectedDate, and System.Web.UI.WebControls.SelectedDatesCollection.SelectRange(DateTime fromDate, DateTime toDate)SeverityMediumCompat Switch AvailableNo

Description

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.


User ScenarioPages that have set Calendar.SelectedDate with DateTime that doesn't have zeros to hour, minute and second, e.g. DateTime.Today.Now

Work AroundUse DateTime that has zeros for Hour, Minute and Second, by explicitly use the DateTime.Date property.
 

 

 
Short DescriptionParseChildrenAttribute.GetHashCode throws a NullReferenceException if childrenAsProperties is False and childControlType is Null
Affected APIsSystem.Web.UI.ParseChildrenAttribute.GetHashCode()SeverityMediumCompat Switch AvailableNo

DescriptionThe ParseChildrenAttribute will throw a NullReferenceException if childrenAsProperties is false and childControlType is null, which is the default if the default constructor is used. However, GetHashCode is not commonly called on attributes and this was not a customer-reported problem despite being introduced before Beta 2.

User ScenarioCalling GetHashCode() on ParseChildrenAttribute created with the default ctor.

Work AroundDon't call GetHashCode, or set childrenAsProperties to true, or set childControlType.