문서를 영문으로 보려면 영문 확인란을 선택하세요. 마우스 포인터를 텍스트 위로 이동시켜 팝업 창에서 영문 텍스트를 표시할 수도 있습니다.
번역
영문
이 설명서는 보관되지만 유지 되지 않습니다.

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

Visual Studio 2010

업데이트: 2010년 8월

이 항목에서는 버그 수정, 표준 준수 및 보안 관련 변경 사항, 고객 의견에 따른 변경 사항 등을 포함하여 .NET Framework 버전 3.5 서비스 팩 1과 .NET Framework 버전 4 간의 마이그레이션 문제에 설명합니다. 이러한 변경 내용은 대부분 응용 프로그램에서 프로그래밍을 수정할 필요가 없습니다. 프로그래밍 수정이 필요한 변경 내용은 표의 권장 변경 사항 열을 참조하십시오.

이 항목에서는 다음 영역의 중요한 변경 사항에 대해 설명합니다.

이 항목의 문제에 대한 고급 수준의 개요를 보려면 .NET Framework 4 마이그레이션 가이드를 참조하십시오.

베타 2 이후의 마이그레이션 문제는 Migration Issues for .NET Framework 4 Applications: Beta 2 to RTM을 참조하십시오.

새 기능에 대한 자세한 내용은 .NET Framework 4의 새로운 기능을 참조하십시오.

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

기능

3.5 SP1과의 차이점

권장 변경 사항

브라우저 정의 파일

브라우저 정의 파일은 신규 및 업데이트된 브라우저와 장치에 대한 정보를 포함하도록 업데이트되었습니다. 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 명령줄 도구를 실행합니다. 자세한 내용은 http://www.asp.net/mobile 웹 사이트를 참조하십시오.

서로 다른 버전의 ASP.NET에서 실행되는 자식 응용 프로그램

구성 또는 컴파일 오류 때문에 이전 버전의 ASP.NET을 실행하는 응용 프로그램의 자식으로 구성된 ASP.NET 4 응용 프로그램이 시작하지 않을 수도 있습니다. 발생하는 실제 오류는 응용 프로그램이 IIS 6.0에서 실행 중인지 아니면 IIS 7 또는 IIS 7.5에서 실행 중인지에 따라 달라집니다.

구성 시스템에서 ASP.NET 4 응용 프로그램을 제대로 인식할 수 있도록 영향 받는 응용 프로그램의 구성 파일을 변경할 수 있습니다. 수행해야 하는 변경 작업에 대한 자세한 내용은 ASP.NET 웹 사이트에서 ASP.NET 4 Breaking Changes 문서의 "ASP.NET 4 Child Applications Fail to Start When Under ASP.NET 2.0 or ASP.NET 3.5 Applications" 단원을 참조하십시오.

ClientID 변경 사항

ASP.NET 4에 새로 도입된 ClientIDMode 설정을 사용하면 ASP.NET에서 HTML 요소의 id 특성을 생성하는 방식을 지정할 수 있습니다. 이전 버전의 ASP.NET에서는 기본 동작이 ClientIDModeAutoID 설정과 동일했지만 현재 버전에서의 기본 설정은 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" / >

CAS(코드 액세스 보안)

ASP.NET 3.5에 추가되었던 ASP.NET 2.0 NET 기능은 .NET Framework 1.1 및 .NET Framework 2.0 CAS(코드 액세스 보안) 모델을 사용합니다. 그러나 ASP.NET 4에서는 CAS 구현이 크게 달라졌습니다. 그 결과 전역 어셈블리 캐시에서 실행되는 신뢰할 수 있는 코드를 사용하는 부분 신뢰 ASP.NET 응용 프로그램은 여러 가지 보안 예외를 발생시키며 실패할 수도 있습니다. 시스템 수준의 정책에 대한 광범위한 수정이 필요한 부분 신뢰 ASP.NET 응용 프로그램 또한 보안 예외를 throw하며 실패할 수 있습니다.

다음 예제와 같이 trust 구성 요소의 새로운 legacyCasModel 특성을 사용하면 부분 신뢰 ASP.NET 4 응용 프로그램의 동작을 ASP.NET 1.1 및 2.0의 동작으로 되돌릴 수 있습니다.

<trust level= "Medium"

legacyCasModel="true" />

보안 정보보안 정보
그러나 이전 CAS 모델로 복귀하면 보안이 약화될 수도 있습니다.

새로운 ASP.NET 4 코드 액세스 보안 모델에 대한 자세한 내용은 ASP.NET 4 응용 프로그램의 코드 액세스 보안을 참조하십시오.

구성 파일

.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에서 일부 컨트롤은 사용되지 않도록 설정할 수 없는 태그를 생성했습니다. ASP.NET 4에서는 기본적으로 이 유형의 태그가 더 이상 생성되지 않습니다. 렌더링 변경 사항은 다음 컨트롤에 영향을 미칩니다.

  • Image ImageButton 컨트롤은 더 이상 border="0" 특성을 렌더링하지 않습니다.

  • BaseValidator 클래스 및 이 클래스로부터 상속되는 유효성 검사 컨트롤은 더 이상 빨간색 텍스트를 기본적으로 렌더링하지 않습니다.

  • HtmlForm 컨트롤은 name 특성을 렌더링하지 않습니다.

  • Table 컨트롤은 border="0" 특성을 더 이상 렌더링하지 않습니다.

사용자 입력을 처리하도록 설계되지 않은 컨트롤(예: Label 컨트롤)은 Enabled 속성이 false로 설정되어 있거나 컨테이너 컨트롤로부터 이 설정을 상속한 경우 더 이상 disabled="disabled" 특성을 렌더링하지 않습니다.

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

<pages controlRenderingCompatibilityVersion="3.5" />

기본 문서의 이벤트 처리기

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

<form action="Default.aspx" />

ASP.NET 4에서도 http://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"를 참조하십시오.

해시 알고리즘

ASP.NET에서는 암호화 및 해시 알고리즘을 함께 사용하여 폼 인증 쿠키 및 뷰 상태 같은 데이터를 안전하게 보호할 수 있게 합니다. 기본적으로 ASP.NET 4에서는 쿠키 및 뷰 상태에 대한 해시 작업에 HMACSHA256 알고리즘을 사용합니다. 이전 버전의 ASP.NET에서는 이 알고리즘보다 오래된 HMACSHA1 알고리즘이 사용되었습니다.

ASP.NET 2.0과 ASP.NET 4가 혼합된 응용 프로그램을 실행하기 때문에 폼 인증 쿠키 같은 데이터가 여러 .NET Framework 버전에 걸쳐 작동해야 하는 경우에는 Web.config 파일에 다음 설정을 추가하여 ASP.NET 4 웹 응용 프로그램이 오래된 HMACSHA1 알고리즘을 사용하도록 구성합니다.

<machineKey validation="SHA1" />

Internet Explorer에서 컨트롤 호스팅

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

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

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

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

HtmlEncode 및 UrlEncode 메서드

HttpUtility HttpServerUtility 클래스의 HtmlEncodeUrlEncode 메서드는 작은따옴표 문자(')를 다음과 같이 인코딩하도록 업데이트되었습니다.

  • HtmlEncode 메서드는 작은따옴표를 &#39;로 인코딩합니다.

  • UrlEncode 메서드는 작은따옴표를 %27로 인코딩합니다.

코드에서 HtmlEncodeUrlEncode 메서드가 사용되는 곳을 살펴보고 인코딩 변경으로 인한 다른 변경 사항이 응용 프로그램에 영향을 주지 않는지 확인합니다.

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"를 참조하십시오.

멤버 자격 형식

ASP.NET 멤버 자격에 사용된 일부 형식(예: System.Web.Security.MembershipProvider)은 System.Web.dll에서 System.Web.ApplicationServices.dll 어셈블리로 이동되었습니다. 클라이언트 및 확장 .NET Framework SKU의 형식 간 아키텍처 레이어 종속성을 해결하기 위해 해당 형식이 이동되었습니다.

이전 버전의 ASP.NET에서 업그레이드되어 이동된 멤버 자격 형식을 사용하는 클래스 라이브러리는 ASP.NET 4 프로젝트에서 사용될 때 컴파일되지 않을 수 있습니다. 이러한 경우 클래스 라이브러리 프로젝트의 참조를 System.Web.ApplicationServices.dll에 추가하십시오.

Menu 컨트롤 변경 사항

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

Web.config 파일의 모바일 어셈블리

이전 버전의 ASP.NET에서 System.Web.Mobile.dll 어셈블리에 대한 참조는 system.web/compilation에서 assemblies 섹션의 루트 Web.config 파일에 포함되었습니다. 성능을 향상시키기 위해 이 어셈블리에 대한 참조가 제거되었습니다.

참고참고
System.Web.Mobile.dll 어셈블리 및 ASP.NET 모바일 컨트롤은 ASP.NET 4에 포함되어 있지만 사용되지 않습니다.

이 어셈블리의 유형을 사용하려는 경우 어셈블리에 대한 참조를 루트 Web.config 파일 또는 응용 프로그램 Web.config 파일에 추가하십시오.

출력 캐싱

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"로 변경해도 됩니다.

페이지 구문 분석

ASP.NET 웹 페이지(.aspx 파일) 및 사용자 정의 컨트롤(.ascx 파일)의 페이지 파서는 이전 버전의 ASP.NET보다 ASP.NET 4에서 보다 엄격하며 이전 버전에서보다 더 많은 태그가 유효하지 않은 것으로 표시됩니다.

페이지가 실행할 때 발생한 오류 메시지를 확인하고 잘못된 태그로 인해 발생한 오류를 수정하십시오.

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가 사용되도록 코드를 변경합니다.

FilePath 속성의 PathInfo 정보

ASP.NET 4에서는 HttpRequest.FilePath, HttpRequest.AppRelativeCurrentExecutionFilePathHttpRequest.CurrentExecutionFilePath 같은 속성의 반환 값에 더 이상 PathInfo 값이 포함되지 않습니다. 대신 HttpRequest.PathInfoPathInfo 정보를 사용할 수 있습니다. 예를 들어 다음과 같은 URL 부분이 있는 경우를 가정해 봅니다.

/testapp/Action.mvc/SomeAction

이전 버전의 ASP.NET에서 System.Web.HttpRequest 속성은 다음 값을 가집니다.

ASP.NET 4에서 System.Web.HttpRequest 속성은 이 값 대신 다음 값을 가집니다.

코드에서 경로 정보를 반환하기 위해 System.Web.HttpRequest 클래스의 속성을 사용하는 부분이 있는지 살펴보고 경로 정보 반환 방식의 변경 사항이 반영되도록 코드를 변경합니다.

요청 유효성 검사

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

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

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

<httpRuntime requestValidationMode="2.0" />

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

라우팅

Visual Studio 2010에서 파일 시스템 웹 사이트를 만드는 경우 폴더 이름에 점(.)이 포함된 폴더에 웹 사이트가 있으면 URL 라우팅이 안정적으로 작동하지 않습니다. 일부 가상 경로에서 HTTP 404 오류를 반환합니다. 이는 Visual Studio 2010이 루트 가상 디렉터리의 잘못된 경로를 사용하여 Visual Studio 개발 서버(Cassini)를 시작하기 때문입니다.

  • 파일 기반 웹 사이트의 속성 페이지에서 가상 경로 특성을 "/"로 변경합니다.

    또는

  • 웹 사이트 프로젝트가 아닌 웹 응용 프로그램 프로젝트를 만듭니다. 웹 응용 프로그램 프로젝트에는 이 문제가 없으며 프로젝트 폴더 이름에 점이 있더라도 URL 라우팅이 작동합니다.

    또는

  • IIS에 호스팅된 HTTP 기반 웹 사이트를 만듭니다. IIS에 호스팅된 웹 사이트는 웹 프로젝트 폴더뿐 아니라 가상 경로에 점을 포함할 수 있습니다.

SharePoint 사이트

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

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

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

XHTML 1.1 표준

새 웹 사이트에서 XHTML 1.1을 따르도록 하기 위해 .NET Framework 4의 ASP.NET 컨트롤은 XHTML 1.1 호환 HTML을 생성합니다. 이 렌더링은 Web.config 파일의 다음 옵션을 사용하여 설정됩니다.

<system.Web>

<pages controlRenderingCompatibilityVersion="4.0"/>

</system.Web>

기본적으로 이 옵션은 4.0으로 설정됩니다. Visual Studio 2008에서 Visual Studio로 업그레이드하는 웹 프로젝트에는 호환성을 위해 3.5가 설정되어 있습니다.

없음

맨 위로 이동

일반 기능

기능

3.5 SP1과의 차이점

권장 변경 사항

CardSpace

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

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

구성 파일

.NET Framework에서 응용 프로그램 구성 파일에 액세스하는 방법이 수정되었습니다.

응용 프로그램 구성 파일의 이름이 application-name.config인 경우 이름을 application-name.exe.config로 변경하십시오. 예를 들어 이름을 MyApp.config에서 MyApp.exe.config로 변경합니다.

C# 코드 컴파일러

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

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

호스팅

(관리되지 않는 API)

호스팅 기능을 개선하기 위해 일부 호스팅 활성화 API가 더 이상 사용되지 않습니다. In-Process Side-by-Side 실행 기능은 여러 버전의 .NET Framework를 동일한 프로세스에서 로드 및 시작할 수 있습니다. 예를 들어, .NET Framework 2.0 SP1 기반의 추가 기능(또는 구성 요소)과 .NET Framework 4 기반의 추가 기능을 동일한 프로세스에 로드하는 응용 프로그램을 실행할 수 있습니다. 이전 구성 요소는 계속해서 이전 .NET Framework 버전을 사용하고, 새 구성 요소는 새 .NET Framework 버전을 사용합니다.

In-Process Side-by-Side 실행 에 설명된 구성을 사용합니다.

새 보안 모델

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

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

맨 위로 이동

날짜 및 시간

네임스페이스: System, 어셈블리: mscorlib(mscorlib.dll)

기능

3.5 SP1과의 차이점

권장 변경 사항

일광 절약 시간

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

없음

문자열 형식 지정

문화권별 형식 지정을 지원하기 위해 TimeSpan 구조체에 새로운 ParseExactTryParseExact 메서드와 ToString, ParseTryParse 메서드의 새로운 오버로드가 포함되어 있습니다.

없음

맨 위로 이동

전역화

새로운 중립 및 특정 문화권 목록은 전역화 및 지역화의 새로운 기능을 참조하십시오.

네임스페이스: System.Globalization, 어셈블리: mscorlib(mscorlib.dll)

기능

3.5 SP1과의 차이점

권장 변경 사항

문화권 이름

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

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

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

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

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

LCID 매개 변수

자동화 서버 설정에서 예상되는 동작과 일관되도록 CLR은 더 이상 LCID 매개 변수의 현재 문화권을 관리되지 않는 COM 기반 응용 프로그램에 전달하지 않습니다. 대신 문화권으로 1033(en-us)을 전달합니다.

지정된 문화권이 있어야 하는 네이티브 응용 프로그램이 아니라면 수정은 전혀 필요하지 않습니다.

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

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

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

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

문화권 검색

Windows 7부터는 .NET Framework 4에서 문화권 정보 자체를 저장하는 대신 운영 체제로부터 해당 데이터를 가져옵니다. 또한 .NET Framework에서는 데이터 정렬 및 대/소문자 구분을 위해 Windows와 동기화합니다.

없음

Unicode 5.1 표준

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

없음

맨 위로 이동

예외

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

기능

3.5 SP1과의 차이점

권장 변경 사항

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

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

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

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

실행 엔진 예외

catch할 수 있는 예외는 안정되지 않은 프로세스가 계속 실행되도록 허용하기 때문에 이제 ExecutionEngineException은 더 이상 사용되지 않습니다. 이 변경 사항은 런타임에서 예측 가능성과 안정성을 향상시킵니다.

InvalidOperationException 을 사용하여 상태를 알립니다.

맨 위로 이동

리플렉션

네임스페이스: System.Reflection, 어셈블리: mscorlib(mscorlib.dll)

기능

3.5 SP1과의 차이점

권장 변경 사항

어셈블리 해시 알고리즘

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

없음

어셈블리 로딩

어셈블리의 중복 로드를 방지하고 가상 주소 공간을 절약하기 위해 이제 CLR에서는 Win32 MapViewOfFile 함수만 사용하여 어셈블리를 로드합니다. 또한 더 이상 LoadLibrary 함수를 호출하지 않습니다.

이 변경 사항은 진단 응용 프로그램에 다음과 같이 영향을 미칩니다.

  • ProcessModuleCollection Process.GetCurrentProcess().Modules에 대한 호출을 통해 가져오는 클래스 라이브러리(.dll 파일)의 모듈을 더 이상 포함하지 않습니다.

  • EnumProcessModules 함수를 사용하는 Win32 응용 프로그램에게는 관리되는 모듈 중 일부가 나열되지 않습니다.

없음

선언 형식

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

없음

대리자

이제 대리자는 null 값이 대리자의 생성자에 전달되면 NullReferenceException 대신 ArgumentNullException을 throw합니다.

예외 처리에서 ArgumentNullException이 catch되는지 확인하십시오.

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

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

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

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

전역 어셈블리 캐시 도구

Gacutil.exe(전역 어셈블리 캐시 도구) 는 더 이상 셸 플러그 인 뷰어를 지원하지 않습니다.

없음

상호 운용성

네임스페이스: System.Runtime.InteropServices, 어셈블리: mscorlib(mscorlib.dll)

기능

3.5 SP1과의 차이점

권장 변경 사항

버퍼 길이

(관리되지 않는 API)

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

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

JIT 디버깅

JIT(Just-In-Time) 디버깅 등록을 단순화하기 위해 이제 .NET Framework 디버거는 네이티브 코드에 대한 JIT 디버깅 동작을 제어하는 AeDebug 레지스트리 키만 사용합니다. 이러한 변경에 따른 결과는 다음과 같습니다.

  • 더 이상 관리 코드와 네이티브 코드별로 서로 다른 두 디버거를 등록할 수 없습니다.

  • 더 이상 비대화형 프로세스를 위해 디버거를 자동으로 시작할 수 없지만 사용자에게 대화형 프로세스에 대해 알릴 수는 있습니다.

  • 디버거가 시작하지 못하거나 시작되어야 할 디버거가 등록되어 있지 않는 경우 더 이상 사용자에게 알리지 않습니다.

  • 응용 프로그램의 대화형 기능에 의존하는 자동 시작 정책은 더 이상 지원되지 않습니다.

필요한 경우 디버깅 작업을 조정하십시오.

플랫폼 호출

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

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

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

제거된 인터페이스

(관리되지 않는 API)

개발자에게 혼란을 주지 않기 위해 다음 인터페이스가 제거되었습니다. 이러한 인터페이스는 유용한 런타임 시나리오를 전혀 제공하지 않고 CLR에서 구현을 제공하거나 받아들이지 않기 때문입니다.

  • INativeImageINativeImageDependency

  • INativeImageInstallInfo

  • INativeImageEvaluate

  • INativeImageConverter

  • ICorModule

  • IMetaDataConverter

없음

맨 위로 이동

이 단원에서는 데이터 집합 및 SQL 클라이언트, Entity Framework, LINQ to SQL 및 WCF Data Server(이전의 ADO.NET Data Services) 사용과 관련된 마이그레이션 문제를 설명합니다.

DataSet 및 SQL 클라이언트

다음 표에서는 이전에 제한되거나 문제가 되었던 기능의 향상된 점에 대해 설명합니다.

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

기능

3.5 SP1과의 차이점

POCO 시나리오

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

행 편집

DataView 클래스에서 구현하는 IndexOf 메서드는 이제 -1을 반환하지 않고 편집 중인 행의 값을 올바르게 반환합니다.

이벤트

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

예외

연결이 설정되지 않거나 열리지 않은 경우 Prepare 메서드는 이제 NullReferenceException 대신 InvalidOperationException을 throw합니다.

뷰 매핑

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

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

트랜잭션

트랜잭션 완료(중단 또는 롤백 포함) 이후 연결된 상태에서 문을 실행하려고 하는 경우 이제는 InvalidOperationException이 throw됩니다. 이전 버전에서는 예외가 throw되지 않았고, 트랜잭션이 중단된 경우에도 추가로 명령을 실행할 수 있었습니다.

맨 위로 이동

Entity Framework

다음 표에서는 이전에 제한되거나 문제가 되었던 기능의 향상된 점에 대해 설명합니다.

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

기능

3.5 SP1과의 차이점

엔터티 개체

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

Entity SQL

Entity SQL에서 식별자 확인을 위해 규칙이 개선되었습니다.

Entity SQL 파서는 다중 파트 식별자를 확인할 수 있게 논리가 개선되었습니다.

구조적 주석

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

쿼리

쿼리가 다음과 같이 개선되었습니다.

  • 빈 컬렉션에 대해 null 키를 사용하는 GroupBy 쿼리는 해당 쿼리에 추가적인 select가 있어도 행을 전혀 반환하지 않습니다.

  • LINQ 및 Entity-SQL 쿼리에 생성된 SQL은 이제 문자열 매개 변수를 기본적으로 유니코드가 아닌 값으로 간주합니다.

맨 위로 이동

LINQ to SQL

다음 표에서는 이전에 제한되거나 문제가 되었던 기능의 향상된 점에 대해 설명합니다.

네임스페이스: System.Data.Linq, 어셈블리: System.Data.Linq(System.Data.Linq.dll)

기능

3.5 SP1과의 차이점

이벤트

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

쿼리

Skip(0)은 LINQ to SQL 쿼리에서 더 이상 무시되지 않습니다. 따라서 이 메서드를 포함한 쿼리는 다르게 동작할 수 있습니다. 예를 들어 경우에 따라 OrderBy 절은 Skip(0)과 함께 사용해야 하며 OrderBy 절이 포함되지 않은 경우 쿼리에서 NotSupportedException 예외를 throw합니다.

맨 위로 이동

WCF 데이터 서비스(WCF Data Services)

다음 표에서는 이전에 제한되거나 문제가 되었던 기능의 향상된 점에 대해 설명합니다.

네임스페이스: 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)

기능

3.5 SP1과의 차이점

일괄 처리되는 이진 내용

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

변경 인터셉터

이제 변경 인터셉터는 삭제 요청에 대해 실행됩니다.

변경 인터셉터는 엔터티 집합의 엔터티를 수정하기 위한 요청을 서버가 받을 때마다 실행되는 메서드입니다. 이 메서드는 들어오는 요청이 처리되기 전에 실행됩니다. 변경 인터셉터는 변경되고 있는 엔터티 및 해당 엔터티에 대해 수행되고 있는 작업에 대한 액세스를 제공합니다.

예외

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

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

Headers

헤더가 다음과 같이 개선되었습니다.

  • 이제 WCF Data Services는 지정되지 않은 값이 있는 eTag 헤더를 제대로 거부합니다.

  • 이제 WCF Data Services는 요청에 if-* 헤더가 포함되어 있으면 오류를 반환하고 링크에 대한 삭제 요청에 따라 요청을 실행하지 않습니다.

  • 이제 WCF Data Services는 클라이언트가 Accept 헤더에 지정한 형식(Atom, JSON)으로 오류를 클라이언트에 반환합니다.

JSON 판독기

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

병합

MergeOption 열거형이 다음과 같이 개선되었습니다.

  • AppendOnly 병합 옵션은 더 이상 클라이언트에 있는 엔터티를 데이터 서비스로부터의 이후 응답 결과로 수정하지 않습니다.

  • 이제 PreserveChanges 옵션은 동적 SQL과 저장 프로시저 기반 업데이트에서 차이점 없이 일관됩니다.

요청

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

스트림

WCF Data Services에서는 읽기 및 쓰기 작업을 위한 내부 스트림을 더 이상 닫지 않습니다.

URI

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

다음 표에서는 이전에 제한되거나 문제가 되었던 기능의 향상된 점에 대해 설명합니다.

기능

3.5 SP1과의 차이점

구성 파일

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

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

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

서비스 호스팅

이제는 요소 정의에 allowDefinition="MachineToApplication" 특성을 추가하여 서비스 수준에서 <serviceHostingEnvironment> 구성 요소를 지정할 수 없습니다.

서비스 수준에서 <serviceHostingEnvironment> 요소를 지정하는 것은 기술적으로 올바르지 않으며 일관되지 않은 동작을 유발합니다.

맨 위로 이동

응용 프로그램

네임스페이스: System.Windows, System.Windows.Controls, 어셈블리: PresentationFramework(PresentationFramework.dll)

기능

3.5 SP1과의 차이점

권장 변경 사항

예외 처리

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

없음

링크된 리소스

프로젝트 폴더 구조 이외의 위치에 있는 이미지 등의 리소스 파일은 응용 프로그램을 빌드할 때 쉽게 링크되도록 하기 위해 리소스의 파일 이름 대신 리소스 파일의 전체 경로를 리소스 ID로 사용합니다. 응용 프로그램에서 런타임에 파일을 찾을 수 있습니다.

없음

부분 신뢰 응용 프로그램

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

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

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

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

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

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

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

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

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

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

리소스 사전

리소스 사전에 정의되고 테마 수준 사전에 병합되는 Freezable 리소스는 테마 수준 리소스 사전을 개선하고 사전의 변경을 방지하기 위해 이제 항상 고정된 것으로 표시되므로 변경할 수 없습니다. 이는 freezable 리소스에 대한 예상 동작입니다.

테마 수준의 병합된 사전에 정의된 리소스를 수정하는 응용 프로그램은 리소스를 복제하고 복제본을 수정해야 합니다. 또는 ResourceDictionary에서 리소스가 쿼리될 때마다 새 복사본을 만들도록 리소스를 x:Shared="false"로 표시할 수 있습니다.

Windows 7

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

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

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

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

없음

창 스타일 및 투명성

AllowsTransparency true이고 WindowStateMinimized일 때 WindowStyleNone 이외의 값으로 설정하면 InvalidOperationException 예외가 throw됩니다.

AllowsTransparency true인 경우 WindowStyle을 변경해야 하면 Win32 SetWindowLongPtr 함수를 호출하면 됩니다.

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을 설치합니다.

맨 위로 이동

컨트롤

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

기능

3.5 SP1과의 차이점

권장 변경 사항

대화 상자

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

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

부동 창

부동 창을 잘못된 방식으로 계속 활성화하여 부동 창이 모달 대화 상자처럼 나타나게 하는 포커스 복원 논리를 수정하기 위해 이제는 후보가 부동 창의 자식인 경우 포커스가 복원되지 않습니다.

없음

컬렉션의 항목

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

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

레이아웃

Page.ShowsNavigationUI 를 변경해도 더 이상 레이아웃이 무효화되거나 다른 레이아웃이 전달되지 않으므로 불필요하게 다시 레이아웃하지 않아도 됩니다.

다른 레이아웃이 전달되도록 ShowsNavigationUI를 변경할 경우 해당 속성을 설정한 후에 UIElement.InvalidateVisual을 호출합니다.

메뉴

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

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

탐색

Frame 이 위치를 직접 탐색하는 경우 초기 탐색 이후에 IsNavigationInitiator 속성이 true로 설정됩니다. 이와 같이 변경되었기 때문에 시작 시나리오 중에 다른 이벤트가 추가로 발생하지 않습니다.

없음

팝업

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

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

속성 값

이제 DependencyObject.SetCurrentValue 메서드를 사용하면 속성에 영향을 주는 바인딩, 스타일, 트리거 등을 그대로 유지하면서 속성을 유효 값으로 설정할 수 있습니다.

컨트롤 작성자는 사용자 조작 등 다른 작업의 파생 작업으로 인해 속성 값이 변경될 때마다 SetCurrentValue를 사용해야 합니다.

텍스트 상자

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

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

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

맨 위로 이동

그래픽

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

기능

3.5 SP1과의 차이점

권장 변경 사항

비트맵 효과

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

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

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

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

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

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

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

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

비트맵 프레임

복제된 BitmapFrame 개체는 이제 DownloadProgress, DownloadCompletedDownloadFailed 이벤트를 수신합니다. 따라서 웹에서 다운로드되고 Style을 통해 Image 컨트롤에 적용되는 이미지가 올바르게 작동합니다.

다음 경우에 모두 해당할 때만 동작의 변경이 나타납니다.

이벤트 처리기에서 sender를 확인하고 sender가 원본 BitmapFrame인 경우에만 조치를 수행합니다.

이미지 디코딩

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

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

맨 위로 이동

입력

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

기능

3.5 SP1과의 차이점

권장 변경 사항

명령 인스턴스 바인딩

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

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

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

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

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

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

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

브라우저 응용 프로그램

개체에서 라우트된 키 이벤트를 올바른 순서로 수신하도록 WPF 브라우저 응용 프로그램(XBAP)에서 이제 독립 실행형 WPF 응용 프로그램과 동일한 방법으로 키 이벤트를 처리합니다.

없음

데드 키 조합

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

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

포커스 관리자

FocusManager.GetFocusedElement 메서드에 IsFocusScope 연결 속성이 true로 설정된 요소가 전달되면 이 메서드는 반환되는 요소가 메서드에 전달되는 요소와 동일한 PresentationSource 개체에 속하는 경우에만 포커스 범위 내에서 키보드 포커스가 있는 마지막 요소를 반환합니다.

없음

맨 위로 이동

UI 자동화

네임스페이스: 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)

기능

3.5 SP1과의 차이점

권장 변경 사항

뷰의 클래스 계층 구조

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

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

화면에 표시되지 않는 컨테이너

잘못된 반환 값을 수정하기 위해 UIElementAutomationPeer.IsOffscreenCore 메서드는 이제 스크롤되어 보이지 않는 항목 컨테이너에 대해 올바르게 false를 반환합니다. 또한 다른 창이 요소를 가렸는지 여부 또는 요소가 특정 모니터에서 표시되는지 여부는 이 메서드의 값에 영향을 주지 않습니다.

없음

메뉴 및 자식 개체

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

없음

새 인터페이스 및 어셈블리

UI 자동화의 새 기능을 사용할 수 있도록 다음 인터페이스가 추가되었습니다.

WPF 자동화 피어를 빌드하는 프로젝트는 UIAutomationProvider.dll에 대한 명시적 참조를 추가해야 합니다.

Thumb

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

없음

가상화된 요소

성능 향상을 위해 UIElementAutomationPeer.GetChildrenCore 메서드는 가상화 여부와 상관없이 모든 자식 개체를 반환하지 않고 대신 시각적 트리에 실제로 있는 자식 개체만 반환합니다.

ItemContainerPattern 을 사용하여 ItemsControlAutomationPeer의 모든 항목을 반복합니다.

맨 위로 이동

XAML

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

기능

3.5 SP1과의 차이점

권장 변경 사항

태그 확장

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

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

특성 구문 분석

이제 XAML에서 특성에는 하나의 마침표만 사용할 수 있습니다. 다음은 유효한 특성 구문의 예입니다.

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

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

다음 특성 구문은 더 이상 유효하지 않습니다.

<Button Control.Button.Background = "Red"/>(마침표 2개 이상)

마침표가 2개 이상인 XAML 특성을 수정합니다.

맨 위로 이동

다음 표에서는 이전에 제한되거나 문제가 되었던 기능의 향상된 점에 대해 설명합니다.

스키마 및 변환

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

기능

3.5 SP1과의 차이점

카멜레온 스키마

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

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

ID 함수

XmlReader 개체가 XLST로 전달되는 경우 XSLT id 함수는 이제 null 대신 올바른 값을 반환합니다.

사용자가 CreateReader 메서드를 사용하여 LINQ to XML 클래스로부터 XmlReader 개체를 만든 경우 이 XmlReader 개체는 XSLT로 전달되었고 XSLT id 함수의 모든 인스턴스는 null을 반환했습니다. 이 값은 id 함수에 대해 허용되는 반환 값이 아닙니다.

네임스페이스 특성

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

네임스페이스 선언

하위 트리의 XmlReader 개체는 더 이상 단일 XML 요소 내에 중복되는 네임스페이스 선언을 만들지 않습니다.

스키마 유효성 검사

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

스크립트 함수

function-available function를 실제로 사용할 수 있는 경우 이 함수는 더 이상 false를 잘못 반환하지 않습니다.

URI

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

맨 위로 이동

유효성 검사

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

기능

3.5 SP1과의 차이점

네임스페이스 확인자

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

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

공백

판독기를 만들 때 데이터가 손실되지 않도록 하기 위해 XmlReader.Create 메서드는 더 이상 중요한 공백을 삭제하지 않습니다.

XML 유효성 검사에서는 텍스트가 XML 태그와 혼합될 수 있는 혼합 콘텐츠 모드를 인식합니다. 혼합 모드에서 모든 공백은 중요하며 반드시 보고되어야 합니다.

맨 위로 이동

쓰기

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

기능

3.5 SP1과의 차이점

엔터티 참조

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

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

줄 바꿈 처리

데이터 손상을 방지하기 위해 XmlWriter 개체는 None 옵션을 그대로 유지합니다.

맨 위로 이동

날짜

변경 내용

이유

2010년 8월

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

향상된 기능 관련 정보

표시: