.NET Framework 4 마이그레이션 문제.NET Framework 4 migration issues

이 항목에서는 수정, 표준 준수 및 보안에 대한 변경 내용, 고객 피드백 기반의 변경 내용을 포함하여 .NET Framework 버전 3.5 서비스 팩 1과 .NET Framework 버전 4 간의 마이그레이션 문제에 대해 설명합니다.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:

이 항목의 문제에 대한 좀 더 간략한 개요는 .NET Framework 4 마이그레이션 가이드를 참조하세요.For an higher-level overview of the issues in this topic, see the Migration Guide to the .NET Framework 4.

새로운 기능에 대한 자세한 내용은 .NET Framework 4의 새로운 기능을 참조하세요.For information about new features, see What's New in the .NET Framework 4.

ASP.NET 및 웹ASP.NET and Web

네임스페이스: System.Web, System.Web.Mobile, System.Web.Security, System.Web.UI.WebControls; 어셈블리: System.Web(System.Web.dll의)Namespaces: System.Web, System.Web.Mobile, System.Web.Security, System.Web.UI.WebControls; assembly: System.Web (in System.Web.dll)

기능Feature 3.5 SP1과의 차이점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. Netscape Navigator와 같은 오래된 브라우저와 디바이스는 제거되었으며 Google Chrome 및 Apple iPhone과 같은 최신 브라우저와 디바이스가 추가되었습니다.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.

HttpBrowserCapabilities 개체(페이지의 Request.Browse 속성에 의해 노출됨)는 브라우저 정의 파일에 의해 구동됩니다.The HttpBrowserCapabilities object (which is exposed by the page's Request.Browse property) is driven by the browser definition files. 따라서 ASP.NET 4에서 이 개체의 속성에 액세스하여 반환되는 정보는 이전 버전의 ASP.NET에서 반환된 정보와 다를 수 있습니다.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\BrowsersWindows\Microsoft.NET\Framework\v2.0.50727\CONFIG\Browsers

ASP.NET 4의 해당 \CONFIG\Browsers 폴더에 파일을 복사합니다.Copy the files into the corresponding \CONFIG\Browsers folder for ASP.NET 4. 파일을 복사한 후 Aspnet_regbrowsers.exe 명령줄 도구를 실행합니다.After you copy the files, run the Aspnet_regbrowsers.exe command-line tool. 자세한 내용은 https://www.asp.net/mobile 웹 사이트를 참조하세요.For more information, see the https://www.asp.net/mobile Web site.
혼합된 버전의 ASP.NET에서 실행 중인 자식 애플리케이션Child applications running under mixed versions of ASP.NET 이전 버전의 ASP.NET을 실행하는 애플리케이션의 자식으로서 구성된 ASP.NET 4 애플리케이션은 구성 또는 컴파일 오류로 인해 시작하지 못할 수 있습니다.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. 발생하는 특정 오류는 애플리케이션이 IIS 6.0에서 실행되는지 아니면 IIS 7 또는 IIS 7.5에서 실행되는지에 따라 다릅니다.The specific error that occurs depends on whether the application runs under IIS 6.0, or under IIS 7 or IIS 7.5. 구성 시스템이 ASP.NET 4 애플리케이션을 올바르게 인식할 수 있도록 영향을 받는 애플리케이션의 구성 파일을 변경할 수 있습니다.You can make changes to the configuration files of the affected applications so that the configuration system correctly recognizes the ASP.NET 4 application. 반드시 수행해야 할 변경 내용에 대한 자세한 내용은 ASP.NET 웹 사이트에 있는 ASP.NET 4 Breaking Changes(ASP.NET 4 주요 변경 내용) 문서의 “ASP.NET 4 Child Applications Fail to Start When Under ASP.NET 2.0 or ASP.NET 3.5 Applications”(ASP.NET 4 자식 애플리케이션이 ASP.NET 2.0 또는 ASP.NET 3.5 애플리케이션에서 시작되지 않음) 섹션을 참조하세요.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 변경 내용ClientID changes ASP.NET 4의 새로운 clientIDMode 설정을 통해 ASP.NET이 HTML 요소에 대해 id 특성을 생성하는 방법을 지정할 수 있습니다.The new clientIDMode setting in ASP.NET 4 lets you specify how ASP.NET generates the id attribute for HTML elements. ASP.NET의 이전 버전에서는 기본 동작이 clientIDModeAutoID 설정과 동일합니다.In previous versions of ASP.NET, the default behavior was equivalent to the AutoID setting of clientIDMode. 이제 기본 설정은 Predictable입니다.The default setting is now Predictable. 자세한 내용은 ASP.NET 웹 서버 컨트롤 식별을 참조하세요.For more information, see ASP.NET Web Server Control Identification. Visual Studio를 사용하여 ASP.NET 2.0 또는 ASP.NET 3.5에서 애플리케이션을 업그레이드하는 경우, .NET Framework 이전 버전의 동작을 유지하는 Web.config 파일에 설정이 자동으로 추가됩니다.If you use Visual Studio 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. 그러나 .NET Framework 4를 대상으로 하도록 IIS에서 애플리케이션 풀을 변경하여 애플리케이션을 업그레이드하는 경우 ASP.NET은 기본적으로 새 모드를 사용합니다.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. 새 클라이언트 ID 모드를 사용하지 않으려면 Web.config 파일에 다음 설정을 추가하세요.To disable the new client ID mode, add the following setting to the Web.config file:

<pages clientIDMode="AutoID" />
CAS(코드 액세스 보안)Code access security (CAS) ASP.NET 3.5에 추가된 ASP.NET 2.0 NET 기능은 .NET Framework 1.1 및 .NET Framework 2.0 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. 그러나 ASP.NET 4의 CAS 구현은 크게 개선되었습니다.However, the implementation of CAS in ASP.NET 4 has been substantially overhauled. 따라서 전역 어셈블리 캐시에서 실행되는 신뢰할 수 있는 코드를 사용하는 부분 신뢰 ASP.NET 애플리케이션은 다양한 보안 예외와 함께 실패할 수 있습니다.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. 컴퓨터 CAS 정책에 대한 광범위한 수정에 의존하는 부분 신뢰 애플리케이션도 실패하고 보안 예외를 throw할 수 있습니다.Partial-trust applications that rely on extensive modifications to machine CAS policy might also fail and throw security exceptions. 다음 예제와 같이 trust 구성 요소에서 새 legacyCasModel 특성을 사용하여 부분 신뢰 ASP.NET 4 애플리케이션을 ASP.NET 1.1 및 2.0의 동작으로 되돌릴 수 있습니다.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" />

중요: 이전 CAS 모델로 되돌리면 보안이 약화될 수 있습니다.Important: Reverting to the older CAS model might represent reduced security.

새로운 ASP.NET 4 코드 액세스 보안 모델에 대한 자세한 내용은 ASP.NET 4 애플리케이션의 코드 액세스 보안을 참조하세요.For more information about the new ASP.NET 4 code access security model, see Code Access Security in ASP.NET 4 Applications.
구성 파일Configuration files .NET Framework 및 ASP.NET 4의 루트 구성 파일(machine.config 파일 및 루트 Web.config 파일)은 ASP.NET 3.5의 애플리케이션 Web.config 파일에 있는 대부분의 상용구 구성 정보를 포함하도록 업데이트되었습니다.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. 관리되는 IIS 7 및 IIS 7.5 구성 시스템의 복잡성 때문에 ASP.NET 4, IIS 7 및 IIS 7.5에서 ASP.NET 3.5 애플리케이션을 실행하면 ASP.NET 오류 또는 IIS 오류가 발생할 수 있습니다.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. Visual Studio의 프로젝트 업그레이드 도구를 사용하여 ASP.NET 3.5 애플리케이션을 ASP.NET 4로 업그레이드하세요.Upgrade ASP.NET 3.5 applications to ASP.NET 4 by using the project upgrade tools in Visual Studio. Visual Studio 2010은 ASP.NET 3.5 애플리케이션의 Web.config 파일을 자동으로 수정하여 ASP.NET 4에 대한 적절한 설정을 포함합니다.Visual Studio 2010 automatically modifies the ASP.NET 3.5 application's Web.config file to contain the appropriate settings for ASP.NET 4.

그러나 다시 컴파일하지 않고 .NET Framework 4를 사용하여 ASP.NET 3.5 애플리케이션을 실행할 수 있습니다.However, you can run ASP.NET 3.5 applications using the .NET Framework 4 without recompilation. 이 경우 .NET Framework 4 및 IIS 7 또는 IIS 7.5에서 애플리케이션을 실행하기 전에 애플리케이션의 Web.config 파일을 수동으로 수정해야 할 수 있습니다.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. 반드시 변경해야 하는 구체적인 내용은 SP(서비스 팩) 릴리스를 비롯하여 작업 중인 소프트웨어의 조합에 따라 다릅니다.The specific change you must make depends on the combination of software you are working with, including Service Pack (SP) releases. 이 변경으로 인해 영향을 받을 수 있는 소프트웨어 조합 및 특정 조합의 문제를 해결하는 방법에 대한 자세한 내용은 ASP.NET 웹 사이트에 있는 ASP.NET 4 Breaking Changes(ASP.NET 4 주요 변경 내용) 문서의 “Configuration Errors Related to New ASP.NET 4 Root Configuration”(새 ASP.NET 4 루트 구성과 관련된 구성 오류) 섹션을 참조하세요.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 이전 버전의 ASP.NET에서는 일부 컨트롤에서 비활성화할 수 없는 태그를 내보냈습니다.In previous versions of ASP.NET, some controls emitted markup that you could not disable. 기본적으로 이 형식의 태그는 ASP.NET 4에서 더 이상 생성되지 않습니다.By default, this type of markup is no longer generated in ASP.NET 4. 이러한 렌더링 변경은 다음 컨트롤에 영향을 줍니다.The rendering changes affect the following controls:

* ImageImageButton 컨트롤은 더 이상 border="0" 특성을 렌더링하지 않습니다.* The Image and ImageButton controls no longer render a border="0" attribute.
* BaseValidator 클래스와 그로부터 파생된 유효성 검사 컨트롤은 더 이상 기본적으로 빨간색 텍스트를 렌더링하지 않습니다.* The BaseValidator class and validation controls that derive from it no longer render red text by default.
* HtmlForm 컨트롤은 name 특성을 렌더링하지 않습니다.* The HtmlForm control does not render a name attribute.
* Table 컨트롤이 더 이상 border="0" 특성을 렌더링하지 않습니다.* The Table control no longer renders a border="0" attribute.

사용자 입력용으로 디자인되지 않은 컨트롤(예: Label 컨트롤)은 Enabled 속성이 false로 설정된 경우(또는 컨테이너 컨트롤에서 이 설정을 상속하는 경우) 더 이상 disabled="disabled" 특성을 렌더링하지 않습니다.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).
Visual Studio를 사용하여 ASP.NET 2.0 또는 ASP.NET 3.5에서 애플리케이션을 업그레이드하는 경우, 레거시 렌더링을 유지하는 Web.config 파일에 설정이 자동으로 추가됩니다.If you use Visual Studio 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. 그러나 .NET Framework 4를 대상으로 하도록 IIS에서 애플리케이션 풀을 변경하여 애플리케이션을 업그레이드하는 경우 ASP.NET은 기본적으로 새 렌더링 모드를 사용합니다.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. 새 렌더링 모드를 사용하지 않으려면 Web.config 파일에 다음 설정을 추가하세요.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는 기본 문서가 매핑된 확장명 없는 URL에 대한 요청이 있을 때 HTML form 요소의 action 특성 값을 빈 문자열로 렌더링합니다.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. 이전 버전의 ASP.NET에서는 http://contoso.com에 대한 요청이 결국 Default.aspx에 대한 요청이 되었습니다.In earlier releases of ASP.NET, a request to http://contoso.com would result in a request to Default.aspx. 이 문서에서 여는 form 태그는 다음 예제와 같이 렌더링됩니다.In that document, the opening form tag would be rendered as in the following example:

<form action="Default.aspx" />

ASP.NET 4에서는 http://contoso.com에 대한 요청이 결국 Default.aspx에 대한 요청이 되지만, ASP.NET에서는 이제 다음 예제와 같이 HTML 열기 form 태그를 렌더링합니다.In ASP.NET 4, a request to http://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="" />

action 특성이 빈 문자열이면 IIS DefaultDocumentModule 개체가 Default.aspx에 대한 자식 요청을 만듭니다.When the action attribute is an empty string, the IIS DefaultDocumentModule object creates a child request to Default.aspx. 대부분의 상황에서 이 자식 요청은 애플리케이션 코드에 대해 투명하며, Default.aspx 페이지는 정상적으로 실행됩니다.Under most conditions, this child request is transparent to application code, and the Default.aspx page runs normally. 그러나 관리 코드와 IIS 7 또는 IIS 7.5 통합 모드 간의 잠재적 상호 작용으로 인해 관리되는 .aspx 페이지가 자식 요청 중에 제대로 작동하지 않을 수 있습니다.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. 다음 상황이 발생하면 기본 .aspx 문서에 대한 자식 요청으로 인해 오류가 발생하거나 예기치 않은 동작이 발생합니다.If the following conditions occur, the child request to a default .aspx document will result in an error or in unexpected behavior:

* form 요소의 action 특성이 ""로 설정된 상태로 .aspx 페이지가 브라우저로 전송됩니다.* An .aspx page is sent to the browser with the form element's action attribute set to "".
* 양식이 ASP.NET에 다시 게시됩니다.* The form is posted back to ASP.NET.
* 관리되는 HTTP 모듈은 Request.Form 또는 Request.Params 등 엔터티 본문의 일부를 읽습니다.* A managed HTTP module reads some part of the entity body, such as Request.Form or Request.Params. 이렇게 하면 POST 요청의 엔터티 본문이 관리되는 메모리로 읽힙니다.This causes the entity body of the POST request to be read into managed memory. 결과적으로 IIS 7 또는 IIS 7.5 통합 모드에서 실행 중인 모든 네이티브 코드 모듈에서 더 이상 엔터티 본문을 사용할 수 없습니다.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.
* IIS DefaultDocumentModule 개체가 결국 실행되어 Default.aspx 문서에 대한 자식 요청을 만듭니다.* 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.
* HTTP 파이프라인이 자식 요청에 대해 실행되면 .aspx 파일의 처리기가 처리기 실행 단계 중에 실행됩니다.* 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. 따라서 .aspx 페이지 처리기가 발생해야 하는 이벤트(있는 경우)를 결정하는 데 사용할 수 있는 정보가 없습니다.Therefore there is no information available for the .aspx page handler to determine what event (if any) should be raised. 그 결과, 영향을 받는 .aspx 페이지의 포스트백 이벤트 처리기는 실행되지 않습니다.As a result, none of the postback event handlers for the affected .aspx page run.
이 변경의 결과 발생할 수 있는 문제를 해결하는 방법에 대한 자세한 내용은 ASP.NET 웹 사이트에 있는 ASP.NET 4 Breaking Changes(ASP.NET 4 주요 변경 내용) 문서의 “Event Handlers Might Not Be Not Raised in a Default Document in IIS 7 or IIS 7.5 Integrated Mode”(IIS 7 또는 IIS 7.5 통합 모드의 기본 문서에서 이벤트 처리기가 작동하지 않을 수 있음) 섹션을 참조하세요.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은 암호화 및 해시 알고리즘을 모두 사용하여 양식 인증 쿠키 및 보기 상태와 같은 데이터를 보호합니다.ASP.NET uses both encryption and hashing algorithms to help secure data such as forms authentication cookies and view state. 기본적으로 ASP.NET 4는 쿠키 및 보기 상태의 해시 작업에 HMACSHA256 알고리즘을 사용합니다.By default, ASP.NET 4 uses the HMACSHA256 algorithm for hash operations on cookies and view state. 이전 버전의 ASP.NET에서는 이전 HMACSHA1 알고리즘을 사용했습니다.Earlier versions of ASP.NET used the older HMACSHA1 algorithm. 양식 인증 쿠키와 같은 데이터가 .NET Framework 버전 전체에서 작동해야 하는, ASP.NET 2.0 및 ASP.NET 4가 혼합된 애플리케이션을 실행하는 경우, Web.config 파일에서 다음 설정을 추가하여 ASP.NET 4 웹 애플리케이션이 이전 HMACSHA1 알고리즘을 사용하도록 구성하세요.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" />
Internet Explorer의 컨트롤 호스팅Hosting controls in Internet Explorer 웹에 컨트롤을 호스트하는 더 나은 솔루션이 있기 때문에 더 이상 Internet Explorer에서 Windows Forms 컨트롤을 호스트할 수 없습니다.You can no longer host Windows Forms controls in the Internet Explorer, because there are better solutions for hosting controls on the Web. 따라서 IEHost.dll 및 IEExec.exe 어셈블리는 .NET Framework에서 제거되었습니다.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:

* Silverlight 애플리케이션을 만들고 브라우저 외부에서 실행되도록 구성할 수 있습니다.* You can create a Silverlight application and configure it to run outside the browser. 자세한 내용은 브라우저 외부에서 실행 지원을 참조하세요.For more information, see Out-of-Browser Support.
* XBAP(XAML 브라우저 애플리케이션)를 빌드하여 WPF 기능을 활용할 수 있습니다(클라이언트 컴퓨터에 .NET Framework 필요).* You can build a XAML browser application (XBAP) to take advantage of WPF capabilities (requires the .NET Framework on client machines). 자세한 내용은 WPF XAML 브라우저 애플리케이션 개요를 참조하세요.For more information, see WPF XAML Browser Applications Overview.
HtmlEncode 및 UrlEncode 메서드HtmlEncode and UrlEncode methods HttpUtilityHttpServerUtility 클래스의 HtmlEncodeUrlEncode 메서드가 다음과 같이 작은따옴표 문자(')를 인코딩하도록 업데이트되었습니다.The HtmlEncode and UrlEncode methods of the HttpUtility and HttpServerUtility classes have been updated to encode the single quotation mark character (') as follows:

* HtmlEncode 메서드는 작은따옴표의 인스턴스를 &#39;으로 인코딩합니다.* The HtmlEncode method encodes instances of the single quotation mark as &#39;
* UrlEncode 메서드는 작은따옴표의 인스턴스를 %27로 인코딩합니다.* The UrlEncode method encodes instances of the single quotation mark as %27
HtmlEncodeUrlEncode 메서드를 사용하는 장소에 대한 코드를 검사하고 인코딩의 변경으로 인해 애플리케이션에 영향을 주는 변경이 발생하지 않는지 확인하세요.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.
ASP.NET 2.0 애플리케이션의 HttpException 오류HttpException errors in ASP.NET 2.0 applications IIS 6에서 ASP.NET 4를 사용하도록 설정한 경우 IIS 6(Windows Server 2003 또는 Windows Server 2003 R2)에서 실행되는 ASP.NET 2.0 애플리케이션에서 다음과 같은 오류가 발생할 수 있습니다. System.Web.HttpException: Path '/[yourApplicationRoot]/eurl.axd/[Value]' was not found.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. * 웹 사이트를 실행하기 위해 ASP.NET 4가 필요하지 않은 경우 대신 ASP.NET 2.0을 사용하도록 사이트를 다시 매핑합니다.* 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-

* 웹 사이트를 실행하기 위해 ASP.NET 4가 필요한 경우 자식 ASP.NET 2.0 가상 디렉터리를 ASP.NET 2.0에 매핑된 다른 웹 사이트로 이동합니다.* 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-

* 확장명 없는 URL을 사용하지 않도록 설정하세요.* Disable extensionless URLs. 자세한 내용은 ASP.NET 웹 사이트에 있는 ASP.NET 4 Breaking Changes(ASP.NET 4 주요 변경 내용) 문서의 “ASP.NET 2.0 Applications Might Generate HttpException Errors That Reference eurl.axd”(ASP.NET 2.0 애플리케이션이 eurl.axd를 참조하는 HttpException 오류를 생성할 수 있음)를 참조하세요.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 ASP.NET 멤버 자격에서 사용되는 일부 형식(예: MembershipProvider)이 System.Web.dll에서 System.Web.ApplicationServices.dll 어셈블리로 이동했습니다.Some types (for example, MembershipProvider) that are used in ASP.NET membership have been moved from System.Web.dll to the System.Web.ApplicationServices.dll assembly. 클라이언트 형식 및 확장된 .NET Framework SKU 형식 간 아키텍처 계층화 종속성을 해결하기 위해 형식을 이동했습니다.The types were moved in order to resolve architectural layering dependencies between types in the client and in extended .NET Framework SKUs. ASP.NET의 이전 버전에서 업그레이드되었고 이동된 멤버 자격 유형을 사용하는 클래스 라이브러리는 ASP.NET 4 프로젝트에서 사용될 때 컴파일되지 않을 수 있습니다.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. 이 경우 클래스 라이브러리 프로젝트의 참조를 System.Web.ApplicationServices.dll에 추가하세요.If so, add a reference in the class library project to System.Web.ApplicationServices.dll.
메뉴 컨트롤 변경Menu control changes Menu 컨트롤을 변경하면 다음과 같은 동작이 발생합니다.Changes to the Menu control result in the following behavior:

* MenuRenderingModeList로 설정되거나 MenuRenderingModeDefault로 설정되고 ControlRenderingCompatibilityVersion4.0 이상으로 설정된 경우 PopOutImageUrl 속성은 아무런 효과도 없습니다.* If MenuRenderingMode is set to List, or if MenuRenderingMode is set to Default and ControlRenderingCompatibilityVersion is set to 4.0 or later, the PopOutImageUrl property has no effect.
* StaticPopOutImageUrlDynamicPopOutImageUrl 속성에 설정된 경로에 백슬래시(\)가 포함되어 있으면 이미지가 렌더링되지 않습니다.* If the path that is set in the StaticPopOutImageUrl and DynamicPopOutImageUrl properties contains a backslash (\), the images do not render. (ASP.NET의 이전 버전에서는 경로에 백슬래시를 포함할 수 있었습니다.)(In earlier versions of ASP.NET, the path could include a backslash.)
* 개별 메뉴 항목의 PopOutImageUrl 속성을 설정하는 대신 부모 Menu 컨트롤의 StaticPopOutImageUrl 또는 DynamicPopOutImageUrl을 설정하세요.* Instead of setting the PopOutImageUrl property for individual menu items, set the StaticPopOutImageUrl or DynamicPopOutImageUrl of the parent Menu control.

또는-or-

MenuRenderingModeTable, MenuRenderingModeDefault, ControlRenderingCompatibilityVersion3.5로 설정하세요.Set MenuRenderingMode to Table, or set MenuRenderingMode to Default and set ControlRenderingCompatibilityVersion to 3.5. 이렇게 설정하면 Menu 컨트롤이 이전 버전의 ASP.NET에서 사용한 HTML 테이블 기반 레이아웃을 사용하게 합니다.These settings cause the Menu control to use the HTML table-based layout that it used in earlier versions of ASP.NET.
* StaticPopOutImageUrl 또는 DynamicPopOutImageUrl 속성의 경로에 백슬래시(\)가 포함되어 있으면 슬래시 문자(/)를 대체하세요.* If the path in the StaticPopOutImageUrl or DynamicPopOutImageUrl property contains a backslash (\), substitute a slash character (/).
Web.config 파일의 모바일 어셈블리Mobile assembly in Web.config file ASP.NET의 이전 버전에서는 System.Web.Mobile.dll 어셈블리에 대한 참조가 system.web/compilationassemblies 섹션에 있는 루트 Web.config 파일에 포함되었습니다.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.

참고: System.Web.Mobile.dll 어셈블리 및 ASP.NET 모바일 컨트롤은 ASP.NET 4에 포함되지만 사용되지는 않습니다.Note: The System.Web.Mobile.dll assembly and the ASP.NET mobile controls are included in ASP.NET 4, but they are deprecated.
이 어셈블리의 형식을 사용하려면 루트 Web.config 파일 또는 애플리케이션 Web.config 파일의 어셈블리에 대한 참조를 추가하세요.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 ASP.NET 1.0에서는 Location="ServerAndClient"를 출력 캐시 설정으로 지정한 캐시된 페이지가 응답에서 Vary:* HTTP 헤더를 내보내는 버그가 있었습니다.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. ASP.NET 1.1에서는 Vary:* 헤더를 억제하기 위해 호출할 수 있는 SetOmitVaryStar 메서드가 추가되었습니다.In ASP.NET 1.1, the SetOmitVaryStar method was added, which could be called in order to suppress the Vary:* header. 그러나 버그 보고서에 따르면 개발자는 기존의 SetOmitVaryStar 동작을 인식하지 못합니다.However, bug reports suggest that developers are unaware of the existing SetOmitVaryStar behavior.

ASP.NET 4에서는 다음 지시문을 지정하는 응답에서 더 이상 Vary:* HTTP 헤더를 내보내지 않습니다.In ASP.NET 4, the Vary:* HTTP header is no longer emitted from responses that specify the following directive:

<%@ OutputCache Location="ServerAndClient" %>

결과적으로 Vary:* 헤더를 억제하기 위해 SetOmitVaryStar 메서드가 더 이상 필요하지 않습니다.As a result, the SetOmitVaryStar method is no longer needed in order to suppress the Vary:* header. Location 특성에 대해 “ServerAndClient”를 지정하는 애플리케이션에서는 SetOmitVaryStar를 호출할 필요 없이 브라우저에서 페이지를 캐시할 수 있습니다.In applications that specify "ServerAndClient" for the Location attribute, pages will be cacheable in the browser without requiring that you call SetOmitVaryStar.
애플리케이션의 페이지가 Vary:*을 내보내야 하는 경우 다음 예제와 같이 AppendHeader 메서드를 호출합니다.If pages in the application must emit Vary:*, call the AppendHeader method as shown in the following example:

System.Web.HttpResponse.AppendHeader("Vary","*");

또는 출력 캐싱 Location 특성의 값을 “Server”로 변경할 수 있습니다.Alternatively, you can change the value of the output caching Location attribute to "Server".
페이지 구문 분석Page parsing ASP.NET 웹 페이지(.aspx 파일) 및 사용자 컨트롤(.ascx 파일)의 페이지 파서는 이전 버전의 ASP.NET보다 ASP.NET 4에서 더 엄격하며, 이전 버전보다 더 많은 태그를 잘못된 것으로 표시합니다.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 형식Passport types ASP.NET 2.0에 내장된 Passport 지원은 사용되지 않으며 Passport(이제 Live ID SDK)의 변경으로 인해 지원되지 않습니다.The Passport support built into ASP.NET 2.0 is obsolete and is unsupported due to changes in Passport (now Live ID SDK). 그 결과 System.Web.Security의 Passport와 관련된 형식이 이제 ObsoleteAttribute 특성으로 표시됩니다.As a result, the types related to Passport in System.Web.Security are now marked with the ObsoleteAttribute attribute. System.Web.Security 네임스페이스(예: PassportIdentity)에서 Passport 형식을 사용하는 코드를 SDK를 사용하도록 변경하세요.Change any code you have that uses Passport types in the System.Web.Security namespace (for example, PassportIdentity) to use the SDK.
FilePath 속성의 PathInfo 정보PathInfo information in the FilePath property ASP.NET 4는 FilePath, AppRelativeCurrentExecutionFilePath, CurrentExecutionFilePath와 같은 속성의 반환 값에 더 이상 PathInfo 값을 포함하지 않습니다.ASP.NET 4 no longer includes the PathInfo value in the return values from properties such as FilePath, AppRelativeCurrentExecutionFilePath, and CurrentExecutionFilePath. 대신, PathInfo 정보를 PathInfo에서 사용할 수 있습니다.Instead, the PathInfo information is available in PathInfo. 예를 들어 다음과 같은 URL 조각을 가정해 보겠습니다.For example, imagine the following URL fragment:

/testapp/Action.mvc/SomeAction

이전 버전의 ASP.NET에서 HttpRequest 속성은 다음과 같은 값을 갖습니다.In earlier versions of ASP.NET, HttpRequest properties have the following values:

* FilePath: /testapp/Action.mvc/SomeAction* FilePath: /testapp/Action.mvc/SomeAction
* PathInfo: (empty)* PathInfo: (empty)

ASP.NET 4에서 HttpRequest 속성은 대신 다음과 같은 값을 갖습니다.In ASP.NET 4, HttpRequest properties instead have the following values:

* FilePath: /testapp/Action.mvc* FilePath: /testapp/Action.mvc
* PathInfo: SomeAction* PathInfo: SomeAction
경로 정보를 반환하기 위해 HttpRequest 클래스의 속성에 의존하는 위치에 대한 코드를 검사하세요. 경로 정보가 반환되는 방식의 변화를 반영하도록 코드를 변경하세요.Examine your code for places where you rely on properties of the HttpRequest class to return path information; change the code to reflect the changes in how path information is returned.
요청 유효성 검사Request validation 요청 유효성 검사를 향상하기 위해, 요청 수명 주기의 초기에 ASP.NET 요청 유효성 검사가 호출됩니다.To improve request validation, the ASP.NET request validation is invoked earlier in the request life cycle. 따라서 웹 서비스 호출 및 사용자 지정 처리기 등 .aspx 파일 이외의 요청에 대해서는 요청 유효성 검사가 실행됩니다.As a result, request validation runs for requests that are not for .aspx files, such as for Web service calls and for custom handlers. 또한 요청 처리 파이프라인에서 사용자 지정 HTTP 모듈이 실행 중일 때 요청 유효성 검사가 활성화됩니다.Request validation will also be active when custom HTTP modules are running in the request processing pipeline.

이러한 변경 결과로 .aspx 파일 이외의 리소스에 대한 요청은 요청 유효성 검사 오류를 throw할 수 있습니다.As a result of this change, requests for resources other than .aspx files might throw request validation errors. 요청 파이프라인(예: 사용자 지정 HTTP 모듈)에서 실행되는 사용자 지정 코드는 요청 유효성 검사 오류를 throw할 수 있습니다.Custom code that runs in the request pipeline (for example, custom HTTP modules) might also throw request validation errors.
필요한 경우 웹 구성 파일에서 다음 설정을 사용하여 요청 유효성 검사를 트리거하는 .aspx 페이지만 이전 동작으로 되돌릴 수 있습니다.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" />

경고: 이전 동작으로 되돌리는 경우 기존 처리기, 모듈 및 기타 사용자 지정 코드의 모든 코드가 XSS 공격 벡터일 수 있는, 잠재적으로 안전하지 않은 HTTP 입력에 대한 검사를 수행해야 합니다.Warning: 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 Visual Studio 2010에서 파일 시스템 웹 사이트를 만든 경우 이름에 점(.)이 포함된 폴더에 웹 사이트가 있으면 URL 라우팅이 안정적으로 작동하지 않습니다.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. 일부 가상 경로에서 HTTP 404 오류가 반환됩니다.An HTTP 404 error is returned from some virtual paths. 이 오류는 Visual Studio 2010이 루트 가상 디렉터리의 잘못된 경로를 사용하여 Visual Studio 개발 서버를 시작하기 때문에 발생합니다.This occurs because Visual Studio 2010 launches the Visual Studio Development Server 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. 웹 애플리케이션 프로젝트에는 이 문제가 없으며, 프로젝트 폴더의 이름에 점이 있는 경우에도 URL 라우팅이 작동합니다.Web application projects do not have this issue, and URL routing works even if the project folder has a dot in its name.

또는-or-

* IIS에서 호스트되는 HTTP 기반 웹 사이트를 만드세요.* Create an HTTP-based Web site that is hosted in IIS. IIS에서 호스트하는 웹 사이트는 가상 경로는 물론 프로젝트 파일 폴더에도 점을 포함할 수 있습니다.IIS-hosted Web sites can have dots in the virtual path as well as in the project file folder.
SharePoint 사이트SharePoint sites WSS_Minimal이라는 사용자 지정 부분 신뢰 수준이 포함된 SharePoint 웹 사이트의 자식으로 배포된 ASP.NET 4 웹 사이트를 실행하려고 하면 다음 오류가 표시됩니다.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'.
지금은 ASP.NET과 호환되는 SharePoint 버전이 없습니다.Currently, no versions of SharePoint are compatible with ASP.NET. 따라서 ASP.NET 4 웹 사이트를 SharePoint 웹 사이트의 자식으로 실행해서는 안 됩니다.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 표준XHTML 1.1 standards 새로운 웹 사이트에 XHTML 1.1 규격을 사용하기 위해 .NET Framework 4의 ASP.NET 컨트롤은 XHTML 1.1 규격 HTML을 생성합니다.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. <system.Web> 요소 내부의 Web.config 파일에서 다음 옵션을 사용하여 이 렌더링을 사용하도록 설정할 수 있습니다.This rendering is enabled using the following option in the Web.config file inside the <system.Web> element:

<pages controlRenderingCompatibilityVersion="4.0"/>

이 옵션은 기본적으로 4.0으로 설정됩니다.This option is set by default to 4.0. Visual Studio 2008에서 업그레이드되는 웹 프로젝트는 호환성을 위해 3.5 설정을 사용합니다.Web projects that are upgraded from Visual Studio 2008 have the 3.5 setting enabled for compatibility.
없음None.

코어Core

일반 기능General features

기능Feature 3.5 SP1과의 차이점Differences from 3.5 SP1 권장 변경 내용Recommended changes
CardSpaceCardSpace Windows CardSpace는 이제 .NET Framework에 포함되지 않으며 별도로 제공됩니다.Windows CardSpace is no longer included in the .NET Framework; it is provided separately. Microsoft 다운로드 센터에서 Windows CardSpace를 다운로드하세요.Download Windows CardSpace from the Microsoft Download Center.
구성 파일Configuration files .NET Framework가 애플리케이션 구성 파일에 액세스하는 방법이 수정되었습니다.Corrections have been made in how the .NET Framework accesses application configuration files. 애플리케이션 구성 파일의 이름이 application-name.config인 경우 이름을 application-name.exe.config로 바꾸세요. 예를 들어 MyApp.configMyApp.exe.config로 바꿉니다.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# 코드 컴파일러C# code compiler Microsoft.CSharp 네임스페이스에 있던 Compiler, CompilerErrorErrorLevel 클래스는 더 이상 사용할 수 없으며 해당 어셈블리(cscompmgd.dll)는 .NET Framework에 더 이상 포함되지 않습니다.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. CodeDomProvider 클래스 및 System.CodeDom.Compiler 네임스페이스의 기타 클래스를 사용하세요.Use the CodeDomProvider class and other classes in the System.CodeDom.Compiler namespace. 자세한 내용은 CodeDOM 사용을 참조하세요.For more information, see Using the CodeDOM.
호스팅(관리되지 않는 API)Hosting (unmanaged API) 호스팅 기능의 향상을 위해 일부 호스팅 활성화 API가 사용되지 않습니다.To improve hosting capabilities, some of the hosting activation APIs have been deprecated. In-Process Side-by-Side 실행 기능을 통해 애플리케이션은 동일한 프로세스에서 여러 버전의 .NET Framework를 로드하고 시작할 수 있습니다.In-process side-by-side execution features enable an application to load and start multiple versions of the .NET Framework in the same process. 예를 들어 .NET Framework 2.0 SP1을 기반으로 하는 추가 기능(또는 구성 요소) 및 동일한 프로세스에서 .NET Framework 4를 기반으로 하는 추가 기능을 로드하는 애플리케이션을 실행할 수 있습니다.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. 이전 구성 요소는 이전 .NET Framework 버전을 계속 사용하고 새 구성 요소는 새 .NET Framework 버전을 사용합니다.Older components continue to use the older .NET Framework version, and new components use the new .NET Framework version. In-Process Side-by-Side 실행에 설명된 구성을 사용하세요.Use the configurations described in In-Process Side-by-Side Execution.
새 보안 모델New security model .NET Framework 4의 보안 변경 내용에 설명된 대로 CAS(코드 액세스 보안) 정책이 해제되어 단순화된 모델로 대체되었습니다.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. 애플리케이션에서 CAS를 사용하는 경우 수정이 필요할 수 있습니다.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

네임스페이스: System; 어셈블리: mscorlib(mscorlib.dll)Namespace: System; assembly: mscorlib (in mscorlib.dll)

기능Feature 3.5 SP1과의 차이점Differences from 3.5 SP1 권장 변경 내용Recommended changes
일광 절약Daylight savings 시스템 시계와의 일관성을 위해, 시간 속성(예: LocalNow)은 일광 절약 시간제 작업에 대해 다른 .NET Framework 데이터 대신 운영 체제 규칙을 사용합니다.To be consistent with the system clock, time properties (such as Local and Now) now use operating system rules instead of other .NET Framework data for daylight saving time operations. 없음None.
문자열 서식 지정Formatting strings 문화권에 민감한 서식을 지원하기 위해 새로운 ParseExactTryParseExact 메서드 외에도 ToString, ParseTryParse 메서드의 새로운 오버로드가 TimeSpan 구조에 포함됩니다.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.

네임스페이스: System.Globalization; 어셈블리: mscorlib(mscorlib.dll)Namespace: System.Globalization; assembly: mscorlib (in mscorlib.dll)

기능Feature 3.5 SP1과의 차이점Differences from 3.5 SP1 권장 변경 내용Recommended changes
문화권 이름Culture names 다음과 같은 이름 변경은 독일, 디베히 및 아프리카 문화권에 영향을 미칩니다.The following name changes affect the German, Divehi, and African cultures:

* CurrencyEnglishName: 독일어(스위스)(de-CH) 문화권의 통화 이름이 “sFr.”에서* CurrencyEnglishName: The currency name for the German (Switizerland) (de-CH) culture has changed from "sFr." “Fr.”로 변경되었습니다.to "Fr.".
* LongDatePattern: 디베히어(몰디브)(dv-MV) 문화권의 긴 날짜 패턴이 “dd/MMMM/yyyy”에서 “dd/MM/yyyy”로 변경되었습니다.* LongDatePattern: The long date pattern for the Divehi (Maldives) (dv-MV) culture has changed from "dd/MMMM/yyyy" to "dd/MM/yyyy".
* PMDesignator: 아프리카어(남아프리카)(af-ZA) 문화권의 P.M.* PMDesignator: The P.M. 지정자가 “nm”에서 “PM”으로 변경되었습니다.designator of the Afrikaans (South Africa) (af-ZA) culture has changed from "nm" to "PM".
문화권 이름이 변경됩니다.Note culture name changes.
LCID 매개 변수LCID parameter 자동화 서버 설정에서 예상되는 동작과의 일관성을 위해, CLR은 더 이상 LCID 매개 변수에 대한 현재 문화권을 관리되지 않는 COM 기반 애플리케이션에 전달하지 않습니다.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. 대신, 문화권에 1033(en-us)을 전달합니다.Instead, it passes 1033 (en-us) for the culture. 특정 문화권을 요구하는 기본 애플리케이션을 제외하고는 수정이 필요하지 않습니다.No modifications necessary except for native applications that require a specified culture.
사용되지 않는 문화권 형식Obsolete culture types CultureTypesCultureTypes 문화권 형식은 이제 사용되지 않습니다.The CultureTypes and CultureTypes culture types are now obsolete.

이전 버전과의 호환성을 위해 이제 CultureTypes는 이전 .NET Framework에 포함되었던 중립적인 특정 문화권을 반환하고, CultureTypes는 빈 목록을 반환합니다.For backward compatibility, CultureTypes now returns neutral and specific cultures that were included with the previous .NET Framework, and CultureTypes now returns an empty list.
CultureTypes 열거형의 다른 값을 사용하세요.Use other values of the CultureTypes enumeration.
문화권 검색Retrieving culture Windows 7부터 .NET Framework 4는 데이터 자체를 저장하는 대신 운영 체제에서 문화권 정보를 검색합니다.Beginning with Windows 7, the .NET Framework 4 retrieves culture information from the operating system instead of storing the data itself. 또한 .NET Framework는 데이터 정렬 및 대/소문자 처리를 위해 Windows와 동기화됩니다.In addition, the .NET Framework synchronizes with Windows for sorting and casing data. 없음None.
Unicode 5.1 표준Unicode 5.1 standards 이제 .NET Framework는 모든 유니코드 5.1 문자(약 1,400자 추가)를 지원합니다.The .NET Framework now supports all Unicode 5.1 characters -- an addition of approximately 1400 characters. 추가 문자에는 새로운 기호, 화살표, 분음 부호, 구두점, 수학 기호, CJK 스트로크 및 표의 문자, 추가 말라얄람어 및 텔루구어 숫자 문자, 다양한 미얀마어, 라틴어, 아랍어, 그리스어, 몽골어 및 키릴 문자가 포함됩니다.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. 유니코드 5.1에서는 다음 새 스크립트가 지원됩니다. 순다어, 렙차어, 올치키어, 바이어(Vai), 사우라슈트라어, 카야리어(Kayah Li), 레장어, 구르무키어, 오리야어, 타밀어, 텔구루어, 말라얌람어 문자 및 참어(Cham)입니다.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

네임스페이스: System, System.Runtime.ExceptionServices; 어셈블리: mscorlib(mscorlib.dll)Namespaces: System, System.Runtime.ExceptionServices; assembly: mscorlib (in mscorlib.dll)

기능Feature 3.5 SP1과의 차이점Differences from 3.5 SP1 권장 변경 내용Recommended changes
손상된 프로세스 상태에 대한 예외Exceptions for corrupted process state CLR은 더 이상 손상된 프로세스 상태에 대한 예외를 관리 코드의 예외 처리기로 전달하지 않습니다.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.

자세한 내용은 CLR 자세히 보기 블로그의 HandleProcessCorruptedStateExceptionsAttribute손상된 상태 예외 처리 항목을 참조하세요.For more information, see the HandleProcessCorruptedStateExceptionsAttribute and the entry Handling Corrupted State Exceptions in the CLR Inside Out blog.
실행 엔진 예외Execution engine exceptions catchable 예외로 인해 불안정한 프로세스가 계속 실행될 수 있으므로 ExecutionEngineException은 이제는 사용되지 않습니다.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. InvalidOperationException을 사용하여 조건을 알리세요.Use an InvalidOperationException to signal the condition.

반사Reflection

네임스페이스: System.Reflection; 어셈블리: mscorlib(mscorlib.dll)Namespace: System.Reflection; assembly: mscorlib (in mscorlib.dll)

기능Feature 3.5 SP1과의 차이점Differences from 3.5 SP1 권장 변경 내용Recommended changes
어셈블리 해시 알고리즘Assembly hash algorithms 어셈블리가 로드되지 않을 경우 런타임에서 참조된 어셈블리의 해시 알고리즘을 알지 못하기 때문에 HashAlgorithm 속성은 이제 AssemblyHashAlgorithm을 반환합니다.The HashAlgorithm property now returns AssemblyHashAlgorithm, because the runtime does not know the hash algorithm of the referenced assembly when the assembly is not loaded. 이는 GetReferencedAssemblies 메서드에 의해 반환된 것과 같이 참조된 어셈블리의 속성을 사용함을 의미합니다.(This refers to using the property on a referenced assembly such as that returned by the GetReferencedAssemblies method.) 없음None.
어셈블리 로딩Assembly loading 어셈블리의 중복 로드를 방지하고 가상 주소 공간을 절약하기 위해 이제 CLR은 Win32 MapViewOfFile 함수만 사용하여 어셈블리를 로드합니다.To prevent redundant loading of assemblies and to save virtual address space, the CLR now loads assemblies by using only the Win32 MapViewOfFile function. 또한 더 이상 LoadLibrary 함수를 호출하지 않습니다.It no longer also calls the LoadLibrary function.

이러한 변경은 진단 애플리케이션에 다음과 같은 방식으로 영향을 줍니다.This change affects diagnostic applications in the following ways:

* ProcessModuleCollection에는 Process.GetCurrentProcess().Modules에 대한 호출에서 가져온 클래스 라이브러리(.dll 파일)의 모듈이 더 이상 포함되지 않습니다.* A ProcessModuleCollection will no longer contain any modules from a class library (.dll file), as obtained from a call to Process.GetCurrentProcess().Modules.
EnumProcessModules 함수를 사용하는 Win32 애플리케이션은 나열된 관리되는 모듈을 모두 볼 수는 없습니다.* Win32 applications that use the EnumProcessModules function will not see all managed modules listed.
없음None.
선언 형식Declaring type 형식에 선언 형식이 없으면 이제 DeclaringType 속성이 올바르게 null을 반환합니다.The DeclaringType property now correctly returns null when the type does not have a declaring type. 없음None.
대리자Delegates 대리자의 생성자에 null 값이 전달되면 이제 대리자가 NullReferenceException 대신 ArgumentNullException을 throw합니다.A delegate now throws an ArgumentNullException instead of a NullReferenceException when a null value is passed to the delegate's constructor. 예외 처리가 ArgumentNullException을 catch하는지 확인하세요.Ensure that any exception handling catches ArgumentNullException.
전역 어셈블리 캐시 위치 변경Global assembly cache location change .NET Framework 4 어셈블리의 경우 전역 어셈블리 캐시가 Windows 디렉터리(%WINDIR%)에서 Microsoft.Net 하위 디렉터리( %WINDIR%\Microsoft.Net)로 이동했습니다.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.

관리되지 않는 ASM_CACHE_FLAGS 열거형에 새 ASM_CACHE_ROOT_EX 플래그가 포함됩니다.The unmanaged ASM_CACHE_FLAGS enumeration contains the new ASM_CACHE_ROOT_EX flag. 이 플래그는 GetCachePath 함수로 얻을 수 있는 .NET Framework 4 어셈블리의 캐시 위치를 가져옵니다.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 Gacutil.exe(전역 어셈블리 캐시 도구)는 더 이상 셸 플러그 인 뷰어를 지원하지 않습니다.The Gacutil.exe (Global Assembly Cache Tool) no longer supports the shell plugin viewer. 없음None.

상호 운용성Interoperability

네임스페이스: System.Runtime.InteropServices; 어셈블리: mscorlib(mscorlib.dll)Namespace: System.Runtime.InteropServices; assembly: mscorlib (in mscorlib.dll)

기능Feature 3.5 SP1과의 차이점Differences from 3.5 SP1 권장 변경 내용Recommended changes
버퍼 길이(관리되지 않는 API)Buffer length (unmanaged API) 메모리를 절약하기 위해 ICorProfilerInfo2::GetStringLayout 메서드에 대한 pBufferLengthOffset 매개 변수의 기능이 pStringLengthOffset 매개 변수와 일치하도록 변경되었습니다.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 디버깅JIT debugging JIT(Just-In-Time) 디버깅에 대한 등록을 단순화하기 위해 .NET Framework 디버거는 이제 네이티브 코드의 JIT 디버깅 동작을 제어하는 AeDebug 레지스트리 키만 사용합니다.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. Microsoft Visual Studio에서 애플리케이션을 디버그하면 이러한 오류를 알려주므로 수정할 수 있습니다.Debugging your applications in Microsoft Visual Studio alerts you to these errors so you can correct them.

업데이트할 수 없는 이진 파일이 있는 경우 애플리케이션의 구성 파일에 <NetFx40_PInvokeStackResilience> 요소를 포함하면 이전 버전과 마찬가지로 스택 위에서 호출 오류를 해결할 수 있습니다.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.
제거된 인터페이스(관리되지 않는 API)Removed interfaces (unmanaged API) 개발자에게 혼란을 주지 않도록 다음 인터페이스가 제거되었습니다. 이러한 인터페이스는 유용한 런타임 시나리오를 제공하지 않았고 CLR이 구현을 제공하거나 수락하지 않았기 때문입니다.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* INativeImageINativeImageDependency
* INativeImageInstallInfo* INativeImageInstallInfo
* INativeImageEvaluate* INativeImageEvaluate
* INativeImageConverter* INativeImageConverter
* ICorModule* ICorModule
* IMetaDataConverter* IMetaDataConverter
없음None.

데이터Data

이 섹션에서는 데이터 집합 및 SQL 클라이언트, Entity Framework, LINQ to SQL, WCF Data Services(이전의 ADO.NET Data Services) 사용에 대한 마이그레이션 문제를 설명합니다.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).

데이터 세트 및 SQL 클라이언트DataSet and SQL Client

다음 표에서는 이전에 제한 사항이었거나 기타 문제가 있던 기능의 개선 내용을 설명합니다.The following table describes improvements to features that previously had limitations or other issues.

네임스페이스: System.Data, System.Data.Objects.DataClasses, System.Data.SqlClient; 어셈블리: System.Data(System.Data.dll의), System.Data.Entity(System.Data.Entity.dll의)Namespaces: System.Data, System.Data.Objects.DataClasses, System.Data.SqlClient; assemblies: System.Data (in System.Data.dll), System.Data.Entity (in System.Data.Entity.dll)

기능Feature 3.5 SP1과의 차이점Differences from 3.5 SP1
POCO 시나리오POCO Scenarios IRelatedEnd 인터페이스에는 POCO(Plain Old CLR Object) 시나리오의 유용성을 개선하기 위한 새로운 방법이 있습니다.The IRelatedEnd interface has new methods to improve its usability in Plain Old CLR Object (POCO) scenarios. 이 새로운 메서드는 매개 변수로 IEntityWithRelationships 엔터티 대신 Object를 사용합니다.These new methods take an Object instead of an IEntityWithRelationships entity as a parameter.
행 편집Editing Rows DataView 클래스에 의해 구현된 IndexOf 메서드는 이제 -1을 반환하는 대신 편집 중인 행의 값을 올바르게 반환합니다.The IndexOf method, as implemented by the DataView class, now correctly returns the value of a row that is being edited, instead of returning -1.
이벤트Events 행이 수정된 상태이고 RejectChanges 메서드가 호출되면 이제 PropertyChanged 이벤트가 발생합니다.The PropertyChanged event is now raised when a row is in a modified state and the RejectChanges method is called. 이러한 변경을 통해 DataSet 개체의 내용을 노출하는 UI 컨트롤을 더 쉽게 만들 수 있습니다.This change makes it easier to create UI controls that expose the contents of a DataSet object.
예외Exceptions 연결이 설정되어 있지 않거나 NullReferenceException 대신 열려 있으면 이제 Prepare 메서드가 InvalidOperationException을 throw합니다.The Prepare method now throws an InvalidOperationException when a connection is not set or open instead of a NullReferenceException.
매핑 보기Mapping Views 쿼리 뷰 매핑 오류가 이제 런타임에 NullReferenceException을 throw하는 대신 디자인 타임에 catch됩니다.Query view mapping errors are now caught at design time instead of throwing a NullReferenceException at run time.

이제 매핑 유효성 검사는 개념 스키마(CSDL)의 두 연결 집합이 동일한 열로 매핑되는 오류를 catch합니다.Mapping validation now catches the error in which two association sets in Conceptual Schema (CSDL) are mapped to the same column.
트랜잭션Transactions 트랜잭션이 완료된 후(중단되거나 롤백된 경우 포함) 애플리케이션이 연결에서 명령문을 실행하려고 하면 이제 InvalidOperationException이 throw됩니다.If an application tries to execute a statement on a connection after a transaction has been completed (including aborted or rolled back), an InvalidOperationException is now thrown. 이전 버전에서는 예외가 throw되지 않았으므로 트랜잭션이 중단되더라도 추가 명령을 실행할 수 있었습니다.Previous versions did not throw an exception and let you execute additional commands even if a transaction was aborted.

Entity FrameworkEntity Framework

다음 표에서는 이전에 제한 사항이었거나 기타 문제가 있던 기능의 개선 내용을 설명합니다.The following table describes improvements to features that previously had limitations or other issues.

네임스페이스: System.Data, System.Data.Objects, System.Data.Objects.DataClasses; 어셈블리: System.Data.Entity(System.Data.Entity.dll의)Namespaces: System.Data, System.Data.Objects, System.Data.Objects.DataClasses; assembly: System.Data.Entity (in System.Data.Entity.dll)

기능Feature 3.5 SP1과의 차이점Differences from 3.5 SP1
엔터티 개체Entity objects 이제 Detach 메서드와 SaveChanges 메서드가 호출될 때 엔터티 개체의 상태 간에 패리티가 있습니다.There is now parity between the Detach method and the state of the entity object when the SaveChanges method is called. 이렇게 일관성이 향상되어 예기치 않은 예외가 throw되지 않습니다.This improved consistency prevents unexpected exceptions from being thrown.
Entity SQLEntity SQL Entity SQL에서 식별자 해결에 대한 규칙이 개선되었습니다.Rules have been improved for identifier resolutions in Entity SQL.

Entity SQL 파서에서 다중 파트 식별자 확인에 대한 논리가 개선되었습니다.The Entity SQL parser has improved logic for resolving multipart identifiers.
구조적 주석Structural annotations 이제 Entity Framework가 구조적 주석을 인식합니다.The Entity Framework now recognizes structural annotations.
쿼리Queries 쿼리는 다음과 같이 향상되었습니다.The following improvements were made in queries:

* 빈 컬렉션에 대해 null 키를 사용하는 GroupBy 쿼리는 쿼리에 추가 선택 항목이 있는지에 관계없이 행을 반환하지 않습니다.* A GroupBy query using a null key over an empty collection will not return any rows, regardless if there are any additional selects in the query.
* LINQ 및 Entity-SQL 쿼리에서 생성된 SQL은 기본적으로 문자열 매개 변수를 유니코드가 아닌 값으로 처리합니다.* Generated SQL in LINQ and Entity-SQL queries now treat string parameters as non-Unicode values by default.

LINQ to SQLLINQ to SQL

다음 표에서는 이전에 제한 사항이었거나 기타 문제가 있던 기능의 개선 내용을 설명합니다.The following table describes improvements to features that previously had limitations or other issues.

네임스페이스: System.Data.Linq; 어셈블리: System.Data.Linq(System.Data.Linq.dll의)Namespace: System.Data.Linq; assembly: System.Data.Linq (in System.Data.Linq.dll)

기능Feature 3.5 SP1과의 차이점Differences from 3.5 SP1
이벤트Events 컬렉션이 로드될 때 이벤트를 일으키는 것 외에도, EntitySet<TEntity>가 언로드될 때 EntitySet<TEntity> 컬렉션은 이제 추가 및 제거 작업에 대해 ListChanged 이벤트를 발생시킵니다.A EntitySet<TEntity> collection now raises the ListChanged event for add and remove operations if the EntitySet<TEntity> is unloaded, in addition to raising the event when the collection is loaded.
쿼리Queries Skip(0)은 LINQ to SQL 쿼리에서 더 이상 무시되지 않습니다.Skip(0) is no longer ignored in LINQ to SQL queries. 따라서 이 메서드가 있는 쿼리가 다르게 동작할 수 있습니다.As a result, queries that have this method might behave differently. 예를 들면 경우에 따라 Skip(0)OrderBy 절이 필요하며, OrderBy 절이 포함되지 않은 경우 이제 쿼리에서 NotSupportedException 예외를 throw합니다.For example in some cases, an OrderBy clause is required with Skip(0), and the query will now throw a NotSupportedException exception if the OrderBy clause was not included.

WCF Data ServicesWCF Data Services

다음 표에서는 이전에 제한 사항이었거나 기타 문제가 있던 기능의 개선 내용을 설명합니다.The following table describes improvements to features that previously had limitations or other issues.

네임스페이스: System.Data.Services, System.Data.Services.Client, System.Data.Services.Common, System.Data.Services.Providers; 어셈블리: System.Data.Services(System.Data.Services.dll의), System.Data.Services.Client(System.Data.Services.Client.dll의)Namespaces: System.Data.Services, System.Data.Services.Client, System.Data.Services.Common, System.Data.Services.Providers; assemblies: System.Data.Services (in System.Data.Services.dll), System.Data.Services.Client (in System.Data.Services.Client.dll)

기능Feature 3.5 SP1과의 차이점Differences from 3.5 SP1
일괄 처리된 이진 콘텐츠Batched Binary Content 이제 WCF 데이터 서비스는 요청 및 응답에서 일괄 처리된 이진 콘텐츠를 지원합니다.WCF Data Services now supports batched binary content in requests and responses.
변경 인터셉터Change interceptors 이제 삭제 요청에 대해 변경 인터셉터가 실행됩니다.Change interceptors are now executed for a delete request.

변경 인터셉터는 엔터티 집합의 엔터티를 수정하기 위해 서버에서 요청을 수신할 때마다 실행되는 메서드로서,A change interceptor is a method that runs every time a request is received by the server to modify an entity in the entity set. 들어오는 요청이 실행되기 전에 실행됩니다.It runs before the incoming request is executed. 또한 변경되고 있는 엔터티 및 여기에서 수행되는 작업에 대한 액세스를 제공합니다.The change interceptor provides access to the entity that is being changed and the operation that is being performed on it.
예외Exceptions 다음 조건은 이제 NullReferenceException 대신 좀 더 유용한 예외를 throw합니다.The following conditions now throw more useful exceptions instead of a NullReferenceException:

* 데이터 서비스 호출이 시간 초과될 때 TimeoutException.* A TimeoutException when a call to a data service times out.
* 데이터 서비스에 대한 잘못된 요청이 있을 때 DataServiceRequestException.* A DataServiceRequestException when a bad request is made to a data service.

애플리케이션에서 새 예외를 catch하려면 예외 처리를 변경해야 합니다.In your applications, you should change exception handling to catch the new exceptions.
헤더Headers 헤더는 다음과 같이 향상되었습니다.The following improvements were made to headers:

* WCF Data Services는 이제 지정되지 않은 값을 가지고 있는 eTag 헤더를 올바르게 거부합니다.* WCF Data Services now correctly rejects an eTag header that has an unspecified value.
* WCF Data Services는 이제 오류를 반환하고, 요청에 if-* 헤더가 있을 때 링크에 대한 삭제 요청을 실행하지 않습니다.* WCF Data Services now returns an error and does not execute the request for a delete request to a link when an if-* header is in the request.
* WCF Data Services는 이제 클라이언트가 Accept 헤더에 지정한 형식(Atom, JSON)으로 클라이언트에 오류를 반환합니다.* WCF Data Services now returns an error to the client in the format (Atom, JSON) that the client specified in the Accept header.
JSON 판독기JSON Reader JSON(JavaScript Object Notation) 판독기는 이제 WCF 데이터 서비스로 전송된 JSON 페이로드를 처리할 때 단일 백 슬래시(“\”) 이스케이프 문자를 읽을 경우 올바르게 오류를 반환합니다.The JavaScript Object Notation (JSON) reader now correctly returns an error when it reads the single backslash ("\") escape character, when it processes JSON payloads sent to a WCF Data Service.
병합Merges MergeOption 열거형은 다음과 같이 향상되었습니다.The following improvements were made to the MergeOption enumeration:

* MergeOption 병합 옵션은 더 이상 데이터 서비스에서 오는 후속 응답의 결과로 클라이언트의 엔터티를 수정하지 않습니다.* The MergeOption merge option no longer modifies the entity on the client as a result of any subsequent response from a data service.
* MergeOption 옵션은 이제 동적 SQL과 저장 프로시저 기반 업데이트 간에 일치합니다.* The MergeOption option is now consistent between dynamic SQL and stored procedure-based updates.
요청Requests OnStartProcessingRequest 메서드는 이제 데이터 서비스에 대한 요청이 처리되기 전에 호출됩니다.The OnStartProcessingRequest method is now called before a request to data services is processed. 따라서 ServiceOperation 서비스에 대한 요청이 올바르게 작동할 수 있습니다.This enables the request to work correctly for ServiceOperation services.
스트림Streams WCF Data Services는 더 이상 읽기 및 쓰기 작업에 대한 기본 스트림을 닫지 않습니다.WCF Data Services no longer closes the underlying stream for read and write operations.
URIURIs WCF Data Services 클라이언트에서 URI의 이스케이프가 수정되었습니다.The escaping of URIs by WCF Data Services client has been corrected.

WCF(Windows Communication Foundation)Windows Communication Foundation (WCF)

다음 표에서는 이전에 제한 사항이었거나 기타 문제가 있던 기능의 개선 내용을 설명합니다.The following table describes improvements to features that previously had limitations or other issues.

기능Feature 3.5 SP1과의 차이점Differences from 3.5 SP1
구성 파일Configuration files 구성 파일 계층 구조를 통해 동작을 상속할 수 있도록 WCF는 이제 구성 파일 간 병합을 지원합니다.To enable inheritance of behaviors through the configuration file hierarchy, WCF now supports merging across configuration files.

이제 구성 상속 모델이 확장되어 컴퓨터에서 실행 중인 모든 서비스에 적용될 동작을 사용자가 정의할 수 있습니다.The configuration inheritance model is now expanded to let users define behaviors that will be applied to all the services that are running on the computer.

계층 구조의 서로 다른 수준에 같은 이름의 동작이 있는 경우 동작 변경이 발생할 수 있습니다.You may encounter behavioral changes if there are behaviors with the same name at different levels of the hierarchy.
서비스 호스팅Service hosting 요소 정의에 allowDefinition="MachineToApplication" 특성을 추가하여 서비스 수준에서 더 이상 <serviceHostingEnvironment> 구성 요소를 지정할 수 없습니다.You can no longer specify the <serviceHostingEnvironment> configuration element at the service level by adding the attribute allowDefinition="MachineToApplication" to the element definition.

서비스 수준에서 <serviceHostingEnvironment> 요소를 지정하는 것은 기술적으로 올바르지 않으며, 이로 인해 일관성 없는 동작이 발생합니다.Specifying the <serviceHostingEnvironment> element at the service level is technically incorrect and causes inconsistent behavior.

WPF(Windows Presentation Foundation)Windows Presentation Foundation (WPF)

애플리케이션Applications

네임스페이스: System.Windows, System.Windows.Controls; 어셈블리: PresentationFramework(PresentationFramework.dll의)Namespaces: System.Windows, System.Windows.Controls; assembly: PresentationFramework (in PresentationFramework.dll)

기능Feature 3.5 SP1과의 차이점Differences from 3.5 SP1 권장 변경 내용Recommended changes
예외 처리Exception handling 오류를 더 일찍 검색할 수 있도록 WPF는 TargetInvocationException을 throw하고 원래 예외를 catch하는 대신 InnerException 속성을 NullReferenceException, OutOfMemoryException, StackOverflowExceptionSecurityException과 같은 심각한 예외로 설정합니다.To enable errors to be detected earlier, WPF throws a TargetInvocationException and sets the InnerException property to critical exceptions, such as NullReferenceException, OutOfMemoryException, StackOverflowException, and SecurityException, instead of catching the original exception. 없음None.
연결된 리소스Linked resources 좀 더 쉬운 연결을 위해, 프로젝트의 폴더 구조가 아닌 다른 위치에 있는 리소스 파일(예: 이미지)은 애플리케이션을 빌드할 때 파일 이름 대신 리소스 파일의 전체 경로를 리소스 ID로 사용합니다.To make linking easier, resource files (such as images) that are located in a location other than the project's folder structure use the resource file's full path instead of just its file name as the resource ID when the application is built. 애플리케이션은 런타임 시 파일을 찾을 수 있습니다.The application will be able to locate the files at run time. 없음None.
부분 신뢰 애플리케이션Partial-trust applications 보안상의 이유로, 부분 신뢰로 실행되고 HTML이 포함된 WebBrowser 컨트롤 또는 Frame 컨트롤을 포함하는 Windows 기반 애플리케이션은 컨트롤이 생성될 때 SecurityException을 throw합니다.For security considerations, Windows-based applications that run in partial trust and contain a WebBrowser control or a Frame control that contains HTML will throw a SecurityException when the control is created.

브라우저 애플리케이션은 예외를 throw하고 다음 조건이 모두 충족될 경우 메시지를 표시합니다.Browser applications will throw an exception and display a message if all of the following conditions are met:

* 애플리케이션이 Firefox에서 실행되고 있습니다.* The application is running in Firefox.
* 애플리케이션이 신뢰할 수 없는 사이트의 인터넷 영역에서 부분 신뢰로 실행되고 있습니다.* The application is running in partial trust in the Internet zone from non-trusted sites.
* 애플리케이션에 HTML이 포함된 WebBrowser 컨트롤 또는 Frame 컨트롤이 있습니다.* The application contains a WebBrowser control or a Frame control that contains HTML.

신뢰할 수 있는 사이트 또는 인트라넷 영역에서 실행되는 애플리케이션은 영향을 받지 않습니다.Note that applications that run from trusted sites or from the intranet zone will not be affected.
브라우저 애플리케이션에서 다음 중 하나를 수행하여 이 변경의 영향을 완화할 수 있습니다.In your browser applications, you can ease this change by doing one of the following:

* 완전 신뢰에서 브라우저 애플리케이션을 실행합니다.* Run the browser application in full trust.
* 고객이 애플리케이션의 사이트를 신뢰할 수 있는 사이트 영역에 추가하도록 합니다.* Have customers add the application's site to the trusted sites zone.
* 고객이 Internet Explorer에서 애플리케이션을 실행하도록 합니다.* Have customers run the application in Internet Explorer.
리소스 사전Resource dictionaries 테마 수준 리소스 사전을 개선하고, 변경하지 못하도록 리소스 사전에 정의되어 있고 테마 수준 사전에 병합된 고정 가능한 리소스는 항상 고정된 것으로 표시되며 변경되지 않습니다.To improve theme-level resource dictionaries and prevent them from changing, freezable resources that are defined in a resource dictionary and merged into a theme-level dictionary are now always marked as frozen and are immutable. 이것이 고정 가능한 리소스에 대해 예상되는 동작입니다.This is the expected behavior for freezable resources. 테마 수준에서 병합된 사전에 정의된 리소스를 수정하는 애플리케이션은 리소스를 복제하고 복제된 복사본을 수정해야 합니다.Applications that modify a resource that is defined in a theme-level merged dictionary should clone the resource and modify the cloned copy. 또는 리소스를 쿼리할 때마다 ResourceDictionary에서 새 복사본을 만들도록 리소스를 x:Shared="false"로 표시할 수 있습니다.Alternatively, the resource can be marked x:Shared="false" so that the ResourceDictionary creates a new copy every time the resource is queried.
Windows 7Windows 7 WPF 애플리케이션이 Windows 7에서 더 잘 작동할 수 있도록 다음과 같이 창 동작이 수정되었습니다.To make WPF applications work better on Windows 7, the following improvements were made to correct the behavior of a window:

* 도킹 및 제스처 상태가 이제 사용자 상호 작용을 기반으로 예상대로 작동합니다.* Dock and gesture states now work as expected based on user interactions.
* 작업 표시줄 명령 Cascade windows, Show windows stackedShow windows side-by-side가 이제 올바르게 작동하고 적절한 속성을 업데이트합니다.* The taskbar commands Cascade windows, Show windows stacked, and Show windows side-by-side now have the correct behavior and update the appropriate properties.
* 이제 최대화 또는 최소화된 창의 Top, Left, WidthHeight 속성에 모니터에 따라 다른 값 대신 창의 올바른 복원 위치가 포함됩니다.* The Top, Left, Width, and Height properties for a maximized or minimized window now contain the correct restore location of the window instead of other values, depending on the monitor.
없음None.
창 스타일 및 투명도Windows style and transparency AllowsTransparencytrue이고 WindowStateWindowState일 때 WindowStyleWindowStyle 이외의 값으로 설정하려고 하면 InvalidOperationException이 throw됩니다.An InvalidOperationException is thrown if you try to set WindowStyle to a value other than WindowStyle when AllowsTransparency is true and WindowState is WindowState. AllowsTransparencytrue일 때 WindowStyle을 변경해야 하는 경우 Win32 SetWindowLongPtr 기능을 호출할 수 있습니다.If you must change the WindowStyle when AllowsTransparency is true, you can call the Win32 SetWindowLongPtr function.
XPS 뷰어XPS Viewer WPF에는 Microsoft XPSEP(XML Paper Specification Essentials Pack)가 포함되어 있지 않습니다.WPF does not include the Microsoft XML Paper Specification Essentials Pack (XPSEP). XPSEP는 Windows 7 및 Windows Vista에 포함되어 있습니다.XPSEP is included with Windows 7 and Windows Vista.

.NET Framework 3.5 SP1을 설치하지 않고 Windows XP를 실행하는 컴퓨터에서는 PrintDialog에 있는 것 이외의 WPF API를 사용하여 인쇄할 때 WINSPOOL에 의존하게 됩니다.On a computer that is running Windows XP without the .NET Framework 3.5 SP1 installed, printing by using a WPF API other than those in PrintDialog will rely on the WINSPOOL. 일부 프린터 기능은 보고되지 않으며 일부 프린터 설정은 인쇄 중에 적용되지 않습니다.Some printer capabilities will not be reported and some printer settings will not be applied during printing.
필요한 경우 Microsoft XML Paper Specification Essentials Pack을 설치하세요.If needed, install the Microsoft XML Paper Specification Essentials Pack.

컨트롤Controls

네임스페이스: System.Windows, System.Windows.Controls, System.Windows.Data, System.Windows.Input; 어셈블리: PresentationFramework(PresentationFramework.dll의), PresentationCore(PresentationCore.dll의), WindowsBase(WindowsBase.dll의)Namespaces: System.Windows, System.Windows.Controls, System.Windows.Data, System.Windows.Input; assemblies: PresentationFramework (in PresentationFramework.dll), PresentationCore (in PresentationCore.dll), WindowsBase (in WindowsBase.dll)

기능Feature 3.5 SP1과의 차이점Differences from 3.5 SP1 권장 변경 내용Recommended changes
대화 상자Dialog boxes 안정성을 높이기 위해 ShowDialog 메서드는 FileDialog 컨트롤을 만든 동일한 스레드에서 호출됩니다.To improve reliability, the ShowDialog method is called on the same thread that created the FileDialog control. 반드시 FileDialog 컨트롤을 만들고 동일한 스레드에서 ShowDialog 메서드를 호출해야 합니다.Be sure to create a FileDialog control and call the ShowDialog method on the same thread.
부동 창Floating windows 부동 창을 올바르지 않게 계속해서 다시 활성화하여 모달 대화 상자처럼 표시되게 하는 포커스 복원 논리를 수정하기 위해, 이제 후보가 창의 자식이 아닌 경우 포커스 복원이 방지됩니다.To fix focus restoration logic that incorrectly keeps reactivating a floating window (making it appear like a modal dialog box), focus restoration is now prevented if the candidate is not a child of the window. 없음None.
컬렉션의 항목Items in collections 항목을 기본 컬렉션으로 이동하거나 추가할 경우, CollectionView가 정렬되지 않으면 동일한 상대 위치의 CollectionView에 항목이 나타납니다.When an item is moved or added to an underlying collection, it appears in the CollectionView in the same relative location if the CollectionView is not sorted. 이렇게 하면 컬렉션의 항목 위치 및 연관된 CollectionView의 항목 위치 간에 일관성이 유지됩니다.This provides consistency between the item's position in the collection and in the associated CollectionView. 항목의 고정된 위치에 의존하는 대신 CollectionView에서 항목의 위치를 찾으려면 ContainerFromItem 또는 IndexOf 메서드를 사용하세요.Use the ContainerFromItem or IndexOf method to find the location of an item in a CollectionView instead of relying on a fixed location of an item.
레이아웃Layouts 불필요한 레이아웃 재작업을 제거하기 위해 ShowsNavigationUI를 변경하면 더 이상 레이아웃이 무효화되지 않거나 다른 레이아웃이 전달됩니다.To eliminate unnecessary re-layouts, changing the ShowsNavigationUI no longer invalidates layout or causes another layout pass. ShowsNavigationUI를 변경하면 다른 레이아웃이 전달될 것으로 예상하는 경우, 속성을 설정한 후에 InvalidateVisual을 호출하세요.If you expect that changing ShowsNavigationUI will cause another layout pass, call InvalidateVisual after you set the property.
메뉴Menus 메뉴 팝업에서 ClearType 텍스트를 사용할 수 있도록 ControlTemplate 클래스와 MenuItem 컨트롤 및 기타 컨트롤이 수정되었습니다.To enable ClearType text in menu pop-ups, modifications were made to the ControlTemplate class and to the MenuItem control and other controls. 애플리케이션은 컨트롤 템플릿의 시각적 구조에 의존해서는 안 됩니다.Applications should not rely on the visual structure of control templates. ControlTemplate의 명명된 부분만 공용 계약의 일부입니다.Only named parts of a ControlTemplate are part of the public contract. 애플리케이션이 ControlTemplate에서 특정 개체를 찾아야 하는 경우, 트리에서 개체의 고정된 위치에 의존하는 대신 시각적 트리에서 특정 형식을 검색하세요.If an application must find a certain object in a ControlTemplate, search the visual tree for a specific type instead of relying on a fixed location of an object in the tree.
탐색Navigating Frame이 특정 위치로 직접 이동하면 초기 탐색 후 IsNavigationInitiator 속성은 true입니다.If a Frame directly navigates to a location, the IsNavigationInitiator property is true after the initial navigation. 이러한 변경 덕분에 시작 시나리오 중에 추가 이벤트가 발생하지 않습니다.This change prevents additional events from being raised during startup scenarios. 없음None.
팝업Pop-ups 레이아웃 전달 중에 CustomPopupPlacementCallback 대리자를 한 번만 호출하는 대신 여러 번 호출할 수 있습니다.The CustomPopupPlacementCallback delegate can now be called multiple times during a layout pass instead of only once. CustomPopupPlacementCallback 대리자가 이전 위치를 기반으로 Popup의 위치를 계산할 때 popupSize, targetSize 또는 offset 매개 변수의 값이 변경되는 경우에만 위치를 다시 계산하세요.If your CustomPopupPlacementCallback delegate calculates the position of a Popup based on its previous position, recalculate the position only if the values of the popupSize, targetSize, or offset parameters change.
속성 값Property values SetCurrentValue 메서드를 사용할 경우 속성에 영향을 미치는 모든 바인딩, 스타일 또는 트리거는 계속 준수되지만, 속성을 유효한 값으로 설정할 수 있습니다.The SetCurrentValue method now lets you set a property to an effective value, although it continues to respects any binding, style, or trigger that affects the property. 컨트롤 작성자는 사용자 조작을 포함하여 다른 동작의 부작용으로 속성 값이 변경될 때마다 SetCurrentValue를 사용해야 합니다.Control authors should use SetCurrentValue whenever the property value changes as a side-effect of some other action, including user manipulation.
텍스트 상자Text boxes 보안상의 이유로, CopyCut 메서드는 부분 신뢰로 호출될 때 자동으로 실패합니다.For security considerations, the Copy and Cut methods silently fail when they are called in partial trust.

또한 TextBoxBase에서 상속한 컨트롤의 Copy 또는 Cut 속성을 프로그래밍 방식으로 실행하면 부분 신뢰에서 차단됩니다.In addition, programmatic execution of the Copy or Cut property on a control that inherits from TextBoxBase will be blocked in partial trust. 그러나 Command 속성이 이러한 명령 중 하나에 바인딩된 단추를 클릭하는 등 사용자가 시작한 복사 및 잘라내기 명령은 작동합니다.However, user-initiated copy and cut commands, such as clicking a button whose Command property is bound to one of these commands, will work. 바로 가기 키를 통한 표준 복사 및 잘라내기와 상황에 맞는 메뉴는 이전과 마찬가지로 부분 신뢰로 작동합니다.Standard copy and cut through keyboard shortcuts and the context menu will still work as before in partial trust.
단추 클릭 등 사용자가 시작한 작업에 Copy 또는 Cut 명령을 바인딩하세요.Bind the Copy or Cut command to a user-initiated action, such as clicking a button.

그래픽Graphics

네임스페이스: System.Windows, System.Windows.Controls, System.Windows.Data, System.Windows.Input, System.Windows.Media.Effects; 어셈블리: PresentationFramework(PresentationFramework.dll의), PresentationCore(PresentationCore.dll의), WindowsBase(WindowsBase.dll의)Namespaces: System.Windows, System.Windows.Controls, System.Windows.Data, System.Windows.Input, System.Windows.Media.Effects; assemblies: PresentationFramework (in PresentationFramework.dll), PresentationCore (in PresentationCore.dll), WindowsBase (in WindowsBase.dll)

기능Feature 3.5 SP1과의 차이점Differences from 3.5 SP1 권장 변경 내용Recommended changes
비트맵 효과Bitmap effects 성능 향상을 위해, BitmapEffect 클래스 및 BitmapEffect 클래스에서 상속한 클래스는 여전히 존재하지만 비활성화되어 있습니다.To improve performance, the BitmapEffect class and the classes that inherit from the BitmapEffect class, although still present, are disabled. 다음 조건이 참인 경우 하드웨어 가속 렌더링 파이프라인을 사용하여 효과가 렌더링됩니다.The effect will render by using the hardware-accelerated rendering pipeline if the following conditions are true:

* 애플리케이션은 반경 속성이 100DIU 미만인 DropShadowBitmapEffect 또는 BlurBitmapEffect를 사용합니다.* The application uses a DropShadowBitmapEffect or a BlurBitmapEffect that has a radius property set less than 100 DIU.
* 애플리케이션을 실행하는 컴퓨터의 비디오 카드는 픽셀 셰이더 2.0을 지원합니다.* The video card on the computer that runs the application supports pixel shader 2.0.

이러한 조건이 충족되지 않으면 BitmapEffect 개체는 아무 효과도 없습니다.If these conditions are not met, a BitmapEffect object will have no effect.

또한 Visual Studio는 BitmapEffect 개체 또는 하위 클래스를 발견하면 컴파일러 경고를 생성합니다.Also, Visual Studio produces a compiler warning when it encounters the BitmapEffect object or a subclass.

PushEffect 메서드는 사용되지 않는 것으로 표시됩니다.The PushEffect method is marked obsolete.
기존의 BitmapEffect 및 파생 클래스 사용을 중단하고 대신 Effect에서 파생된 새 클래스(BlurEffect, DropShadowEffectShaderEffect)를 사용하세요.Discontinue using the legacy BitmapEffect and derived classes and instead use the new classes derived from Effect: BlurEffect, DropShadowEffect, and ShaderEffect.

ShaderEffect 클래스로부터 상속받아 자신의 고유한 효과를 만들 수도 있습니다.You can also create your own effects by inheriting from the ShaderEffect class.
비트맵 프레임Bitmap frames 복제된 BitmapFrame 개체는 이제 DownloadProgress, DownloadCompletedDownloadFailed 이벤트를 수신합니다.The cloned BitmapFrame objects now receive the DownloadProgress, DownloadCompleted, and DownloadFailed events. 이렇게 하면, 웹에서 다운로드되어 Image 컨트롤에 적용된 이미지가 Style을 통해 올바르게 작동합니다.This enables images that are downloaded from the Web and applied to the Image control through a Style to work correctly.

다음이 모두 참인 경우에만 동작이 변경됩니다.You will see a change in behavior only if all of the following statements are true:

* DownloadProgress, DownloadCompleted 또는 DownloadFailed 이벤트를 구독합니다.* You subscribe to the DownloadProgress, DownloadCompleted, or DownloadFailed event.
* BitmapFrame의 소스가 웹에서 온 것입니다.* The source of the BitmapFrame is from the Web.
* 다운로드가 진행되는 동안 BitmapFrame이 복제됩니다.* The BitmapFrame is cloned while the download is still in progress.
이벤트 처리기에서 전송자를 확인하고 전송자가 원래 BitmapFrame인 경우에만 조치를 취하세요.Check the sender in the event handler and take action only if the sender is the original BitmapFrame.
이미지 디코딩Decoding images 이미지가 디코딩되지 않을 때 IOException이 처리되지 않도록 BitmapSource 클래스는 이미지를 디코딩하지 않을 때 DecodeFailed 이벤트를 일으킵니다.To prevent an IOException from not being handled when images may not decode, the BitmapSource class will raise the DecodeFailed event when it does not decode an image. IOException에 대한 예외 처리를 제거하고 DecodeFailed 이벤트를 사용하여 디코딩 실패를 확인하세요.Remove any exception handling for IOException, and use the DecodeFailed event to check for decode failure.

입력Input

네임스페이스: System.Windows, System.Windows.Controls, System.Windows.Data, System.Windows.Input; 어셈블리: PresentationFramework(PresentationFramework.dll의), PresentationCore(PresentationCore.dll의), WindowsBase(WindowsBase.dll의)Namespaces: System.Windows, System.Windows.Controls, System.Windows.Data, System.Windows.Input; assemblies: PresentationFramework (in PresentationFramework.dll), PresentationCore (in PresentationCore.dll), WindowsBase (in WindowsBase.dll)

기능Feature 3.5 SP1과의 차이점Differences from 3.5 SP1 권장 변경 내용Recommended changes
명령 인스턴스 바인딩Binding command instances 보기-모델 기반 명령 인스턴스를 보기 기반 입력 제스처에 바인딩하는 메커니즘을 제공하기 위해 InputBinding 클래스는 이제 DependencyObject 대신 Freezable에서 상속받습니다.To provide a mechanism to bind View-Model-based command instances to View-based input gestures, the InputBinding class now inherits from Freezable instead of DependencyObject. 이제 다음 속성이 종속성 속성이 됩니다.The following properties are now dependency properties:

* Command
* CommandParameter
* CommandTarget

이 변경의 결과는 다음과 같습니다.This change results in the following:

* 이제 InputBinding 개체는 변경 가능한 상태로 유지되는 대신 등록 시 고정됩니다.* An InputBinding object is now frozen when it is registered instead of remaining mutable.
* DependencyObject 클래스의 제한 때문에 다중 스레드에서 인스턴스 수준 InputBinding 개체에 액세스할 수 없습니다.* You cannot access instance-level InputBinding objects from multiple threads, due to the restrictions of the DependencyObject class.
* Freezable 클래스의 제한 때문에 등록 이후에 클래스 수준 입력 바인딩을 변경할 수 없습니다.* You cannot mutate class-level input bindings after their registration, due to the restrictions of the Freezable class.
* 보기-모델에서 작성된 명령 인스턴스에는 입력 바인딩을 지정할 수 없습니다.* You cannot specify input bindings on command instances that are created in a View-Model.
바인딩이 변경될 수 있는 경우 개별 스레드에 InputBinding 클래스의 개별 인스턴스를 작성하거나 아니면 고정하세요.Create separate instances of an InputBinding class on separate threads if bindings are to be mutable, or freeze them otherwise. 등록된 후에는 클래스 수준의 정적 InputBinding을 변경하지 마세요.Do not mutate a class-level static InputBinding after it has been registered.
브라우저 애플리케이션Browser applications WPF 브라우저 애플리케이션(.XBAP)은 이제 개체가 올바른 순서로 라우팅된 키 이벤트를 수신할 수 있도록 독립 실행형 WPF 애플리케이션과 마찬가지로 키 이벤트를 처리합니다.WPF Browser applications (.XBAP) now process key events just like stand-alone WPF applications so that objects receive routed key events in the correct order. 없음None.
데드 키 조합Dead key combinations WPF는 눈에 보이는 문자를 생성하지 않는 데드 키를 난독 처리하지만, 대신 키가 다음 문자 키와 결합되어 한 문자를 생성함을 나타냅니다.WPF obfuscates dead keys, which produce no visible character, but instead indicates that the key is to be combined with the next letter key to produce one character. KeyDownEvent 이벤트와 같은 키 입력 이벤트는 Key 속성을 Key 값으로 설정하여 키가 데드 키일 때 보고합니다.The key input events, such as the KeyDownEvent event, report when a key is a dead key by setting the Key property to the Key value. 애플리케이션은 일반적으로 결합된 문자를 만드는 키보드 입력에 응답하지 않으므로, 이는 일반적으로 예상되는 동작입니다.This is usually expected behavior because applications usually do not intend to respond to keyboard input that creates a combined character. 결합된 문자의 일부였던 키를 읽어야 하는 애플리케이션은 DeadCharProcessedKey 속성을 사용하여 현재 모호한 키를 얻을 수 있습니다.Applications that expect to read keys that were part of combined characters can get the now obfuscated key by using the DeadCharProcessedKey property.
포커스 관리자Focus manager true로 설정된 IsFocusScope 연결 속성이 있는 요소가 FocusManager.GetFocusedElement(DependencyObject) 메서드에 전달되면, 이 메서드는 해당 포커스 영역 내에서 마지막 키보드 포커스 요소인 요소를 반환합니다. 단, 반환된 요소가 메서드에 전달된 요소와 동일한 PresentationSource 개체여야 합니다.When the FocusManager.GetFocusedElement(DependencyObject) method is passed an element that has the IsFocusScope attached property set to true, the method returns an element that is the last keyboard-focused element within that focus scope if and only if the returned element belongs to the same PresentationSource object as the element that is passed to the method. 없음None.

UI 자동화UI Automation

네임스페이스: System.Windows, System.Windows.Automation.Peers, System.Windows.Automation.Provider, System.Windows.Controls, System.Windows.Data, System.Windows.Input; 어셈블리: PresentationFramework(PresentationFramework.dll의), PresentationCore(PresentationCore.dll의), UIAutomationProvider(UIAutomationProvider.dll의), WindowsBase(WindowsBase.dll의)Namespace: System.Windows, System.Windows.Automation.Peers, System.Windows.Automation.Provider, System.Windows.Controls, System.Windows.Data, System.Windows.Input; assemblies: PresentationFramework (in PresentationFramework.dll), PresentationCore (in PresentationCore.dll), UIAutomationProvider (in UIAutomationProvider.dll), WindowsBase (in WindowsBase.dll)

기능Feature 3.5 SP1과의 차이점Differences from 3.5 SP1 권장 변경 내용Recommended changes
보기의 클래스 계층 구조Class hierarchy of views TreeViewAutomationPeerTreeViewItemAutomationPeer 클래스는 FrameworkElementAutomationPeer 대신 ItemsControlAutomationPeer에서 상속합니다.The TreeViewAutomationPeer and TreeViewItemAutomationPeer classes inherit from ItemsControlAutomationPeer instead of FrameworkElementAutomationPeer. TreeViewItemAutomationPeer 클래스에서 상속하고 GetChildrenCore 메서드를 재정의하는 경우 새 TreeViewDataItemAutomationPeer 클래스에서 상속하는 개체의 반환을 고려해 보세요.If you inherit from the TreeViewItemAutomationPeer classes and override the GetChildrenCore method, consider returning an object that inherits from the new TreeViewDataItemAutomationPeer class.
화면 밖 컨테이너Containers off screen 잘못된 반환 값을 수정하기 위해 IsOffscreenCore 메서드는 보기에서 벗어나 스크롤된 항목 컨테이너에 대해 이제 false를 올바르게 반환합니다.To fix an incorrect return value, the IsOffscreenCore method now correctly returns false for item containers that are scrolled out of view. 또한 메서드의 값은 다른 창에 의해 가려지는지 또는 요소가 특정 모니터에 표시되는지 여부에 의해 영향을 받지 않습니다.Also, the value of the method is not affected by occlusion by other windows, or by whether the element is visible on a specific monitor. 없음None.
메뉴 및 자식 개체Menus and child objects MenuItem 개체가 아닌 자식이 포함된 메뉴의 UI 자동화를 사용할 수 있도록, GetChildrenCore 메서드는 MenuItemAutomationPeer 개체 대신 자식 UIElement 개체의 AutomationPeer 개체를 반환합니다.To enable UI automation of menus that contain children other than MenuItem objects, the GetChildrenCore method now returns the AutomationPeer object of a child UIElement object, instead of a MenuItemAutomationPeer object. 없음None.
새 인터페이스 및 어셈블리New interfaces and assembly UI 자동화에 대한 새로운 기능을 사용할 수 있도록 다음 인터페이스가 추가되었습니다.To enable new features for UI automation, the following interfaces were added:

* IItemContainerProvider
* ISynchronizedInputProvider
* IVirtualizedItemProvider
WPF 자동화 피어를 빌드하는 프로젝트는 UIAutomationProvider.dll에 대한 명시적 참조를 추가해야 합니다.Any project that builds WPF automation peers must add an explicit reference to UIAutomationProvider.dll.
ThumbThumbs GetClassNameCore 메서드는 null 대신 값을 반환합니다.The GetClassNameCore method returns a value instead of null. 따라서 Thumb 클래스에서 상속하는 GridSplitter 등의 컨트롤은 이름을 UI 자동화에 보고합니다.Therefore, controls such as GridSplitter that inherit from the Thumb class will report a name to UI Automation. 없음None.
가상화된 요소Virtualized elements 성능 향상을 위해 GetChildrenCore 메서드는 가상화 여부와 관계없이 모든 자식 개체 대신 시각적 트리에 실제로 있는 자식 개체만 반환합니다.To improve performance, the GetChildrenCore method returns only the child objects that are actually in the visual tree, instead of all child objects, regardless of whether they are virtualized. ItemsControlAutomationPeer의 모든 항목을 반복하려면 ItemContainerPattern을 사용하세요.Use ItemContainerPattern to iterate over all items of an ItemsControlAutomationPeer.

XAMLXAML

네임스페이스: System.Windows, System.Windows.Controls, System.Windows.Data, System.Windows.Input, System.Windows.Markup; 어셈블리: PresentationFramework(PresentationFramework.dll의), PresentationCore(PresentationCore.dll의), WindowsBase(WindowsBase.dll의)Namespaces: System.Windows, System.Windows.Controls, System.Windows.Data, System.Windows.Input, System.Windows.Markup; assemblies: PresentationFramework (in PresentationFramework.dll), PresentationCore (in PresentationCore.dll), WindowsBase (in WindowsBase.dll)

기능Feature 3.5 SP1과의 차이점Differences from 3.5 SP1 권장 변경 내용Recommended changes
태그 확장Markup extension WPF는 이제 속성을 설정하거나 컬렉션에 항목을 만들기 위해 태그 확장을 사용할 때 경우에 따라 MarkupExtension 개체를 반환하는 대신 항상 ProvideValue 메서드의 값을 올바르게 사용합니다.WPF now correctly always uses the value from the ProvideValue method instead of returning the MarkupExtension object in certain cases when a markup extension is used to set a property or to create an item in a collection. 경우에 따라 태그 확장은 자체를 반환할 수 있습니다.A markup extension might return itself in some cases. 애플리케이션이 이전 버전에서 MarkupExtension 개체를 반환한 리소스에 액세스하는 경우 MarkupExtension 개체 대신 ProvideValue에서 반환된 개체를 참조하세요.If your application accesses a resource that returned a MarkupExtension object in earlier versions, reference the object that is returned from ProvideValue, instead of the MarkupExtension object.
특성 구문 분석Parsing attributes 이제 XAML의 특성에는 마침표를 하나만 포함할 수 있습니다.Attributes in XAML can now have only one period. 예를 들어, 다음은 유효합니다.For example, the following are valid:

<Button Background="Red"/>(마침표 없음)<Button Background="Red"/> (no periods)

<Button Button.Background = "Red"/>(마침표 1개)<Button Button.Background = "Red"/> (one period)

다음은 유효하지 않습니다.The following is no longer valid:

<Button Control.Button.Background = "Red"/>(마침표 2개 이상)<Button Control.Button.Background = "Red"/> (more than one period)
마침표가 2개 이상인 XAML 특성을 수정하세요.Correct XAML attributes that have more than one period.

XMLXML

다음 표의 각 행에서는 이전에 제한 사항이었거나 기타 문제가 있던 기능의 개선 내용을 설명합니다.The rows in this table describe improvements to features that previously had limitations or other issues.

스키마 및 변환Schema and transforms

네임스페이스: System.Xml.Linq, System.Xml.Schema, System.Xml.XPath; 어셈블리: System.Xml(System.Xml.dll의), System.Xml.Linq(System.Xml.Linq.dll의)Namespaces: System.Xml.Linq; System.Xml.Schema, System.Xml.XPath; assemblies: System.Xml (in System.Xml.dll), System.Xml.Linq (in System.Xml.Linq.dll)

기능Feature 3.5 SP1과의 차이점Differences from 3.5 SP1
카멜레온 스키마Chameleon schemas 데이터 손상을 방지하기 위해 이제 카멜레온 스키마는 여러 스키마에 포함될 때 올바르게 복제됩니다.To prevent data corruption, chameleon schemas are now cloned correctly when they are included with multiple schemas.

카멜레온 스키마는 대상 네임스페이스가 없는 스키마이며, 다른 XSD에 포함될 때 가져오기 스키마의 대상 네임스페이스를 사용합니다.Chameleon schemas are schemas that do not have a target namespace, and when they are included in another XSD, they take on the target namespace of the importing schema. 카멜레온 스키마는 스키마에 공통 형식을 포함하는 데 종종 사용됩니다.They are often used to include common types into a schema.
ID 함수ID functions XmlReader 개체가 XLST에 전달될 때 이제 XSLT id 함수가 null 대신 올바른 값을 반환합니다.The XSLT id function now returns the correct value instead of null when an XmlReader object is passed to an XLST.

사용자가 CreateReader 메서드를 사용하여 LINQ to XML 클래스에서 XmlReader 개체를 만들었고 이 XmlReader 개체가 XSLT로 전달된 경우, XSLT의 id 함수 인스턴스가 전에는 null을 반환했습니다.If the user created an XmlReader object from a LINQ to XML class by using the CreateReader method, and this XmlReader object was passed to an XSLT, any instances of the id function in the XSLT previously returned null. 이것은 id 함수에 대해 허용된 반환 값이 아닙니다.This is not an allowed return value for the id function.
네임스페이스 특성Namespace attribute 데이터 손상을 방지하기 위해 이제 XPathNavigator 개체가 x:xmlns 특성의 로컬 이름을 올바르게 반환합니다.To prevent data corruption, an XPathNavigator object now returns the local name of the x:xmlns attribute correctly.
네임스페이스 선언Namespace declarations 하위 트리의 XmlReader 개체는 더 이상 하나의 XML 요소 내에 중복된 네임스페이스 선언을 만들지 않습니다.An XmlReader object on a sub-tree no longer creates duplicate namespace declarations within one XML element.
스키마 유효성 검사Schema validation 잘못된 스키마 유효성 검사를 방지하기 위해, XmlSchemaSet 클래스는 XSD 스키마가 일관성 있고 정확하게 컴파일되도록 합니다.To prevent erroneous schema validation, the XmlSchemaSet class allows for XSD schemas to be compiled correctly and consistently. 이러한 스키마는 다른 스키마를 포함할 수 있습니다. 예를 들어 A.xsdC.xsd를 포함할 수 있는 B.xsd를 포함할 수 있습니다.These schemas can include other schemas; for example, A.xsd can include B.xsd, which can include C.xsd. 이들 중 하나를 컴파일하면 이 의존성 그래프가 트래버스됩니다.Compiling any one of these causes this graph of dependencies to be traversed.
스크립트 함수Script functions 함수가 실제로 사용 가능할 때 function-available 함수는 더 이상 올바르지 않게 false를 반환하지 않습니다.The function-available function no longer incorrectly returns false when the function is actually available.
URIURIs Load 메서드는 이제 LINQ 쿼리에서 올바른 BaseURI를 반환합니다.The Load method now returns the correct BaseURI in LINQ queries.

유효성 검사Validation

네임스페이스: System.Xml.Linq, System.Xml.Schema, System.Xml.XPath; 어셈블리: System.Xml(System.Xml.dll의), System.Xml.Linq(System.Xml.Linq.dll의)Namespaces: System.Xml.Linq; System.Xml.Schema, System.Xml.XPath; assemblies: System.Xml (in System.Xml.dll), System.Xml.Linq (in System.Xml.Linq.dll)

기능Feature 3.5 SP1과의 차이점Differences from 3.5 SP1
네임스페이스 확인자Namespace resolvers ReadContentAs 메서드는 더 이상 전달된 IXmlNamespaceResolver 확인자를 무시하지 않습니다.The ReadContentAs method no longer ignores the IXmlNamespaceResolver resolver passed to it.

이전 버전에서는 지정된 네임스페이스 확인자가 무시되고 대신 XmlReader가 사용되었습니다.In previous versions, the specified namespace resolver was ignored, and the XmlReader was used instead.
공백White space 판독기를 만들 때 데이터 손실을 방지하기 위해 Create 메서드는 더 이상 유효한 공백을 삭제하지 않습니다.To prevent data loss when you are creating a reader, the Create method no longer discards significant white space.

XML 유효성 검사는 텍스트가 XML 태그와 혼합될 수 있는 혼합 콘텐츠 모드를 인식합니다.XML validation recognizes mixed-content mode, where text can be intermixed with XML markup. 혼합 모드에서는 모든 공백이 유효하므로 보고되어야 합니다.In mixed mode, all white space is significant and should be reported.

쓰기Writing

네임스페이스: System.Xml.Linq, System.Xml.Schema, System.Xml.XPath; 어셈블리: System.Xml(System.Xml.dll의), System.Xml.Linq(System.Xml.Linq.dll의)Namespaces: System.Xml.Linq; System.Xml.Schema, System.Xml.XPath; assemblies: System.Xml (in System.Xml.dll), System.Xml.Linq (in System.Xml.Linq.dll)

기능Feature 3.5 SP1과의 차이점Differences from 3.5 SP1
엔터티 참조Entity references 데이터 손상을 방지하기 위해, 엔터티 참조가 더 이상 XML 특성에서 두 번 엔터티화되지 않습니다.To prevent data corruption, entity references are no longer entitized twice in XML attributes.

사용자가 엔터티를 xmlns 특성에 쓰려고 하거나 WriteEntityRef 메서드를 사용하여 xml:lang 또는 xml:space 특성에 쓰려고 하면, 엔터티가 출력에서 두 번 엔터티화되어 데이터가 손상됩니다.If the user tried to write an entity into an xmlns attribute or into an xml:lang or xml:space attribute by using the WriteEntityRef method, the entity was entitized twice in the output, therefore corrupting the data.
줄 바꿈 처리New line handling 데이터 손상을 방지하기 위해 XmlWriter 개체가 NewLineHandling 옵션을 존중합니다.To prevent data corruption, XmlWriter objects respect the NewLineHandling option.

참고 항목See also