ASP.NET Run-Time Breaking Changes

Short Description	Removed Bindable attribute from web controls
Affected APIs	NA	Severity	Low	Compat Switch Available	No
Description	Web 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 Scenario	It 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 Around	None

 

Short Description	AdRotator respects height/width values in the advertisement schema whereas v1 AdRotator did not.
Affected APIs	Rendering change	Severity	Low	Compat Switch Available	No
Description	The 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 Scenario	Does not affect existing user code; only rendering
Work Around	Can customize/undo the AdRotator's default rendering in the AdCreated event.

 

Short Description	Valid values required for
Affected APIs	none (config only)	Severity	Low	Compat Switch Available	No
Description	Invalid 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 Scenario	If 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 Around	Configure a correct value or use defaults

 

Short Description	Throw an exception when process identity does not have read access to the metabase.
Affected APIs	N/A	Severity	Low	Compat Switch Available	No
Description	ASP.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 Scenario	User configures a custom account for process identity, which does not have read access to the metabase.
Work Around	Use 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 APIs	Configuration	Severity	Low	Compat Switch Available	No
Description	When 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 Scenario	If 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 Around	Add a configuration directive to tell ASP.NET how to compile that file type.

 

Short Description	Move WebFormDesigner class to new assembly and make internal.
Affected APIs	Microsoft.VSDesigner.WebForms.WebFormDesigner::(all)	Severity	Low	Compat Switch Available	No
Description	In VS 2005 the WebFormDesigner class has been removed.
User Scenario	Someone 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 Around	None

 

Short Description	The 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 APIs	System.Web.UI.Design.ControlDesigner.DesignTimeElementView	Severity	Low	Compat Switch Available	No
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 Scenario	If 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 Around	There 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		Severity	Low	Compat Switch Available	No
Description	An obsolete undocumented configuration attribute is being removed from the
User Scenario	This 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 Around	remove the attribute from config

 

Short Description	Ignore "remove" and "clear" directives in
Affected APIs	ConfigurationSettings.GetConfig, HttpContext.GetConfig	Severity	Low	Compat Switch Available	No
Description	This change only affects web.config and application.config files that remove a section handler declared in a parent configuration file.
User Scenario	This 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 Around	The workaround is to choose a different unique name for the handler, so that removing a previous handler isn't necessary.

 

Short Description	The 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 APIs	N/A	Severity	Low	Compat Switch Available	No
Description	The 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 Scenario	Files with no extension are no longer compiled and assumed to be ASPX
Work Around	Add an extension to the file and an entry in the build providers for the same

 

Short Description	No cache control HTTP headers for static requests through ASP.Net
Affected APIs	None	Severity	Low	Compat Switch Available	No
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 Scenario	If 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 Around	None

 

Short Description	Some directories have special meaning in a web application in version 2.0
Affected APIs	None	Severity	Low	Compat Switch Available	No
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 Scenario	If 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 Around	Folders in a v1.x application that have these names from the app-root should be renamed to avoid any conflict.

 

Short Description	ProcessModel shutDownTimeout previously accepted bogus values. Now it expects correctly formed values.
Affected APIs	ProcessModelSection.ShutDownTimeout	Severity	Low	Compat Switch Available	No
Description	ProcessModel 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 Around	Specify a valid value in HH:MM:SS format

 

Short Description	Added default behavior to encode \n in response headers and configuration option to disable it.
Affected APIs	All APIs that allow arbitrary strings to be inserted in response headers.	Severity	Low	Compat Switch Available	No
Description	A 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 Scenario	Any 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 Around	Set <httpRuntime EnableHeaderChecking=false ... /> for the application

 

Short Description	When 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 APIs	Configuration APIs are new to version 2.0,	Severity	Low	Compat Switch Available	No
Description	When 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 Scenario	See description
Work Around	use

 

Short Description	AdRotator respects height/width values in the advertisement schema whereas v1 AdRotator did not.
Affected APIs	Rendering change	Severity	Low	Compat Switch Available	No
Description	The 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 Scenario	Does not affect existing user code; only rendering.
Work Around	Can customize/undo the AdRotator's default rendering in the AdCreated event.

 

Short Description	The V1 model of using view links is no longer used in 2.0.
Affected APIs	System.Web.UI.Design.ControlDesigner.DesignTimeElementView	Severity	Low	Compat Switch Available	No
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 Scenario	If 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 Around	None

 

Short Description	When very long paths are passed to Server.MapPath, they now fail with an InvalidOperationException instead of a PathTooLongException.
Affected APIs	System.Web.HttpServerUtility.MapPath	Severity	Low	Compat Switch Available	No
Description	An 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 Scenario	An 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 Around	In either release, it's an error condition and any global exception handling mechanisms will be treated identically.

 

Short Description	Requesting 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 APIs	none	Severity	Low	Compat Switch Available	No
Description	web.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 Around	none

 

Short Description	Expired URI-based session ids will not be reused for new sessions. Turn session id regeneration on by default.
Affected APIs	none	Severity	Low	Compat Switch Available	No
Description	See 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 Description	FormsAuthModule accepts valid tickets in the query string only when enableCrossAppRedirects="true"(which is not the default setting
Affected APIs	None	Severity	Low	Compat Switch Available	No
Description	Because 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 Scenario	When 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 Around	Set enableCrossAppRedirects to true.

 

Short Description	FormsAuthentication cookie not available to client side script to prevent XSS
Affected APIs	None	Severity	Low	Compat Switch Available	No
Description	The 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 Scenario	If 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 Around	Write 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 Description	Set HttpOnly property of session state cookie to true. Session id cookie not available to client side script to prevent XSS.
Affected APIs	empty	Severity	Low	Compat Switch Available	No
Description	The 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 Scenario	empty
Work Around	Write 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 Description	Static file no longer served when mapped to aspnet isapi
Affected APIs	none	Severity	Low	Compat Switch Available	No
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 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 Around	Create specific mappings in ASP.NET handler configuration to StaticFileHandler for all specific mappings in IIS6 scriptmaps.

 

Short Description	Trailing spaces to an advertisement file are no longer trimmed under custom account
Affected APIs	none	Severity	Low	Compat Switch Available	No
Description	The 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 Scenario	If a developer derfines trailing spaces after the file (ex "ad1.xml ") then version 2.0 throws an exception.
Work Around	No 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 APIs	N.A	Severity	Low	Compat Switch Available	No
Description	When 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 Scenario	Application 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 Around	Run 'aspnet_regiis -ga <user>' from the framework install dir.

 

Short Description	The 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 APIs	none	Severity	Low	Compat Switch Available	No
Description	The 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 Scenario	Where 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 Description	Controls 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 APIs	System.Web.dll	Severity	Low	Compat Switch Available	No
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 Scenario	In 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 Around	none

 

Short Description	FormsAuth should not leave tickets around for 50 years
Affected APIs	unk	Severity	Low	Compat Switch Available	No
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 Scenario	see 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 Description	the class differences in MIT assemblies between v1.1DU4 and current v2.0
Affected APIs	DU2/DU4: Assembly: System.Web.UI.MobileControls.Adapters.dl, DU2/DU4: NS: System.Web.UI.MobileControls.Adapters and System.Web.UI.MobileControls.Adapters.XhtmlAdapters	Severity	Low	Compat Switch Available	No
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 Around	check scenario

 

Short Description	Spaces in urls are encoded in V2.0 while they weren't in V1.1.
Affected APIs	None	Severity	Very Low	Compat Switch Available	No
Description	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 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 Around	remove spaces in urls where they are not needed

 

Short Description	Compiler error thrown when there is more than one Default.aspx in a site
Affected APIs	None	Severity	Very Low	Compat Switch Available	No
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 Scenario	See description
Work Around	Turn off batching in web.config. This requires no code change and completely fixes the issue. Don't use files with the same name, or use a classname attribute to make the class different. 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 APIs	None	Severity	Very Low	Compat Switch Available	No
Description	"display:none" CSS attribute in a control designer's design-time isn't honored by Venus in V2.0.
User Scenario	If 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 Description	During 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 APIs	System.Web.UI.Control.UnLoad	Severity	Very Low	Compat Switch Available	No
Description	Child controls are removed from the control collection during UnLoad.
User Scenario	ASP.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 Around	No recommended workaround. The recommendation would be to instantiate a new instance of the control.

 

Short Description	In 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 APIs	None	Severity	Very Low	Compat Switch Available	No
Description	In 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 Scenario	If 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 Around	Avoid throwing in the constructor.

 

Short Description	ASP.NET is now using dymanic assemblies.
Affected APIs	None	Severity	Very Low	Compat Switch Available	No
Description	In 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 Scenario	See description
Work Around	A 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 Description	In 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 APIs	None	Severity	Very Low	Compat Switch Available	No
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 Scenario	See description
Work Around	None

 

Short Description	<location> path attribute cannot end with any of '.', '/', or '\'.
Affected APIs	None	Severity	Very Low	Compat Switch Available	No
Description	In 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 Scenario	See description
Work Around	None

 

Short Description	Typed 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 APIs	N/A	Severity	Very Low	Compat Switch Available	No
Description	After updating a web reference user may see the following compile error: error CS0029: Cannot implicitly convert type 'myDataSet' to 'System.Xml.XmlElement'.
User Scenario	Running 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 Around	Edit the generated code replace XmlElement with the proper class name.

 

Short Description	Hosted AppDomain returns a NullReferenceException at HostingEnvironment.get_HasHostingIdentity()
Affected APIs	HttpRuntime.AppDomainAppId	Severity	Very Low	Compat Switch Available	No
Description	The 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 Scenario	Hosting 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 Around	None

 

Short Description	HttpContext.RewritePath changes '\' to a '/' when set in pathinfo.
Affected APIs	HttpContext.RewritePath	Severity	Very Low	Compat Switch Available	No
Description	When 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 Around	None

 

Short Description	Remove the DirectoryEntry.Password {get;}
Affected APIs	DirectoryEntry.Password {get;}	Severity	Low	Compat Switch Available	No
Description	From security review/threat modeling, it was recommended that password {get; } be removed.
User Scenario	The user relies on DirectoryEntry to retrieve the password, after he sets it.
Work Around	The user should store the password after setting it rather than relying on the getter.

 

Short Description	The 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 APIs	N.A.	Severity	Very Low	Compat Switch Available	No
Description	In 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 Scenario	User 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 Around	Change the codebehind to use the HtmlTitle class instead of the HtmlGenericControl class

 

Short Description	Event Validation feature affects pages containing self-closing IFrames
Affected APIs	N.A.	Severity	Very Low	Compat Switch Available	No
Description	In 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 Scenario	An aspx page which contains self-closing IFrames and posts to the server
Work Around	Add 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 Description	Trace functionality is carried over to a page being transferred to using Server.Transfer if the initial page had trace enabled.
Affected APIs	N.A.	Severity	Very Low	Compat Switch Available	No
Description	Developers 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 Scenario	Trace is enabled on a page which transfer to a second page
Work Around	None

 

Short Description	Custom 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 APIs	System.Web.UI.WebControls.TextBox	Severity	Very Low	Compat Switch Available	No
Description	In 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 Scenario	User has a custom textbox control which overrides ReadOnly but doesn't always return valid values
Work Around	Implement the ReadOnly property such that it returns valid values

 

Short Description	Response.WriteFile throws exception if the length to be written is specified as -1
Affected APIs	System.Web.HttpResponse	Severity	Very Low	Compat Switch Available	No
Description	The 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 Scenario	There 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 Around	None

 

Short Description	List controls throw argument out of range exception if the SelectedIndex property was set to less than -1 and the items collection was empty
Affected APIs	System.Web.UI.WebControls.ListControl	Severity	High	Compat Switch Available	No
Description	In 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 Scenario	If the user sets the SelectedIndex to < -1 when the list control is empty, an exception will occur.
Work Around	Ensure that SelectedIndex property is only set to valid values

 

Short Description	Extra '>' in web config / machine config files are ignored in v1.1 but throw ConfigurationException in v2.0
Affected APIs	N.A.	Severity	Very Low	Compat Switch Available	No
Description	If 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 Scenario	If a user has misconceivedly added an extra '>' to the config elements they will receive Configuration error on running their app on v2.0
Work Around	Remove the extra '>'

 

Short Description	Classnames 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 APIs	N/A	Severity	Very Low	Compat Switch Available	No
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 Scenario	As described
Work Around	Use the classname attribute on declarative page types

 

Short Description	The browser capability "platform" changed from "WinNT" to "W2K3Server" from v1.1 to v2.0 for Internet Explorer running on 2003 Server.
Affected APIs	HttpBrowserCapabilities.Platform	Severity	High	Compat Switch Available	No
Description	When 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 Scenario	We 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 Around	Use .browser file in App_Browsers folder to override and restore the old value in version 1.1.

 

Short Description	Calendar's ID generated in the markup is now including naming container in v2.0, where it didn't in v1.1.
Affected APIs	None on the server side. Only the id of the Calendar control in the markup is changed when it is in a naming container.	Severity	Medium	Compat Switch Available	No
Description	In 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 Scenario	Developer who used the v1.1 Calendar id value in javascript when the Calendar control was in a naming container.
Work Around	Change the client-side javascript to identify the Calendar.ClientId

 

Short Description	HttpContext 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 APIs	System.Web.HttpContext	Severity	Low	Compat Switch Available	No
Description	HttpContext 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 Scenario	HttpContext 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 Around	Add the new property to their wrapper.

 

Short Description	Out-of-band mobile adapter dlls shipped in device updates were consolidated to the core System.Web.Mobile dll.
Affected APIs	Affected 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.dll	Severity	Medium	Compat Switch Available	No
Description	We 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 Scenario	A 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 Around	For 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 Description	An 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 APIs	System.Web.UI.WebControls.Xml	Severity	Medium	Compat Switch Available	No
Description	The .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 Scenario	Having an Xml control display the content of an Xml file that references a DTD file using a relative path.
Work Around	Remove the DTD reference in the referenced Xml file or use a full path when referencing the DTD

 

Short Description	v2.0 config system doesn't allow the same sections to be defined twice in the same config file.
Affected APIs	Config system will throw when the section is requested.	Severity	Medium	Compat Switch Available	No
Description	v2.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 Scenario	Config file has a section defined twice.
Work Around	Remove the duplicate section from the config file.

 

Short Description	If control tag contains properties which are not defined, a parse exception occurs during ParseControl()
Affected APIs	TemplateControl::ParseControl(string content)	Severity	Medium	Compat Switch Available	No
Description	In 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 Scenario	Uses Page.ParseControl(content) to parse an invalid control declaration, for example, with non-matching attributes
Work Around	The 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 Description	NullReferenceException from user code when databinding a control that is inside a customized UserControl
Affected APIs	Container reference that is autogenerated inside the databindnig templates.	Severity	Medium	Compat Switch Available	No
Description	The 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 Scenario	In 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 Around	Use the full clientID instead, this works both in V1 and V2.0<%# Page.FindControl("UserControl1$HiddenControl1").ClientID %>')

 

Short Description	Request.Cookies[0] throws ArgumentOutOfRangeException on first request when the browser has no cookies
Affected APIs	HttpRequest.Cookies	Severity	Very Low	Compat Switch Available	No
Description	In v2.0 we added a performance optimization to eliminate reading the sessionID out of the request in a few cases: it must be mode=InProc, cookieless=false session state is disabled 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 Scenario	In 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 Around	Actually try to use the session before accessing the cookie, and the cookie will be found in the Request.Cookies collection

 

Short Description	Page.RegisterRequiresPostBack(Control control) throws an exception if the control is not the expected IPostBackDataHandler.
Affected APIs	Page.RegisterRequiresPostBack(Control control)	Severity	Medium	Compat Switch Available	No
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 Scenario	See above
Work Around	The no-op call of RegisterRequiresPostBack() in Render stage should be removed

 

Short Description	RadioButton.UniqueGroupName failed to be updated correctly if the RadioButton GroupName was changed after it was called once
Affected APIs	System.Web.UI.WebControls.RadioButton	Severity	Medium	Compat Switch Available	No
Description	Between 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 Scenario	see description
Work Around	none

 

Short Description	Display:none style is not honored at design-time
Affected APIs	None	Severity	Medium	Compat Switch Available	No
Description	See above
User Scenario	If 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 Description	An entire web.config file is validated on the first request to the application
Affected APIs	none	Severity	Medium	Compat Switch Available	No
Description	web.config file at the app level that has invalid config inside
User Scenario	web.config at the app level with
Work Around	none

 

Short Description	Static files are no longer served when mapped to isapi
Affected APIs	None	Severity	Medium	Compat Switch Available	No
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 Around	Create specific mappings in ASP.NET handler configuration to StaticFileHandler for all specific mappings in IIS6 scriptmaps.

 

Short Description	During 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 APIs	Web.UI.Control.UnLoad	Severity	Medium	Compat Switch Available	No
Description	Child controls are removed from the control collection during Unload.
User Scenario	ASP.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 Around	No 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 Description	Custom attributes on Control are queried and instantiated
Affected APIs	none	Severity	Medium	Compat Switch Available	No
Description	Custom attributes on Control are queried and therefore, instantiated. Ensure you have written custom attributes following appropriate design patterns.
User Scenario	If 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 Around	Developers need to ensure that their constructors are written to avoid throwing. This will cause the page or control to fail.

 

Short Description	In v1.x, ASP.NET did not use dynamic assemblies that were generated and loaded into the appdomain
Affected APIs	none	Severity	Medium	Compat Switch Available	No
Description	In v1.x, ASP.NET did not use dynamic assemblies that were generated and loaded into the appdomain. In V2.0 it does
User Scenario	In 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 Around	A 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 Description	Only one
Affected APIs	n/a	Severity	Medium	Compat Switch Available	No
Description	In V1.1 we allow 2
User Scenario	V1.1 Webservices config section used to be able to process multiple elements. Another section that had relaxed rules is
Work Around	make sure sections or elements within sections are unique

 

Short Description	Fields differing by case now throw an ambiguous reference exception
Affected APIs	System.Web	Severity	Medium	Compat Switch Available	No
Description	Due 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 Around	Rename the duplicated fields.

 

Short Description	Spaces in URLs are now encoded
Affected APIs	The HTML src attribute was not being encoded for server controls.	Severity	Medium	Compat Switch Available	No
Description	Spaces 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 Around	Remove spaces in URLs where they are not needed.

 

Short Description	Hosting the runtime without correctly initializing the runtime no longer works.
Affected APIs	HttpRuntime.AppDomainAppId	Severity	Medium	Compat Switch Available	No
Description	The 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 Scenario	A user is referencing AppDomainAppId for controlling synchronization of shutdown.
Work Around	None

 

Short Description	When rewriting an inbound URL, the backslash character is now converted to a forward slash.
Affected APIs	HttpContext.RewritePath	Severity	Medium	Compat Switch Available	No
Description	If you are looking for a '\' in the value returned from HttpContext.RewritePath, it has now been replaced with a '/'.
User Scenario	IE 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 Around	none

 

Short Description	In v2.0 if a developer removes all handlers, then scenarios requiring any client-side static script will no longer function.
Affected APIs	none	Severity	Medium	Compat Switch Available	No
Description	v1.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 Around	None

 

Short Description	FormsAuthentication will no longer automatically set the expiration of the persistent auth ticket to 50 years, but use the configured timeout instead
Affected APIs	FormsAuthentication.RedirectFromLoginPage, GetRedirectUrl, SetAuthCookie (non-compile breaking change of the API behavior).	Severity	Medium	Compat Switch Available	No
Description	Forms 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 Scenario	In 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 Description	Config 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 APIs	N/A	Severity	Medium	Compat Switch Available	No
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 Scenario	In the config file, any attribute or section whose name starts with "config" or "lock" will cause an error.
Work Around	Rename them to remove "config" or "lock".

 

Short Description	SelectedDate isn't recognized on the UI when it is not set with a DateTime that has zeroes for the hour, minute and second.
Affected APIs	System.Web.UI.WebControls.Calendar.SelectedDate, and System.Web.UI.WebControls.SelectedDatesCollection.SelectRange(DateTime fromDate, DateTime toDate)	Severity	Medium	Compat Switch Available	No
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 Scenario	Pages that have set Calendar.SelectedDate with DateTime that doesn't have zeros to hour, minute and second, e.g. DateTime.Today.Now
Work Around	Use DateTime that has zeros for Hour, Minute and Second, by explicitly use the DateTime.Date property.

 

Short Description	ParseChildrenAttribute.GetHashCode throws a NullReferenceException if childrenAsProperties is False and childControlType is Null
Affected APIs	System.Web.UI.ParseChildrenAttribute.GetHashCode()	Severity	Medium	Compat Switch Available	No
Description	The 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 Scenario	Calling GetHashCode() on ParseChildrenAttribute created with the default ctor.
Work Around	Don't call GetHashCode, or set childrenAsProperties to true, or set childControlType.