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

브라우저 정의 파일

브라우저 정의 파일은 신규 및 업데이트된 브라우저와 장치에 대한 정보를 포함하도록 업데이트되었습니다. Netscape Navigator 등의 이전 브라우저와 장치는 제거되었고 Google Chrome 및 Apple iPhone 같은 새 브라우저와 장치가 추가되었습니다.

제거된 브라우저 정의 중 하나로부터 상속된 사용자 지정 브라우저 정의가 응용 프로그램에 포함되어 있으면 오류가 표시됩니다.

HttpBrowserCapabilities 개체는 페이지의 Request.Browser 속성에 의해 노출되며 브라우저 정의 파일에 의해 구동됩니다. 따라서 ASP.NET 4에서 이 개체의 속성에 액세스하여 반환되는 정보는 이전 버전의 ASP.NET에서 반환되는 정보와 다를 수 있습니다.

응용 프로그램이 이전의 브라우저 정의 파일에 의존하는 경우 이 파일을 다음 폴더에서 복사할 수 있습니다.

Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG\Browsers

ASP.NET 4의 상응하는 \CONFIG\Browsers 폴더로 파일을 복사합니다. 파일을 복사한 후 Aspnet_regbrowsers.exe 명령줄 도구를 실행합니다. 자세한 내용은 https://www.asp.net/mobile 웹 사이트를 참조하십시오.

ClientID 변경 사항

ASP.NET 4에 새로 도입된 ClientIDMode 설정을 사용하면 ASP.NET에서 HTML 요소의 id 특성을 생성하는 방식을 지정할 수 있습니다. 이전 버전의 ASP.NET에서는 기본 동작이 ClientIDMode의 AutoID 설정과 동일했지만 현재 버전에서의 기본 설정은 Predictable입니다. 자세한 내용은 ASP.NET 웹 서버 컨트롤 식별을 참조하십시오.

Visual Studio 2010을 사용하여 응용 프로그램을 ASP.NET 2.0 또는 ASP.NET 3.5에서 업그레이드하는 경우 이전 .NET Framework 버전의 동작을 그대로 유지하는 설정이 Web.config 파일에 자동으로 추가됩니다. 그러나 .NET Framework 4를 대상으로 하기 위해 IIS에서 응용 프로그램 풀을 변경하여 응용 프로그램을 업그레이드하면 ASP.NET에서는 새 모드를 기본적으로 사용합니다. 새로운 클라이언트 ID 모드를 사용하지 않으려면 다음 설정을 Web.config 파일에 추가합니다.

<pages ClientIDMode="AutoID" / >

구성 파일

.NET Framework 및 ASP.NET 4의 루트 구성 파일(machine.config 파일 및 루트 Web.config 파일)은 ASP.NET 3.5의 응용 프로그램 Web.config 파일에 있는 일반적인 구성 정보 대부분을 포함하도록 업데이트되었습니다. 관리되는 IIS 7 및 IIS 7.5 구성 시스템의 복잡성 때문에 ASP.NET 4 및 IIS 7과 IIS 7.5에서 ASP.NET 3.5 응용 프로그램을 실행하면 ASP.NET 오류 또는 IIS 오류가 발생할 수 있습니다.

Visual Studio 2010의 프로젝트 업그레이드 도구를 사용하여 ASP.NET 3.5 응용 프로그램을 ASP.NET 4로 업그레이드하십시오. Visual Studio 2010에서는 ASP.NET 4에 적합한 설정이 포함되도록 ASP.NET 3.5 응용 프로그램의 Web.config 파일을 자동으로 수정합니다.

그러나 ASP.NET 3.5 응용 프로그램은 다시 컴파일하지 않고 .NET Framework 4를 사용하여 실행할 수 있습니다. 이 경우 .NET Framework 4를 기반으로 IIS 7 또는 IIS 7.5에서 응용 프로그램을 실행하려면 먼저 응용 프로그램의 Web.config 파일을 직접 수정해야 할 수도 있습니다. 이 파일에서 변경할 사항은 SP(서비스 팩) 릴리스를 비롯한 사용 중인 소프트웨어의 조합에 따라 다릅니다. 이러한 변경 사항에 영향을 받을 수 있는 소프트웨어 조합 및 특정 조합과 관련된 문제를 해결하는 방법에 대한 자세한 내용은 ASP.NET 웹 사이트에서 ASP.NET 4 Breaking Changes 문서의 "Configuration Errors Related to New ASP.NET 4 Root Configuration" 단원을 참조하십시오.

기본 문서의 이벤트 처리기

ASP.NET 4에서는 기본 문서와 매핑되어 있는 확장명 없는 URL에 대한 요청이 있는 경우 HTML form 요소의 action 특성 값을 빈 문자열로 렌더링합니다. ASP.NET의 이전 릴리스에서 https://contoso.com에 대한 요청은 Default.aspx를 요청하게 됩니다. 이 문서에서 여는 form 태그는 다음 예제와 같이 렌더링됩니다.

<form action="Default.aspx" />

ASP.NET 4에서도 https://contoso.com에 대한 요청은 Default.aspx를 요청하게 되지만 이전과 달리 ASP.NET은 HTML 여는 form 태그를 다음 예제와 같이 렌더링합니다.

<form action="" />

action 특성이 빈 문자열인 경우 IIS DefaultDocumentModule 개체는 Default.aspx에 대한 자식 요청을 생성합니다. 대부분의 경우 이 자식 요청은 응용 프로그램 코드에 투명하고 Default.aspx 페이지는 정상적으로 실행됩니다. 그러나 관리 코드와 IIS 7 또는 IIS 7.5 통합 모드 간에 상호 작용이 발생하여 관리되는 .aspx 페이지의 정상적 작동이 자식 요청이 처리되는 동안 중지될 수도 있습니다. 다음 상황이 발생하는 경우 기본 .aspx 문서에 대한 자식 요청으로 인해 오류 또는 예기치 않은 동작이 나타납니다.

• form 요소의 action 특성이 ""로 설정된 채 .aspx 페이지가 브라우저로 보내집니다.

• 양식이 ASP.NET으로 포스트백됩니다.

• 관리되는 HTTP 모듈이 엔터티 본문의 일부분(예: Request.Form 또는 Request.Params)을 읽습니다. 이렇게 하면 POST 요청의 엔터티 본문이 관리되는 메모리로 읽어 들여집니다. 따라서 IIS 7 또는 IIS 7.5 통합 모드에서 실행 중인 네이티브 코드 모듈은 엔터티 본문을 더 이상 사용할 수 없게 됩니다.

• 결국 IIS DefaultDocumentModule 개체가 실행되어 Default.aspx 문서에 대한 자식 요청을 생성합니다. 그러나 관리 코드 조각이 엔터티 본문을 이미 읽었기 때문에 자식 요청에 대해 보낼 수 있는 엔터티 본문은 없습니다.

• HTTP 파이프라인이 자식 요청에 대해 실행되면 .aspx 파일 처리기는 처리기 실행 단계 중에 실행됩니다.

엔터티 본문이 없기 때문에 폼 변수 및 뷰 상태는 없습니다. 따라서 어느 이벤트(있는 경우)가 발생해야 하는지 .aspx 페이지 처리기가 결정하는 데 사용 가능한 정보가 없는 것입니다. 그 결과 해당 .aspx 페이지의 포스트백 이벤트 처리기는 실행되지 않습니다.

이 변경 사항으로 인해 발생할 수 있는 문제의 해결 방법에 대한 자세한 내용은 ASP.NET 웹 사이트에서 ASP.NET 4 Breaking Changes 문서의 "Event Handlers Might Not Be Not Raised in a Default Document in IIS 7 or IIS 7.5 Integrated Mode"를 참조하십시오.

Internet Explorer에서 컨트롤 호스팅

웹에서 컨트롤을 호스팅하는 보다 나은 솔루션이 있으므로 Internet Explorer에서 Windows Forms 컨트롤을 더 이상 호스팅할 수 없습니다. 따라서 IEHost.dll 및 IEExec.exe 어셈블리는 .NET Framework에서 제거되었습니다.

웹 응용 프로그램에서 사용자 지정 컨트롤을 개발하기 위해 다음과 같은 기술을 사용할 수 있습니다.

• Silverlight 응용 프로그램을 만들어 브라우저 외부에서 실행되도록 구성할 수 있습니다. 자세한 내용은 Out-of-Browser Support을 참조하십시오.

• WPF 기능을 활용하기 위해 XBAP(XAML 브라우저 응용 프로그램)를 빌드할 수 있으며 클라이언트 컴퓨터에 .NET Framework가 필요합니다. 자세한 내용은 WPF XAML 브라우저 응용 프로그램 개요를 참조하십시오.

ASP.NET 2.0 응용 프로그램의 HttpException 오류

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.

• 웹 사이트를 실행하는 데 ASP.NET 4가 필요하지 않은 경우 대신 ASP.NET 2.0을 사용하도록 사이트를 다시 매핑하십시오.

  또는

• 웹 사이트를 실행하는 데 ASP.NET 4가 필요한 경우 자식 ASP.NET 2.0 가상 디렉터리를 ASP.NET 2.0으로 매핑된 다른 웹 사이트로 이동하십시오.

  또는

• 확장명 없는 URL을 사용하지 않습니다. 자세한 내용은 ASP.NET 웹 사이트에서 ASP.NET 4 Breaking Changes 문서의 "ASP.NET 2.0 Applications Might Generate HttpException Errors That Reference eurl.axd"를 참조하십시오.

Menu 컨트롤 변경 사항

Menu 컨트롤을 변경하면 다음 동작이 발생합니다.

• System.Web.UI.WebControls.MenuRenderingMode가 List로 설정되거나 System.Web.UI.WebControls.MenuRenderingMode가 Default로 설정되고 PagesSection.ControlRenderingCompatibilityVersion이 4.0 이상으로 설정된 경우 MenuItem.PopOutImageUrl 속성에는 영향이 없습니다.

• Menu.StaticPopOutImageUrl 및 Menu.DynamicPopOutImageUrl 속성에 설정된 경로에 백슬래시(\)가 포함된 경우 이미지는 렌더링되지 않습니다. 이전 버전의 ASP.NET에서는 경로에 백슬래시를 포함할 수 있었습니다.

• 개별 메뉴 항목의 MenuItem.PopOutImageUrl 속성을 설정하는 대신 부모 System.Web.UI.WebControls.Menu 컨트롤의 Menu.StaticPopOutImageUrl 또는 Menu.DynamicPopOutImageUrl을 설정하십시오.

  또는

  System.Web.UI.WebControls.MenuRenderingMode를 Table로 설정하거나 System.Web.UI.WebControls.MenuRenderingMode를 Default로 설정하고 PagesSection.ControlRenderingCompatibilityVersion을 3.5로 설정하십시오. 이렇게 설정하면 Menu 컨트롤에서 이전 버전의 ASP.NET에 사용된 HTML 테이블 기반 레이아웃을 사용합니다.

• Menu.StaticPopOutImageUrl 및 Menu.DynamicPopOutImageUrl 속성의 경로에 백슬래시(\)가 포함된 경우 슬래시 문자(/)로 바꾸십시오.

출력 캐싱

ASP.NET 1.0에서는 버그로 인해 응답에 Vary:* HTTP 헤더를 내보내기 위한 출력 캐시 설정으로 Location="ServerAndClient"를 지정하는 캐시된 페이지가 생성되었습니다. 이에 따라 클라이언트 브라우저는 페이지를 로컬에 캐시하지 말라는 요청을 받게 되었습니다. ASP.NET 1.1에서는 Vary:* 헤더를 내보내지 않기 위해 호출할 수 있는 HttpCachePolicy.SetOmitVaryStar 메서드가 추가되었습니다. 그러나 버그 보고서에 따르면 개발자가 기존의 SetOmitVaryStar 동작을 알지 못해도 됩니다.

ASP.NET 4에서 Vary:* HTTP 헤더는 더 이상 다음 지시문을 지정하는 응답으로부터 내보내지지 않습니다.

<%@ OutputCache Location="ServerAndClient" %>

따라서 이제 Vary:* 헤더를 내보내지 않기 위해 HttpCachePolicy.SetOmitVaryStar 메서드가 필요하지 않습니다. Location 특성으로 "ServerAndClient"를 지정하는 응용 프로그램의 경우 HttpCachePolicy.SetOmitVaryStar를 호출하지 않아도 페이지를 브라우저에서 캐시할 수 있습니다.

응용 프로그램의 페이지에서 Vary:*를 내보내야 하는 경우 다음 예제와 같이 HttpResponse.AppendHeader 메서드를 호출합니다.

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

또는 출력 캐싱 Location 특성의 값을 "Server"로 변경해도 됩니다.

Passport 형식

Passport(지금은 Live ID SDK) 변경 사항으로 인해 ASP.NET 2.0에 기본적으로 제공되는 Passport 지원은 더 이상 사용되지 않고 지원되지도 않습니다. 따라서 System.Web.Security에서 Passport와 관련된 형식은 이제 ObsoleteAttribute 특성으로 표시됩니다.

System.Web.Security 네임스페이스의 Passport 형식(예: System.Web.Security.PassportIdentity)을 사용하는 코드에서 Windows Live ID SDK가 사용되도록 코드를 변경합니다.

요청 유효성 검사

요청 유효성 검사를 개선하기 위해 ASP.NET 요청 유효성 검사는 요청 수명 주기의 초기 단계에 호출됩니다. 따라서 요청 유효성 검사는 .aspx 파일이 아닌 웹 서비스 호출 및 사용자 지정 처리기 등에 대한 요청을 대상으로 실행됩니다. 요청 유효성 검사는 사용자 지정 HTTP 모듈이 요청 처리 파이프라인에서 실행 중인 경우에도 활성화됩니다.

이 변경 사항으로 인해 .aspx 파일 이외의 리소스에 대한 요청은 요청 유효성 검사 오류를 throw할 수도 있습니다. 요청 파이프라인에서 실행되는 사용자 지정 코드(예: 사용자 지정 HTTP 모듈) 또한 요청 유효성 검사 오류를 throw할 수 있습니다.

필요한 경우 웹 구성 파일에서 다음 설정을 사용하여 .aspx 페이지만 요청 유효성 검사를 트리거하도록 하는 이전 동작으로 돌아갈 수 있습니다.

<httpRuntime requestValidationMode="2.0" />

보안 정보

이전 동작으로 되돌리려면 기존 처리기, 모듈 및 기타 사용자 지정 코드의 모든 코드에서 XSS 공격 벡터가 될 수 있는 잠재적으로 안전하지 않은 HTTP 입력을 확인해야 합니다.

SharePoint 사이트

이름이 WSS_Minimal인 사용자 지정 부분 신뢰 수준이 포함된 SharePoint 웹 사이트의 자식으로 배포된 ASP.NET 4 웹 사이트를 실행하려는 경우 다음 오류가 나타납니다.

Could not find permission set named 'ASP.Net'.

현재 ASP.NET과 호환되는 SharePoint 버전은 없습니다. 따라서 ASP.NET 4 웹 사이트를 SharePoint 웹 사이트의 자식으로 실행해서는 안 됩니다.

CardSpace

Windows CardSpace는 더 이상 .NET Framework에 포함되지 않고 개별적으로 제공됩니다.

Microsoft 다운로드 센터에서 Windows CardSpace를 다운로드하십시오.

C# 코드 컴파일러

Microsoft.CSharp 네임스페이스에 있던 Compiler, CompilerError 및 ErrorLevel 클래스는 더 이상 사용할 수 없으며 해당 어셈블리(cscompmgd.dll)는 더 이상 .NET Framework에 포함되지 않습니다.

System.CodeDom.Compiler 네임스페이스에 있는 CodeDomProvider 클래스 및 기타 클래스를 사용하십시오. 자세한 내용은 CodeDOM 사용을 참조하십시오.

새 보안 모델

.NET Framework 4의 보안 변경 내용에 설명된 대로 CAS(코드 액세스 보안) 정책이 사용되지 않고 간단한 모델로 대체되었습니다.

응용 프로그램에서 CAS를 사용하는 경우에는 수정이 필요할 수 있습니다. 자세한 내용은 코드 액세스 보안 정책 호환성 및 마이그레이션을 참조하십시오.

일광 절약 시간

시스템 시계와 시간을 맞추기 위해 시간 속성(예: TimeZoneInfo.Local 및 DateTime.Now)은 이제 다른 .NET Framework 데이터 대신 운영 체제 규칙을 일광 절약 시간 운영에 사용합니다.

없음

문화권 이름

다음과 같은 이름 변경 사항은 독일어, 디베히어 및 아프리카어 문화권에 영향을 줍니다.

• CurrencyEnglishName: 독일어(스위스)(de-CH) 문화권의 통화 이름이 "sFr."에서 "Fr."로 변경되었습니다.

• LongDatePattern: 디베히어(몰디브)(dv-MV) 문화권의 긴 날짜 형식이 "dd/MMMM/yyyy"에서 "dd/MM/yyyy"로 변경되었습니다.

• PMDesignator: 아프리칸스어(남아프리카 공화국)(af-AZ) 문화권의 P.M. 지정자가 "nm"에서 "PM"으로 변경되었습니다.

문화권 이름 변경 사항에 유의하십시오.

더 이상 사용되지 않는 문화권 형식

FrameworkCultures 및 WindowsOnlyCultures 문화권 형식은 이제 사용되지 않습니다.

이전 버전과의 호환성을 위해 이제 FrameworkCultures는 이전 .NET Framework에 포함되어 있는 중립적인 특정 문화권을 반환하고, WindowsOnlyCultures는 빈 목록을 반환합니다.

CultureTypes 열거형의 다른 값을 사용합니다.

Unicode 5.1 표준

이제 .NET Framework에서는 Unicode 5.1 문자를 모두 지원하여 추가로 약 1400개의 문자가 더 지원됩니다. 추가되는 문자로는 새 기호, 화살표, 분음 부호, 구두점, 수학 기호, 한중일 스트로크, 표의문자, 말라얄람어 및 텔루구어 수치 문자 및 다양한 미얀마 문자, 라틴 문자, 아랍 문자, 그리스 문자, 몽골 문자, 키릴 문자 등이 있습니다. 순다 문자, 렙차 문자, 올 치키 문자, 바이 문자, 사우라슈트라 문자, 카야 리 문자, 레장 문자, 참족 문자, 굴목키 문자, 오리야 문자, 타밀 문자, 텔루구 문자, 말라얄람 문자 및 참족 문자 같은 새로운 스크립트도 Unicode 5.1에서 지원됩니다.

없음

손상된 프로세스 상태의 예외

CLR은 더 이상 손상된 프로세스 상태의 예외를 관리 코드의 예외 처리기에 전달하지 않습니다.

이러한 예외는 프로세스 상태가 손상되었음을 나타냅니다. 이 상태에서 응용 프로그램을 실행하지 않는 것이 좋습니다.

자세한 내용은 CLR Inside Out 블로그의 손상된 상태 예외 처리 항목 및 HandleProcessCorruptedStateExceptionsAttribute를 참조하십시오.

어셈블리 해시 알고리즘

참조되는 어셈블리가 로드될 때 해당 어셈블리의 해시 알고리즘을 런타임에서 알지 못하기 때문에 AssemblyName.HashAlgorithm 속성은 이제 AssemblyHashAlgorithm.None을 반환합니다. 이는 Assembly.GetReferencedAssemblies 메서드 등에서 반환하는 참조되는 어셈블리에 대해 이 속성을 사용하는 경우를 가리킵니다.

없음

선언 형식

이제 Type.DeclaringType 속성은 해당 형식에 선언 형식이 없는 경우 올바르게 null을 반환합니다.

없음

전역 어셈블리 캐시 위치 변경 사항

.NET Framework 4 어셈블리의 경우 전역 어셈블리 캐시가 Windows 디렉터리(%WINDIR%)에서 Microsoft.Net 하위 디렉터리(%WINDIR%\Microsoft.Net)로 이동되었습니다. 이전 버전의 어셈블리는 이전과 동일한 디렉터리에 계속 있습니다.

관리되지 않는 ASM_CACHE_FLAGS 열거형에는 새로운 ASM_CACHE_ROOT_EX 플래그가 포함됩니다. 이 플래그는 .NET Framework 4 어셈블리의 캐시 위치를 가져옵니다. 이 위치는 GetCachePath 함수를 통해 반환될 수 있습니다.

없음(권장되지는 않지만 응용 프로그램에서 어셈블리의 명시적 경로를 사용하지 않는 경우를 가정)

버퍼 길이

(관리되지 않는 API)

메모리를 절약하기 위해 ICorProfilerInfo2::GetStringLayout 메서드의 pBufferLengthOffset 매개 변수는 pStringLengthOffset 매개 변수와 일치하도록 기능이 변경되었습니다. 이제 두 매개 변수 모두 문자열 길이의 오프셋 위치를 가리킵니다. 버퍼 길이는 문자열 클래스의 표현에서 제거되었습니다.

버퍼 길이에 대한 종속성이 있으면 이를 모두 제거합니다.

플랫폼 호출

플랫폼 호출에서 잘못된 호출 규칙이 사용되면 이제는 비관리 코드와의 상호 운용성을 향상시키기 위하여 응용 프로그램이 실패합니다. 이전 버전에서는 스택 위쪽에 있는 마샬링 계층이 이러한 오류를 해결했습니다.

Microsoft Visual Studio 2010에서 응용 프로그램을 디버깅하면 이러한 오류에 대한 경고가 나타나므로 해당 오류를 해결할 수 있습니다.

업데이트할 수 없는 이진 파일이 있으면 응용 프로그램의 구성 파일에 <NetFx40_PInvokeStackResilience> 요소를 포함하여 이전 버전과 같이 호출 오류가 스택 위쪽에서 해결되도록 하면 됩니다. 그러나 이렇게 하면 응용 프로그램의 성능에 영향을 미칠 수도 있습니다.

POCO 시나리오

System.Data.Objects.DataClasses.IRelatedEnd 인터페이스에는 POCO(Plain Old CLR Object) 시나리오에서의 유용성을 향상시키는 새 메서드가 있습니다. 이러한 새 메서드는 IEntityWithRelationships 엔터티 대신 Object를 매개 변수로 사용합니다.

이벤트

이제 DataRowView.PropertyChanged 이벤트는 열이 수정되고 있거나 RejectChanges 메서드가 호출되면 발생합니다. 이와 같이 변경되었기 때문에 DataSet 개체의 내용을 노출하는 UI 컨트롤을 보다 쉽게 만들 수 있습니다.

뷰 매핑

이제 쿼리 뷰 매핑 오류는 런타임에 NullReferenceException을 throw하지 않고 디자인 타임에 catch됩니다.

매핑 유효성 검사는 이제 CSDL(개념 스키마 정의 언어)의 두 연결 집합이 동일한 열에 매핑되는 오류를 catch합니다.

엔터티 개체

이제는 ObjectContext.SaveChanges 메서드가 호출될 때 ObjectContext.Detach 메서드와 엔터티 개체의 상태 사이에 패리티가 있습니다. 이에 따라 일관성이 향상되어 예기치 않은 예외가 throw되지 않습니다.

구조적 주석

이제 Entity Framework에서는 구조적 주석을 인식합니다.

이벤트

이제 System.Data.Linq.EntitySet<TEntity> 컬렉션은 EntitySet<TEntity>이 로드된 경우는 물론 언로드된 경우에도 ListChanged 이벤트를 발생시킵니다.

일괄 처리되는 이진 내용

이제 WCF Data Services는 요청 및 응답에서 일괄 처리되는 이진 내용을 지원합니다.

예외

이제 다음과 같은 상황에서는 NullReferenceException 대신 보다 유용한 예외가 throw됩니다.

• 데이터 서비스에 대한 호출이 시간 초과되는 경우에 TimeoutException

• 데이터 서비스에 대한 잘못된 요청이 있는 경우에 DataServiceRequestException

새 예외를 catch하도록 응용 프로그램에서 예외 처리를 변경해야 합니다.

JSON 판독기

이제 JSON(JavaScript Object Notation) 판독기는 WCF 데이터 서비스로 보낸 JSON 페이로드를 처리할 때 단일 백슬래시("\") 이스케이프 문자를 읽는 경우 올바르게 오류를 반환합니다.

요청

DataService<T>.OnStartProcessingRequest 메서드는 이제 데이터 서비스에 대한 요청이 처리되기 전에 호출됩니다. 따라서 요청이 ServiceOperation 서비스에 대해 올바르게 작동할 수 있습니다.

URI

WCF Data Services 클라이언트에 의한 URI 이스케이프의 문제점이 해결되었습니다.

구성 파일

구성 파일 계층 구조를 통해 동작이 상속되도록 하기 위해 WCF에서는 이제 구성 파일 간 병합을 지원합니다.

구성 상속 모델은 컴퓨터에서 실행되는 모든 서비스에 적용될 동작을 사용자가 정의할 수 있게 확장되어 있습니다.

동작과 관련한 변경 사항은 동일한 이름의 여러 동작이 계층 구조의 서로 다른 수준에 있는 경우에 확인할 수 있습니다.

예외 처리

오류가 보다 일찍 감지되도록 하기 위해 PF에서는 원래의 예외를 catch하는 대신 TargetInvocationException을 throw하고 InnerException 속성을 중대한 예외(예: NullReferenceException, OutOfMemoryException, StackOverflowException 및 SecurityException 예외)로 설정합니다.

없음

부분 신뢰 응용 프로그램

부분 신뢰 환경에서 실행되고 HTML을 포함하는 WebBrowser 컨트롤 또는 Frame 컨트롤이 들어 있는 Windows 기반 응용 프로그램에서는 컨트롤을 만들 때 보안을 향상시키기 위해 SecurityException을 throw합니다.

브라우저 응용 프로그램은 다음 조건이 모두 충족될 경우 예외를 throw하고 메시지를 표시합니다.

• Firefox에서 응용 프로그램을 실행 중인 경우

• 응용 프로그램이 신뢰할 수 없는 사이트의 인터넷 영역에서 부분 신뢰로 실행되고 있는 경우

• 응용 프로그램에 HTML을 포함하는 WebBrowser 컨트롤 또는 Frame 컨트롤이 있는 경우

신뢰할 수 있는 사이트나 인트라넷 영역에서 실행되는 응용 프로그램은 영향을 받지 않습니다.

다음 중 하나를 수행하면 브라우저 응용 프로그램에서 이러한 변경의 영향을 줄일 수 있습니다.

• 브라우저 응용 프로그램을 완전 신뢰 환경에서 실행합니다.

• 고객에게 응용 프로그램 사이트를 신뢰할 수 있는 사이트 영역에 추가하도록 요청합니다.

• 고객에게 응용 프로그램을 Internet Explorer에서 실행하도록 요청합니다.

Windows 7

WPF 응용 프로그램이 Windows 7에서 잘 작동되도록 하기 위해 다음과 같은 사항이 개선되어 창의 동작에서 발견되던 문제점이 해결되었습니다.

• 도킹 및 제스처 상태는 이제 사용자 상호 작용에 기반하여 예상된 대로 작동합니다.

• 작업 표시줄 명령 계단식 창 배열, 창 가로 정렬 보기 및 창 세로 정렬 보기는 이제 올바르게 작동하고 적합한 속성을 업데이트합니다.

• 최대화 또는 최소화된 창의 Top, Left, Width 및 Height 속성은 이제 다른 값 대신 모니터를 기준으로 창의 올바른 복원 위치를 포함합니다.

없음

XPS 뷰어

WPF는 Microsoft XPSEP(XML Paper Specification Essentials Pack)를 포함하지 않습니다. XPSEP는 Windows 7 및 Windows Vista에 포함되어 있습니다.

.NET Framework 3.5 SP1이 설치되지 않은 Windows XP를 실행하는 컴퓨터에서 PrintDialog에 있는 것과 다른 WPF API를 사용하여 인쇄할 경우 WINSPOOL이 사용됩니다. 인쇄 중에 일부 프린터 기능이 보고되지 않고 일부 프린터 설정이 적용되지 않습니다.

필요하면 Microsoft XML Paper Specification Essentials Pack을 설치합니다.

대화 상자

안정성 향상을 위해 CommonDialog.ShowDialog 메서드는 Microsoft.Win32.FileDialog 컨트롤을 만든 동일한 스레드에서 호출됩니다.

동일한 스레드에서 FileDialog 컨트롤을 만들고 ShowDialog 메서드를 호출해야 합니다.

컬렉션의 항목

항목을 이동하거나 기본 컬렉션에 추가하면 CollectionView에서 CollectionView가 정렬되지 않은 경우와 동일한 상대적 위치에 항목이 표시됩니다. 따라서 항목 위치는 컬렉션 및 연결된 CollectionView 사이에서 일관성이 유지됩니다.

항목의 고정된 위치를 사용하는 대신 ItemContainerGenerator.ContainerFromItem 또는 CollectionView.IndexOf 메서드를 사용하여 CollectionView에서 항목의 위치를 찾습니다.

메뉴

메뉴 팝업에서 ClearType 텍스트를 사용할 수 있도록 ControlTemplate 클래스 및 MenuItem 컨트롤과 기타 컨트롤이 수정되었습니다.

응용 프로그램은 컨트롤 템플릿의 시각적 구조에 의존하지 않아야 합니다. ControlTemplate의 명명된 요소만 공용 계약에 포함됩니다. 응용 프로그램이 ControlTemplate에서 특정 개체를 찾아야 하는 경우 트리에서 개체의 고정된 위치를 사용하는 대신 시각적 트리에서 특정 형식을 검색합니다.

팝업

이제는 레이아웃을 전달하는 동안 CustomPopupPlacementCallback 대리자를 여러 번 호출할 수 있습니다.

CustomPopupPlacementCallback 대리자가 이전 위치를 기반으로 Popup의 위치를 계산하는 경우에는 popupSize, targetSize 또는 offset 매개 변수의 값이 변경된 경우에만 위치를 다시 계산합니다.

텍스트 상자

보안을 향상하기 위해 TextBoxBase.Copy 및 TextBoxBase.Cut 메서드는 부분 신뢰 환경에서 호출되는 경우 자동으로 실패하게 됩니다.

또한 부분 신뢰 환경에서는 TextBoxBase에서 상속되는 컨트롤에 대해 ApplicationCommands.Copy 또는 ApplicationCommands.Cut 속성을 프로그래밍 방식으로 실행할 수 없습니다. 하지만 사용자가 시작한 복사 및 잘라내기 명령(예: ButtonBase.Command 속성이 두 명령 중 하나에 바인딩되는 단추 클릭)은 작동합니다. 바로 가기 키 및 상황에 맞는 메뉴를 통한 표준 복사 및 잘라내기 명령은 부분 신뢰 환경에서 이전처럼 작동합니다.

ApplicationCommands.Copy 또는 ApplicationCommands.Cut 명령을 사용자가 시작한 작업(예: 단추 클릭)에 바인딩합니다.

비트맵 효과

BitmapEffect 클래스와 BitmapEffect 클래스에서 상속되는 클래스는 계속 남아 있지만 성능 향상을 위해 사용하지 못하도록 되어 있습니다. 다음과 같은 조건이 충족되는 경우 하드웨어 가속 렌더링 파이프라인을 사용하여 해당 효과가 렌더링됩니다.

• 응용 프로그램에서 반지름 속성이 100DIU보다 작게 설정된 BlurBitmapEffect 또는 DropShadowBitmapEffect를 사용하는 경우

• 응용 프로그램을 실행하는 컴퓨터의 비디오 카드가 픽셀 셰이더 2.0을 지원하는 경우

이러한 조건이 충족되지 않는 경우 BitmapEffect 개체는 아무런 효과가 없습니다.

또한 Visual Studio 2010에서는 BitmapEffect 개체 또는 하위 클래스가 발견될 경우 컴파일러 경고가 발생합니다.

PushEffect 메서드는 더 이상 사용되지 않는 것으로 표시됩니다.

레거시 BitmapEffect 및 파생 클래스 사용을 중지하고 대신 Effect: BlurEffect, DropShadowEffect 및 ShaderEffect에서 파생된 새 클래스를 사용합니다.

ShaderEffect 클래스에서 상속하여 고유한 효과를 만들 수도 있습니다.

이미지 디코딩

이미지를 디코딩할 수 없을 때 IOException이 처리되지 않는 경우를 방지하기 위해 BitmapSource 클래스는 이미지를 디코딩하지 않을 때 DecodeFailed 이벤트를 발생시킵니다.

IOException과 관련된 예외 처리를 모두 제거하고 DecodeFailed 이벤트를 사용하여 디코딩 실패를 확인합니다.

명령 인스턴스 바인딩

뷰-모델 기반 명령 인스턴스를 뷰 기반 입력 제스처에 바인딩하는 메커니즘을 제공하기 위해 InputBinding 클래스는 이제 DependencyObject가 아니라 Freezable로부터 상속됩니다. 다음 속성은 이제 종속성 속성입니다.

• Command

• CommandParameter

• CommandTarget

이러한 변경에 따른 결과는 다음과 같습니다.

• InputBinding 개체는 등록될 때 변경 가능한 상태로 유지되는 대신 고정 상태가 됩니다.

• DependencyObject 클래스의 제한 때문에 여러 스레드에서 인스턴스 수준의 InputBinding 개체에 액세스할 수 없습니다.

• Freezable 클래스의 제한 때문에 클래스 수준 입력 바인딩을 등록 이후에 변경할 수 없습니다.

• 뷰-모델에서 만들어진 명령 인스턴스에 대한 입력 바인딩을 지정할 수 없습니다.

바인딩을 변경하거나 고정하려는 경우 InputBinding 클래스의 개별 인스턴스를 개별 스레드에 만듭니다. 클래스 수준의 정적 InputBinding을 등록한 후에는 변경하지 마십시오.

데드 키 조합

WPF에서는 데드 키를 난독 처리하여 보이지 않는 문자를 생성하고, 대신 해당 키가 다음 문자 키와 결합되어 하나의 문자를 생성한다는 것을 나타냅니다. KeyDown 이벤트와 같은 키 입력 이벤트는 키가 데드 키인 경우 Key 속성을 DeadCharProcessed 값으로 설정하여 이를 보고합니다. 이 동작은 결합된 문자를 만드는 키보드 입력에 대해 응용 프로그램이 일반적으로 응답하지 않도록 설정되어 있기 때문에 예상되는 동작입니다.

결합된 문자의 일부인 데드 키를 읽을 응용 프로그램은 DeadCharProcessedKey 속성을 사용하여 난독 처리된 키를 가져올 수 있습니다.

뷰의 클래스 계층 구조

TreeViewAutomationPeer 및 TreeViewItemAutomationPeer 클래스는 FrameworkElementAutomationPeer 대신 ItemsControlAutomationPeer에서 상속됩니다.

TreeViewItemAutomationPeer 클래스에서 상속하고 GetChildrenCore 메서드를 재정의할 경우 새 TreeViewDataItemAutomationPeer 클래스에서 상속되는 개체를 반환해 보십시오.

메뉴 및 자식 개체

MenuItem 개체 이외의 자식을 포함하는 메뉴의 UI 자동화를 활성화하기 위해 GetChildrenCore 메서드는 이제 MenuItemAutomationPeer 개체 대신 자식 UIElement 개체의 AutomationPeer 개체를 반환합니다.

없음

Thumb

GetClassNameCore 메서드는 null 대신 값을 반환합니다. 따라서 Thumb 클래스에서 상속되는 GridSplitter 같은 컨트롤은 UI 자동화에 대한 이름을 보고합니다.

없음

태그 확장

태그 확장을 사용하여 속성을 설정하거나 컬렉션에서 항목을 만들 경우 WPF에서는 이제 특정 클래스의 MarkupExtension 개체를 반환하는 대신 MarkupExtension.ProvideValue 메서드의 값을 항상 올바르게 사용합니다. 태그 확장이 자기 자신을 반환하는 경우도 있습니다.

응용 프로그램이 이전 버전에서 MarkupExtension 개체를 반환했던 리소스에 액세스할 경우 MarkupExtension 개체 대신 ProvideValue에서 반환되는 개체를 참조합니다.

카멜레온 스키마

카멜레온 스키마가 여러 스키마와 함께 포함되어 있는 경우 데이터 손상을 방지하기 위해 카멜레온 스키마는 이제 올바르게 복제됩니다.

카멜레온 스키마는 대상 네임스페이스가 없는 스키마입니다. 이 스키마가 다른 XSD에 포함되어 있는 경우 가져온 스키마의 대상 네임스페이스를 갖게 됩니다. 이 스키마는 주로 일반적인 형식을 스키마에 포함하기 위해 사용됩니다.

네임스페이스 특성

데이터 손상을 방지하기 위해 XPathNavigator 개체는 이제 x:xmlns 특성의 로컬 이름을 올바르게 반환합니다.

스키마 유효성 검사

잘못된 스키마 유효성 검사를 방지하기 위해 XmlSchemaSet 클래스는 XSD 스키마가 올바르고 일관되게 컴파일되도록 합니다. 이러한 스키마에는 다른 스키마가 포함될 수 있습니다. 예를 들어 A.xsd는 C.xsd를 포함하는 B.xsd를 포함할 수 있습니다. 이러한 스키마 중 하나를 컴파일하면 이 종속성 그래프를 트래버스하게 됩니다.

URI

XElement.Load 메서드는 이제 LINQ 쿼리에서 올바른 BaseURI를 반환합니다.

네임스페이스 확인자

XmlReader.ReadContentAs 메서드는 해당 메서드에 전달되는 IXmlNamespaceResolver 확인자를 더 이상 무시하지 않습니다.

이전 버전에서는 지정된 네임스페이스 확인자가 무시되었고 대신 XmlReader가 사용되었습니다.

엔터티 참조

데이터 손상을 방지하기 위해 엔터티 참조는 더 이상 XML 특성에서 두 번 엔터티화되지 않습니다.

이전에는 사용자가 WriteEntityRef 메서드를 사용하여 xmlns 특성 또는 xml:lang이나 xml:space 특성에 엔터티를 쓰려고 하면 해당 엔터티가 출력에서 두 번 엔터티화되어 데이터가 손상되었습니다.

2010년 8월

웹 브라우저에서의 컨트롤 호스팅, 컴파일러 클래스 및 CodeDOM 및 전역 어셈블리 캐시 뷰어에 대한 문제가 추가되었습니다.

향상된 기능 관련 정보