.NET Framework 4 Migration Issues

Article
02/04/2013

This topic describes migration issues between the .NET Framework version 3.5 Service Pack 1 and the .NET Framework version 4, including fixes, changes for standards compliance and security, and changes based on customer feedback. Most of these changes do not require any programming modifications in your applications. For those that may involve modifications, see the Recommended changes column of the table.

This topic describes notable changes in the following areas:

ASP.NET and Web
Core
Data
Windows Communication Foundation (WCF)
Windows Presentation Foundation (WPF)
XML

For an higher-level overview of the issues in this topic, see the Migration Guide to the .NET Framework 4.

For migration issues after Beta 2, see Migration Issues for .NET Framework 4 Applications: Beta 2 to RTM.

For information about new features, see What's New in the .NET Framework 4.

ASP.NET and Web

Namespaces: System.Web, System.Web.Mobile, System.Web.Security, System.Web.UI.WebControls; assembly: System.Web (in System.Web.dll)

Feature	Differences from 3.5 SP1	Recommended changes
Browser definition files	The browser definition files have been updated to include information about new and updated browsers and devices. Older browsers and devices such as Netscape Navigator have been removed, and newer browsers and devices such as Google Chrome and Apple iPhone have been added. If your application contains custom browser definitions that inherit from one of the browser definitions that have been removed, you will see an error. The HttpBrowserCapabilities object (which is exposed by the page’s Request.Browser property) is driven by the browser definition files. Therefore, the information that is returned by accessing a property of this object in ASP.NET 4 might be different than the information that was returned in an earlier version of ASP.NET.	If your application relies on the old browser definition files, you can copy them from the following folder: Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG\Browsers Copy the files into the corresponding \CONFIG\Browsers folder for ASP.NET 4. After you copy the files, run the Aspnet_regbrowsers.exe command-line tool. For more information, see the https://www.asp.net/mobile Web site.
Child applications running under mixed versions of ASP.NET	ASP.NET 4 applications that are configured as children of applications that run earlier versions of ASP.NET might fail to start because of configuration or compilation errors. The specific error that occurs depends on whether the application runs under IIS 6.0, or under IIS 7 or IIS 7.5.	You can make changes to the configuration files of the affected applications so that the configuration system correctly recognizes the ASP.NET 4 application. For information about the changes you must make, see the section "ASP.NET 4 Child Applications Fail to Start When Under ASP.NET 2.0 or ASP.NET 3.5 Applications" in the document ASP.NET 4 Breaking Changes on the ASP.NET Web site.
ClientID changes	The new clientIDMode setting in ASP.NET 4 lets you specify how ASP.NET generates the id attribute for HTML elements. In previous versions of ASP.NET, the default behavior was equivalent to the AutoID setting of clientIDMode. The default setting is now Predictable. For more information, see ASP.NET Web Server Control Identification.	If you use Visual Studio 2010 to upgrade your application from ASP.NET 2.0 or ASP.NET 3.5, the tool automatically adds a setting to the Web.config file that preserves the behavior of earlier versions of the .NET Framework. However, if you upgrade an application by changing the application pool in IIS to target the .NET Framework 4, ASP.NET uses the new mode by default. To disable the new client ID mode, add the following setting to the Web.config file: <pages clientIDMode="AutoID" / >
Code access security (CAS)	ASP.NET 2.0 NET features that were added in ASP.NET 3.5 use the .NET Framework 1.1 and .NET Framework 2.0 code access security (CAS) model. However, the implementation of CAS in ASP.NET 4 has been substantially overhauled. As a result, partial-trust ASP.NET applications that rely on trusted code running in the global assembly cache might fail with various security exceptions. Partial-trust applications that rely on extensive modifications to machine CAS policy might also fail and throw security exceptions.	You can revert partial-trust ASP.NET 4 applications to the behavior of ASP.NET 1.1 and 2.0 by using the new legacyCasModel attribute in the trust configuration element, as shown in the following example: <trust level= "Medium" legacyCasModel="true" /> Security Note Reverting to the older CAS model might represent reduced security. For more information about the new ASP.NET 4 code access security model, see Code Access Security in ASP.NET 4 Applications.
Configuration files	The root configuration files (the machine.config file and the root Web.config file) for the .NET Framework and ASP.NET 4 have been updated to include most of the boilerplate configuration information that was found in the application Web.config files in ASP.NET 3.5. Because of the complexity of the managed IIS 7 and IIS 7.5 configuration systems, running ASP.NET 3.5 applications under ASP.NET 4 and under IIS 7 and IIS 7.5 can result in either ASP.NET errors or IIS errors.	Upgrade ASP.NET 3.5 applications to ASP.NET 4 by using the project upgrade tools in Visual Studio 2010. Visual Studio 2010 automatically modifies the ASP.NET 3.5 application's Web.config file to contain the appropriate settings for ASP.NET 4. However, you can run ASP.NET 3.5 applications using the .NET Framework 4 without recompilation. In that case, you might have to manually modify the application's Web.config file before you run the application under the .NET Framework 4 and under IIS 7 or IIS 7.5. The specific change you must make depends on the combination of software you are working with, including Service Pack (SP) releases. For information about the possible software combinations that are affected by this change and how to resolve problems with specific combinations, see the section "Configuration Errors Related to New ASP.NET 4 Root Configuration" in the document ASP.NET 4 Breaking Changes on the ASP.NET Web site.
Control rendering	In previous versions of ASP.NET, some controls emitted markup that you could not disable. By default, this type of markup is no longer generated in ASP.NET 4. The rendering changes affect the following controls: The Image and ImageButton controls no longer render a border="0" attribute. The BaseValidator class and validation controls that derive from it no longer render red text by default. The HtmlForm control does not render a name attribute. The Table control no longer renders a border="0" attribute. Controls that are not designed for user input (for example, the Label control) no longer render the disabled="disabled" attribute if their Enabled property is set to false (or if they inherit this setting from a container control).	If you use Visual Studio 2010 to upgrade your application from ASP.NET 2.0 or ASP.NET 3.5, the tool automatically adds a setting to the Web.config file that preserves legacy rendering. However, if you upgrade an application by changing the application pool in IIS to target the .NET Framework 4, ASP.NET uses the new rendering mode by default. To disable the new rendering mode, add the following setting to the Web.config file: <pages controlRenderingCompatibilityVersion="3.5" />
Event handlers in default documents	ASP.NET 4 renders the HTML form element’s action attribute value as an empty string when a request is made to an extensionless URL that has a default document mapped to it. In earlier releases of ASP.NET, a request to https://contoso.com would result in a request to Default.aspx. In that document, the opening form tag would be rendered as in the following example: <form action="Default.aspx" /> In ASP.NET 4, a request to https://contoso.com also results in a request to Default.aspx, but ASP.NET now renders the HTML opening form tag as in the following example: <form action="" /> When the action attribute is an empty string, the IIS DefaultDocumentModule object creates a child request to Default.aspx. Under most conditions, this child request is transparent to application code, and the Default.aspx page runs normally. However, a potential interaction between managed code and IIS 7 or IIS 7.5 Integrated mode can cause managed .aspx pages to stop working properly during the child request. If the following conditions occur, the child request to a default .aspx document will result in an error or in unexpected behavior: An .aspx page is sent to the browser with the form element’s action attribute set to "". The form is posted back to ASP.NET. A managed HTTP module reads some part of the entity body, such as Request.Form or Request.Params. This causes the entity body of the POST request to be read into managed memory. As a result, the entity body is no longer available to any native code modules that are running in IIS 7 or IIS 7.5 Integrated mode. The IIS DefaultDocumentModule object eventually runs and creates a child request to the Default.aspx document. However, because the entity body has already been read by a piece of managed code, there is no entity body available to send to the child request. When the HTTP pipeline runs for the child request, the handler for .aspx files runs during the handler-execute phase. Because there is no entity body, there are no form variables and no view state. Therefore there is no information available for the .aspx page handler to determine what event (if any) should be raised. As a result, none of the postback event handlers for the affected .aspx page run.	For information about ways to work around problems that might arise as a result of this change, see "Event Handlers Might Not Be Not Raised in a Default Document in IIS 7 or IIS 7.5 Integrated Mode" in the document ASP.NET 4 Breaking Changes on the ASP.NET Web site.
Hashing algorithm	ASP.NET uses both encryption and hashing algorithms to help secure data such as forms authentication cookies and view state. By default, ASP.NET 4 uses the HMACSHA256 algorithm for hash operations on cookies and view state. Earlier versions of ASP.NET used the older HMACSHA1 algorithm.	If you run applications that mix ASP.NET 2.0 and ASP.NET 4, where data such as forms authentication cookies must work across .NET Framework versions, configure an ASP.NET 4 Web application to use the older HMACSHA1 algorithm by adding the following setting in the Web.config file: <machineKey validation="SHA1" />
Hosting controls in Internet Explorer	You can no longer host Windows Forms controls in the Internet Explorer, because there are better solutions for hosting controls on the Web. Therefore, the IEHost.dll and IEExec.exe assemblies have been removed from the .NET Framework.	You can use the following technologies for custom control development in Web applications: You can create a Silverlight application and configure it to run outside the browser. For more information, see Out-of-Browser Support. You can build a XAML browser application (XBAP) to take advantage of WPF capabilities (requires the .NET Framework on client machines). For more information, see WPF XAML Browser Applications Overview.
HtmlEncode and UrlEncode methods	The HtmlEncode and UrlEncode methods of the HttpUtility and HttpServerUtility classes have been updated to encode the single quotation mark character (') as follows: The HtmlEncode method encodes instances of the single quotation mark as ' The UrlEncode method encodes instances of the single quotation mark as %27	Examine your code for places where you use the HtmlEncode and UrlEncode methods, and make sure that the change in encoding does not result in a change that would affect your application.
HttpException errors in ASP.NET 2.0 applications	After ASP.NET 4 has been enabled on IIS 6, ASP.NET 2.0 applications that run on IIS 6 (in either Windows Server 2003 or Windows Server 2003 R2) might generate errors such as the following: System.Web.HttpException: Path '/[yourApplicationRoot]/eurl.axd/[Value]' was not found.	If ASP.NET 4 is not required in order to run the Web site, remap the site to use ASP.NET 2.0 instead. -or- If ASP.NET 4 is required in order to run the Web site, move any child ASP.NET 2.0 virtual directories to a different Web site that is mapped to ASP.NET 2.0. -or- Disable extensionless URLs. For more information, see "ASP.NET 2.0 Applications Might Generate HttpException Errors That Reference eurl.axd" in the document ASP.NET 4 Breaking Changes on the ASP.NET Web site.
Membership types	Some types (for example, System.Web.Security.MembershipProvider) that are used in ASP.NET membership have been moved from System.Web.dll to the System.Web.ApplicationServices.dll assembly. The types were moved in order to resolve architectural layering dependencies between types in the client and in extended .NET Framework SKUs.	Class libraries that have been upgraded from earlier versions of ASP.NET and that use membership types that have been moved might fail to compile when used in an ASP.NET 4 project. If so, add a reference in the class library project to System.Web.ApplicationServices.dll.
Menu control changes	Changes to the Menu control result in the following behavior: If System.Web.UI.WebControls.MenuRenderingMode is set to List, or if System.Web.UI.WebControls.MenuRenderingMode is set to Default and PagesSection.ControlRenderingCompatibilityVersion is set to 4.0 or later, the MenuItem.PopOutImageUrl property has no effect. If the path that is set in the Menu.StaticPopOutImageUrl and Menu.DynamicPopOutImageUrl properties contains a backslash (\), the images do not render. (In earlier versions of ASP.NET, the path could include a backslash.)	Instead of setting the MenuItem.PopOutImageUrl property for individual menu items, set the Menu.StaticPopOutImageUrl or Menu.DynamicPopOutImageUrl of the parent System.Web.UI.WebControls.Menu control. -or- Set System.Web.UI.WebControls.MenuRenderingMode to Table, or set System.Web.UI.WebControls.MenuRenderingMode to Default and set PagesSection.ControlRenderingCompatibilityVersion to 3.5. These settings cause the Menu control to use the HTML table-based layout that it used in earlier versions of ASP.NET. If the path in the Menu.StaticPopOutImageUrl or Menu.DynamicPopOutImageUrl property contains a backslash (\), substitute a slash character (/).
Mobile assembly in Web.config file	In previous versions of ASP.NET, a reference to the System.Web.Mobile.dll assembly was included in the root Web.config file in the assemblies section under system.web/compilation. To improve performance, the reference to this assembly has been removed. Note The System.Web.Mobile.dll assembly and the ASP.NET mobile controls are included in ASP.NET 4, but they are deprecated.	If you want to use types from this assembly, add a reference to the assembly in either the root Web.config file or in an application Web.config file.
Output caching	In ASP.NET 1.0, a bug caused cached pages that specified Location="ServerAndClient" as an output–cache setting to emit a Vary:* HTTP header in the response. This had the effect of telling client browsers to never cache the page locally. In ASP.NET 1.1, the HttpCachePolicy.SetOmitVaryStar method was added, which could be called in order to suppress the Vary:* header. However, bug reports suggest that developers are unaware of the existing SetOmitVaryStar behavior. In ASP.NET 4, the Vary:* HTTP header is no longer emitted from responses that specify the following directive: <%@ OutputCache Location="ServerAndClient" %> As a result, the HttpCachePolicy.SetOmitVaryStar method is no longer needed in order to suppress the Vary:* header. In applications that specify "ServerAndClient" for the Location attribute, pages will be cacheable in the browser without requiring that you call HttpCachePolicy.SetOmitVaryStar.	If pages in the application must emit Vary:, call the HttpResponse.AppendHeader method as shown in the following example: HttpResponse.AppendHeader("Vary",""); Alternatively, you can change the value of the output caching Location attribute to "Server".
Page parsing	The page parser for ASP.NET Web pages (.aspx files) and user controls (.ascx files) is stricter in ASP.NET 4 than in earlier versions of ASP.NET, and it flags more markup as invalid than in earlier versions.	Examine error messages that are produced when a page runs and fix errors that result from invalid markup.
Passport types	The Passport support built into ASP.NET 2.0 is obsolete and is unsupported due to changes in Passport (now Live ID SDK). As a result, the types related to Passport in System.Web.Security are now marked with the ObsoleteAttribute attribute.	Change any code you have that uses Passport types in the System.Web.Security namespace (for example, System.Web.Security.PassportIdentity) to use the SDK.
PathInfo information in the FilePath property	ASP.NET 4 no longer includes the PathInfo value in the return values from properties such as HttpRequest.FilePath, HttpRequest.AppRelativeCurrentExecutionFilePath, and HttpRequest.CurrentExecutionFilePath. Instead, the PathInfo information is available in HttpRequest.PathInfo. For example, imagine the following URL fragment: /testapp/Action.mvc/SomeAction In earlier versions of ASP.NET, System.Web.HttpRequest properties have the following values: HttpRequest.FilePath: /testapp/Action.mvc/SomeAction HttpRequest.PathInfo: (empty) In ASP.NET 4, System.Web.HttpRequest properties instead have the following values: HttpRequest.FilePath: /testapp/Action.mvc HttpRequest.PathInfo: SomeAction	Examine your code for places where you rely on properties of the System.Web.HttpRequest class to return path information; change the code to reflect the changes in how path information is returned.
Request validation	To improve request validation, the ASP.NET request validation is invoked earlier in the request life cycle. As a result, request validation runs for requests that are not for .aspx files, such as for Web service calls and for custom handlers. Request validation will also be active when custom HTTP modules are running in the request processing pipeline. As a result of this change, requests for resources other than .aspx files might throw request validation errors. Custom code that runs in the request pipeline (for example, custom HTTP modules) might also throw request validation errors.	If necessary, you can revert to the old behavior of having only .aspx pages triggering request validation by using the following setting in the Web configuration file: <httpRuntime requestValidationMode="2.0" /> Security Note If you revert to the old behavior, make sure that all code in existing handlers, modules, and other custom code performs checks for potentially unsafe HTTP inputs that could be XSS attack vectors.
Routing	If you create a file system Web site in Visual Studio 2010 and the Web site is in a folder that contains a dot (.) in the folder name, URL routing will not work reliably. An HTTP 404 error is returned from some virtual paths. This occurs because Visual Studio 2010 launches the Visual Studio Development Server (Cassini) using an incorrect path for the root virtual directory.	In the Properties page for the file-based Web site, change the Virtual Path attribute to "/". -or- Create a Web application project instead of a Web site project. Web application projects do not have this issue, and URL routing works even if the project folder has a dot in its name. -or- Create an HTTP-based Web site that is hosted in IIS. IIS-hosted Web sites can have dots in the virtual path as well as in the project file folder.
SharePoint sites	If you try to run an ASP.NET 4 Web site that is deployed as a child of a SharePoint Web site that contains a custom partial-trust level named WSS_Minimal, you will see the following error: Could not find permission set named 'ASP.Net'.	Currently, no versions of SharePoint are compatible with ASP.NET. As a result, you should not attempt to run an ASP.NET 4 Web site as a child of a SharePoint Web site.
XHTML 1.1 standards	To enable XHTML 1.1 compliance for new Web sites, the ASP.NET controls in the .NET Framework 4 will generate XHTML 1.1 compliant HTML. This rendering is enabled using the following option in the Web.config file: <system.Web> <pages controlRenderingCompatibilityVersion="4.0"/> </system.Web> This option is set by default to 4.0. Web projects that are upgraded to Visual Studio from Visual Studio 2008 will have the 3.5 setting enabled for compatibility.	None.

Core

General Features

Feature	Differences from 3.5 SP1	Recommended changes
CardSpace	Windows CardSpace is no longer included in the .NET Framework; it is provided separately.	Download Windows CardSpace from the Microsoft Download Center.
Configuration files	Corrections have been made in how the .NET Framework accesses application configuration files.	If your application configuration file is named application-name.config, rename it to application-name.exe.config. For example, rename MyApp.config to MyApp.exe.config.
C# code compiler	The Compiler, CompilerError, and ErrorLevel classes that were in the Microsoft.CSharp namespace are no longer available, and their assembly (cscompmgd.dll) is no longer included in the .NET Framework.	Use the CodeDomProvider class and other classes in the System.CodeDom.Compiler namespace. For more information, see Using the CodeDOM.
Hosting (unmanaged API)	To improve hosting capabilities, some of the hosting activation APIs have been deprecated. In-process side-by-side execution features enable an application to load and start multiple versions of the .NET Framework in the same process. For example, you can run applications that load add-ins (or components) that are based on the .NET Framework 2.0 SP1 and add-ins that are based on the .NET Framework 4 in the same process. Older components continue to use the older .NET Framework version, and new components use the new .NET Framework version.	Use the configurations described in In-Process Side-by-Side Execution.
New security model	The code access security (CAS) policy has been turned off and replaced with a simplified model, as described in Security Changes in the .NET Framework 4.	Modifications may be required if you depend on CAS in your applications. For more information, see Code Access Security Policy Compatibility and Migration.

Date and Time

Namespace: System; assembly: mscorlib (in mscorlib.dll)

Feature	Differences from 3.5 SP1	Recommended changes
Daylight savings	To be consistent with the system clock, time properties (such as TimeZoneInfo.Local and DateTime.Now) now use operating system rules instead of other .NET Framework data for daylight saving time operations.	None.
Formatting strings	To support culture-sensitive formatting, the TimeSpan structure includes new overloads of the ToString, Parse, and TryParse methods in addition to new ParseExact and TryParseExact methods.	None.

Globalization

For a list of new neutral and specific cultures, see What's New in Globalization and Localization.

Namespace: System.Globalization; assembly: mscorlib (in mscorlib.dll)

Feature	Differences from 3.5 SP1	Recommended changes
Culture names	The following name changes affect the German, Divehi, and African cultures: CurrencyEnglishName: The currency name for the German (Switizerland) (de-CH) culture has changed from "sFr." to "Fr.". LongDatePattern: The long date pattern for the Divehi (Maldives) (dv-MV) culture has changed from "dd/MMMM/yyyy" to "dd/MM/yyyy". PMDesignator: The P.M. designator of the Afrikaans (South Africa) (af-ZA) culture has changed from "nm" to "PM".	Note culture name changes.
LCID parameter	To be consistent with expected behavior in automation server settings, the CLR no longer passes the current culture for the LCID parameter to unmanaged COM-based applications. Instead, it passes 1033 (en-us) for the culture.	No modifications necessary except for native applications that require a specified culture.
Obsolete culture types	The FrameworkCultures and WindowsOnlyCultures culture types are now obsolete. For backward compatibility, FrameworkCultures now returns neutral and specific cultures that were included with the previous .NET Framework, and WindowsOnlyCultures now returns an empty list.	Use other values of the CultureTypes enumeration.
Retrieving culture	Beginning with Windows 7, the .NET Framework 4 retrieves culture information from the operating system instead of storing the data itself. In addition, the .NET Framework synchronizes with Windows for sorting and casing data.	None.
Unicode 5.1 standards	The .NET Framework now supports all Unicode 5.1 characters -- an addition of approximately 1400 characters. The additional characters include new symbols, arrows, diacritics, punctuation, mathematical symbols, CJK strokes and ideographs, additional Malayalam and Telugu numeric characters, and various Myanmar, Latin, Arabic, Greek, Mongolian, and Cyrillic characters. The following new scripts are supported with Unicode 5.1: Sundanese, Lepcha, Ol Chiki, Vai, Saurashtra, Kayah Li, Rejang, Gurmukhi, Odia, Tamil, Telugu, and Malayalam characters and Cham.	None.

Exceptions

Namespaces: System, System.Runtime.ExceptionServices; assembly: mscorlib (in mscorlib.dll)

Feature	Differences from 3.5 SP1	Recommended changes
Exceptions for corrupted process state	The CLR no longer delivers exceptions for corrupted process state to exception handlers in managed code.	These exceptions indicate that the state of a process has been corrupted. We do not recommend that you run your application in this state. For more information, see the HandleProcessCorruptedStateExceptionsAttribute and the entry Handling Corrupted State Exceptions in the CLR Inside Out blog.
Execution engine exceptions	ExecutionEngineException is now obsolete, because a catchable exception will allow an unstable process to continue to run. This change improves predictability and reliability in the runtime.	Use an InvalidOperationException to signal the condition.

Exceptions for corrupted process state

The CLR no longer delivers exceptions for corrupted process state to exception handlers in managed code.

These exceptions indicate that the state of a process has been corrupted. We do not recommend that you run your application in this state.

For more information, see the HandleProcessCorruptedStateExceptionsAttribute and the entry Handling Corrupted State Exceptions in the CLR Inside Out blog.

Execution engine exceptions

ExecutionEngineException is now obsolete, because a catchable exception will allow an unstable process to continue to run. This change improves predictability and reliability in the runtime.

Use an InvalidOperationException to signal the condition.

Reflection

Namespace: System.Reflection; assembly: mscorlib (in mscorlib.dll)

Feature	Differences from 3.5 SP1	Recommended changes
Assembly hash algorithms	The AssemblyName.HashAlgorithm property now returns AssemblyHashAlgorithm.None, because the runtime does not know the hash algorithm of the referenced assembly when the assembly is not loaded. (This refers to using the property on a referenced assembly such as that returned by the Assembly.GetReferencedAssemblies method.)	None.
Assembly loading	To prevent redundant loading of assemblies and to save virtual address space, the CLR now loads assemblies by using only the Win32 MapViewOfFile function. It no longer also calls the LoadLibrary function. This change affects diagnostic applications in the following ways: A ProcessModuleCollection will no longer contain any modules from a class library (.dll file), as obtained from a call to Process.GetCurrentProcess().Modules. Win32 applications that use the EnumProcessModules function will not see all managed modules listed.	None.
Declaring type	The Type.DeclaringType property now correctly returns null when the type does not have a declaring type.	None.
Delegates	A delegate now throws an ArgumentNullException instead of a NullReferenceException when a null value is passed to the delegate's constructor.	Ensure that any exception handling catches ArgumentNullException.
Global assembly cache location change	For .NET Framework 4 assemblies, the global assembly cache has been moved from the Windows directory (%WINDIR%) to the Microsoft.Net subdirectory (%WINDIR%\Microsoft.Net). Assemblies from earlier versions remain in the older directory. The unmanaged ASM_CACHE_FLAGS enumeration contains the new ASM_CACHE_ROOT_EX flag. This flag gets the cache location for .NET Framework 4 assemblies, which can be obtained by the GetCachePath function.	None, assuming that applications do not use explicit paths to assemblies, which is not a recommended practice.
Global assembly cache tool	The Gacutil.exe (Global Assembly Cache Tool) no longer supports the shell plugin viewer.	None.

Interoperability

Namespace: System.Runtime.InteropServices; assembly: mscorlib (in mscorlib.dll)

Feature	Differences from 3.5 SP1	Recommended changes
Buffer length (unmanaged API)	To save memory, the functionality for the pBufferLengthOffset parameter for the ICorProfilerInfo2::GetStringLayout method has been changed to match the pStringLengthOffset parameter. Both parameters now point to the offset location of the string's length. Buffer length has been removed from the representation of the string class.	Remove any dependency on the buffer length.
JIT debugging	To simplify registration for just-in-time (JIT) debugging, the .NET Framework debugger now uses only the AeDebug registry key, which controls the JIT debugging behavior for native code. This change results in the following: You can no longer register two different debuggers for managed and native code. You can no longer start the debugger automatically for a non-interactive process, but you can prompt the user for an interactive process. You are no longer notified when the debugger fails to start, or when there is no registered debugger that should be started. Auto-launch policies that depend on the interactivity of the application are no longer supported.	Adjust debugging operations as required.
Platform invoke	To improve performance in interoperability with unmanaged code, incorrect calling conventions in a platform invoke now cause the application to fail. In previous versions, the marshaling layer resolved these errors up the stack.	Debugging your applications in Microsoft Visual Studio 2010 will alert you to these errors so you can correct them. If you have binaries that cannot be updated, you can include the <NetFx40_PInvokeStackResilience> element in your application's configuration file to enable calling errors to be resolved up the stack as in earlier versions. However, this may affect the performance of your application.
Removed interfaces (unmanaged API)	To avoid developer confusion, the following interfaces were removed, because they did not provide any useful run-time scenarios, and the CLR did not provide or accept any implementations: INativeImageINativeImageDependency INativeImageInstallInfo INativeImageEvaluate INativeImageConverter ICorModule IMetaDataConverter	None.

Data

This section describes migration issues for using data sets and SQL clients, the Entity Framework, LINQ to SQL, and WCF Data Servers (formerly known as ADO.NET Data Services).