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

2025-06-17

이 문서에서는 수정 사항, 표준 준수 및 보안에 대한 변경 내용, 고객 피드백에 따른 변경 내용을 포함하여 .NET Framework 버전 3.5 서비스 팩 1과 .NET Framework 버전 4 간의 마이그레이션 문제를 설명합니다. 이러한 변경 내용의 대부분은 애플리케이션에서 프로그래밍을 수정할 필요가 없습니다. 수정이 포함될 수 있는 항목은 테이블의 권장 변경 열을 참조하세요. 주목할 만한 변경 내용은 영역별로 세분화됩니다(예: ASP.NET 및 WPF(Windows Presentation Foundation)).

이 문서의 문제에 대한 자세한 개요는 .NET Framework 4에 대한 마이그레이션 가이드를 참조하세요.

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

ASP.NET 및 웹

네임스페이스: 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.Browse` 속성에 의해 노출되는 개체는 브라우저 정의 파일에 의해 구동됩니다. 따라서 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 .
혼합 버전의 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 자식 응용 프로그램이 ASP.NET 2.0 또는 ASP.NET 3.5 응용 프로그램 아래에서 시작되지 않는 경우" 섹션을 참조하세요.
ClientID 변경 내용	ASP.NET 4의 새 `clientIDMode` 설정을 사용하면 ASP.NET HTML 요소에 `id` 대한 특성을 생성하는 방법을 지정할 수 있습니다. 이전 버전의 ASP.NET의 기본 동작은 `AutoID` 설정과 `clientIDMode`에 해당합니다. 기본 설정은 이제 `Predictable`. 자세한 내용은 ASP.NET 웹 서버 컨트롤 식별을 참조하세요.	Visual Studio를 사용하여 ASP.NET 2.0 또는 ASP.NET 3.5에서 애플리케이션을 업그레이드하는 경우 도구는 이전 버전의 .NET Framework의 동작을 유지하는 설정을 Web.config 파일에 자동으로 추가합니다. 그러나 IIS에서 애플리케이션 풀을 .NET Framework 4를 대상으로 변경하여 애플리케이션을 업그레이드하는 경우 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 애플리케이션은 다양한 보안 예외로 인해 실패할 수 있습니다. 부분 신뢰 애플리케이션이 머신 CAS 정책에 대한 광범위한 수정을 의존할 경우, 실패하고 보안 예외를 발생시킬 수 있습니다.	다음 예제와 같이 구성 요소의 새 `legacyCasModel` 특성을 `trust` 사용하여 부분 신뢰 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에서 프로젝트 업그레이드 도구를 사용하여 ASP.NET 3.5 애플리케이션을 ASP.NET 4로 업그레이드합니다. Visual Studio 2010은 ASP.NET 4에 대한 적절한 설정을 포함하도록 ASP.NET 3.5 애플리케이션의 Web.config 파일을 자동으로 수정합니다. 그러나 다시 컴파일하지 않고 .NET Framework 4를 사용하여 ASP.NET 3.5 애플리케이션을 실행할 수 있습니다. 이 경우 .NET Framework 4 및 IIS 7 또는 IIS 7.5에서 애플리케이션을 실행하기 전에 애플리케이션의 Web.config 파일을 수동으로 수정해야 할 수 있습니다. 특정 변경 사항은 SP(서비스 팩) 릴리스를 포함하여 작업 중인 소프트웨어의 조합에 따라 달라집니다. 이 변경의 영향을 받는 가능한 소프트웨어 조합 및 특정 조합의 문제를 해결하는 방법에 대한 자세한 내용은 ASP.NET 웹 사이트의 문서 ASP.NET 4 호환성이 손상되는 변경 내용의 "새 ASP.NET 4 루트 구성과 관련된 구성 오류" 섹션을 참조하세요.
렌더링 제어	이전 버전의 ASP.NET 일부 컨트롤은 사용하지 않도록 설정할 수 없는 태그를 내보냅니다. 기본적으로 이 유형의 태그는 더 이상 ASP.NET 4에서 생성되지 않습니다. 렌더링 변경 내용은 다음 컨트롤에 영향을 줍니다. * `Image` 및 `ImageButton` 컨트롤은 더 이상 `border="0"` 특성을 렌더링하지 않습니다. `BaseValidator`* 파생되는 클래스 및 유효성 검사 컨트롤은 더 이상 기본적으로 빨간색 텍스트를 렌더링하지 않습니다. * `HtmlForm` 컨트롤이 `name` 특성을 렌더링하지 않습니다. 컨트롤은 더 이상 `Table` 속성을 `border="0"` 렌더링하지 않습니다. 사용자 입력을 위해 디자인되지 않은 컨트롤(예: `Label` 컨트롤)은 해당 `disabled="disabled"` 속성이 `Enabled`로 설정되어 있는 경우(또는 컨테이너 컨트롤에서 이 설정을 상속받은 경우) `false` 특성을 더 이상 표시하지 않습니다.	Visual Studio를 사용하여 ASP.NET 2.0 또는 ASP.NET 3.5에서 애플리케이션을 업그레이드하는 경우 도구는 레거시 렌더링을 유지하는 Web.config 파일에 설정을 자동으로 추가합니다. 그러나 IIS에서 애플리케이션 풀을 .NET Framework 4를 대상으로 변경하여 애플리케이션을 업그레이드하는 경우 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 변경 사항에서 "IIS 7 또는 IIS 7.5 통합 모드에서 기본 문서에 이벤트 처리기가 호출되지 않을 수 있음"을 참조하세요.
해시 알고리즘	ASP.NET 암호화 및 해시 알고리즘을 모두 사용하여 양식 인증 쿠키 및 상태 보기와 같은 데이터를 보호합니다. 기본적으로 ASP.NET 4는 쿠키 및 뷰 상태에 대한 해시 작업에 알고리즘을 사용합니다 HMACSHA256 . 이전 버전의 ASP.NET 이전 HMACSHA1 알고리즘을 사용했습니다.	양식 인증 쿠키와 같은 데이터가 .NET Framework 버전에서 작동해야 하는 ASP.NET 2.0 및 ASP.NET 4를 혼합하는 애플리케이션을 실행하는 경우 Web.config 파일에 다음 설정을 추가하여 이전 HMACSHA1 알고리즘을 사용하도록 ASP.NET 4 웹 애플리케이션을 구성합니다. `<machineKey validation="SHA1" />`
Internet Explorer에서 컨트롤 호스팅	웹에서 컨트롤을 호스팅하는 더 나은 솔루션이 있으므로 Internet Explorer에서 Windows Forms 컨트롤을 더 이상 호스트할 수 없습니다. 따라서 IEHost.dll 및 IEExec.exe 어셈블리가 .NET Framework에서 제거되었습니다.	웹 애플리케이션에서 사용자 지정 컨트롤 개발을 위해 다음 기술을 사용할 수 있습니다. * Silverlight 애플리케이션을 만들고 브라우저 외부에서 실행되도록 구성할 수 있습니다. 자세한 내용은 브라우저 외부 지원을 참조하세요. * XBAP(XAML 브라우저 애플리케이션)를 빌드하여 WPF 기능을 활용할 수 있습니다(클라이언트 컴퓨터에서 .NET Framework 필요). 자세한 내용은 WPF XAML 브라우저 애플리케이션 개요를 참조하세요.
HtmlEncode 및 UrlEncode 메서드	`HtmlEncode` 및 `UrlEncode`HttpUtility 클래스의 HttpServerUtility 메서드는 다음과 같이 작은따옴표 문자(')를 인코딩하도록 업데이트되었습니다. * 메서드는 `HtmlEncode` 작은따옴표의 인스턴스를 다음과 같이 인코딩합니다. `'` * 메서드는 `UrlEncode` 작은따옴표의 인스턴스를 다음과 같이 인코딩합니다. `%27`	코드에서 `HtmlEncode` 및 `UrlEncode` 메서드를 사용하는 위치를 검사하고, 인코딩 변경으로 인해 애플리케이션에 영향을 미치는 변경이 발생하지 않도록 확인하세요.
ASP.NET 2.0 애플리케이션의 HttpException 오류	IIS 6에서 ASP.NET 4를 사용하도록 설정한 후 IIS 6에서 실행되는 ASP.NET 2.0 애플리케이션(Windows Server 2003 또는 Windows Server 2003 R2)에서 다음과 같은 오류가 발생할 수 있습니다. `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 주요 변경 내용에서 "ASP.NET 2.0 애플리케이션에서 eurl.axd를 참조하는 HttpException 오류를 생성할 수 있음"을 참조하세요.
멤버 자격 유형	ASP.NET 멤버 자격에 사용되는 일부 형식(예: MembershipProvider)이 System.Web.dll에서 System.Web.ApplicationServices.dll 어셈블리로 이동하였습니다. 클라이언트의 형식과 확장된 .NET Framework SKU 간의 아키텍처 계층화 종속성을 확인하기 위해 형식이 이동되었습니다.	이전 버전의 ASP.NET 업그레이드되었으며 이동된 멤버 자격 유형을 사용하는 클래스 라이브러리는 ASP.NET 4 프로젝트에서 사용할 때 컴파일하지 못할 수 있습니다. 그렇다면 클래스 라이브러리 프로젝트에 System.Web.ApplicationServices.dll에 대한 참조를 추가하십시오.
메뉴 컨트롤 변경 내용	컨트롤을 변경하면 Menu 다음과 같은 동작이 발생합니다. * MenuRenderingMode이 `List`으로 설정되거나, MenuRenderingMode이 `Default`으로 설정되고 ControlRenderingCompatibilityVersion이 `4.0` 이상인 경우, PopOutImageUrl 속성은 영향을 미치지 않습니다. * 속성에 StaticPopOutImageUrl DynamicPopOutImageUrl 설정된 경로에 백슬래시(\)가 포함되어 있으면 이미지가 렌더링되지 않습니다. (이전 버전의 ASP.NET 경로에는 백슬래시를 포함할 수 있습니다.)	* 개별 메뉴 항목의 PopOutImageUrl 속성을 설정하는 대신 부모 StaticPopOutImageUrl 컨트롤을 DynamicPopOutImageUrl Menu 설정합니다. -또는- MenuRenderingMode을 `Table`로 설정하거나, MenuRenderingMode을 `Default`로 설정하고 ControlRenderingCompatibilityVersion을 `3.5`로 설정합니다. 이러한 설정으로 인해 컨트롤은 Menu 이전 버전의 ASP.NET 사용한 HTML 테이블 기반 레이아웃을 사용합니다. * 또는 StaticPopOutImageUrl 속성의 경로에 DynamicPopOutImageUrl 백슬래시(\)가 포함된 경우 슬래시 문자(/)를 대체합니다.
Web.config 파일의 모바일 어셈블리	이전 버전의 ASP.NET System.Web.Mobile.dll 어셈블리에 대한 참조가 아래 섹션의 루트 Web.config 파일에 `assemblies` 포함되었습니다`system.web`/`compilation`. 성능을 향상시키기 위해 이 어셈블리에 대한 참조가 제거되었습니다. 참고: System.Web.Mobile.dll 어셈블리 및 ASP.NET 모바일 컨트롤은 ASP.NET 4에 포함되지만 더 이상 사용되지 않습니다.	이 어셈블리의 형식을 사용하려면 루트 Web.config 파일 또는 애플리케이션 Web.config 파일에서 어셈블리에 대한 참조를 추가합니다.
출력 캐싱	ASP.NET 1.0에서 버그로 인해 출력 캐시 설정으로 지정된 캐시된 `Location="ServerAndClient"` 페이지가 응답에서 `Vary:` HTTP 헤더를 내보낸 것입니다. 이는 클라이언트 브라우저에 페이지를 로컬로 캐시하지 말라고 말하는 효과가 있었습니다. ASP.NET 1.1에서는 SetOmitVaryStar 메서드가 추가되었고, 이 메서드는 `Vary:` 헤더를 표시하지 않도록 호출할 수 있습니다. 그러나 버그 보고서에 따르면 개발자는 기존 `SetOmitVaryStar` 동작을 인식하지 못합니다. ASP.NET 4 `Vary:` 에서는 다음 지시문을 지정하는 응답에서 HTTP 헤더가 더 이상 내보내지지 않습니다. `<%@ OutputCache Location="ServerAndClient" %>` 따라서 SetOmitVaryStar 헤더를 없애기 위해 `Vary:` 메서드가 더 이상 필요하지 않습니다. 특성에 대해 "ServerAndClient" `Location` 를 지정하는 애플리케이션에서는 호출 SetOmitVaryStar할 필요 없이 브라우저에서 페이지를 캐시할 수 있습니다.	애플리케이션에서 페이지가 `Vary:`를 내보내야 할 경우, 다음 예제와 같이 AppendHeader 메서드를 호출하십시오. `System.Web.HttpResponse.AppendHeader("Vary","");` 또는 출력 캐싱 `Location` 특성의 값을 "Server"로 변경할 수 있습니다.
페이지 파싱	ASP.NET 웹 페이지(.aspx 파일) 및 사용자 컨트롤(.ascx 파일)의 페이지 파서는 ASP.NET 4에서 이전 버전의 ASP.NET 보다 더 엄격하며 이전 버전보다 더 많은 태그에 유효하지 않은 것으로 플래그를 지정합니다.	페이지가 실행될 때 생성되는 오류 메시지를 검사하고 잘못된 태그로 인한 오류를 수정합니다.
Passport 유형	ASP.NET 2.0에 기본 제공되는 Passport 지원은 사용되지 않으며 Passport(현재 라이브 ID SDK)의 변경으로 인해 지원되지 않습니다. 따라서 Passport와 관련된 System.Web.Security 안의 형식이 이제 `ObsoleteAttribute` 속성으로 표시됩니다.	System.Web.Security 네임스페이스에서 Passport 형식을 사용하는 모든 코드를 Windows Live ID SDK를 사용하도록 변경합니다 (예: PassportIdentity).
FilePath 속성의 PathInfo 정보	ASP.NET 4는 더 이상 `PathInfo` 값을 FilePath, AppRelativeCurrentExecutionFilePath, CurrentExecutionFilePath와 같은 속성의 반환 값에 포함하지 않습니다. 대신 `PathInfo` 정보는 PathInfo에서 사용할 수 있습니다. 예를 들어 다음 URL 조각을 가정해 보겠습니다. `/testapp/Action.mvc/SomeAction` 이전 버전의 ASP.NET HttpRequest 속성에는 다음 값이 있습니다. * FilePath: `/testapp/Action.mvc/SomeAction` * PathInfo: (비어 있음) ASP.NET 4 HttpRequest 에서는 속성에 다음 값이 대신 있습니다. * FilePath: `/testapp/Action.mvc` * PathInfo: `SomeAction`	경로 정보를 반환하기 위해 클래스의 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 개발 서버를 시작하므로 발생합니다.	* 파일 기반 웹 사이트의 속성 페이지에서 가상 경로 특성을 "/"로 변경합니다. -또는- * 웹 사이트 프로젝트 대신 웹 애플리케이션 프로젝트를 만듭니다. 웹 애플리케이션 프로젝트에는 이 문제가 없으며, 프로젝트 폴더의 이름에 점이 있더라도 URL 라우팅이 작동합니다. -또는- * IIS에서 호스트되는 HTTP 기반 웹 사이트를 만듭니다. IIS 호스팅 웹 사이트에는 가상 경로와 프로젝트 파일 폴더에 점이 있을 수 있습니다.
SharePoint 사이트	명명 `WSS_Minimal`된 사용자 지정 부분 신뢰 수준이 포함된 SharePoint 웹 사이트의 자식으로 배포된 ASP.NET 4 웹 사이트를 실행하려고 하면 다음 오류가 표시됩니다. `Could not find permission set named 'ASP.Net'.`	현재 SharePoint 버전이 ASP.NET 호환되지 않습니다. 따라서 sharePoint 웹 사이트의 자식으로 ASP.NET 4 웹 사이트를 실행하려고 시도해서는 안 됩니다.
XHTML 1.1 표준	새 웹 사이트에 XHTML 1.1 규정 준수를 사용하도록 설정하기 위해 .NET Framework 4의 ASP.NET 컨트롤은 XHTML 1.1 호환 HTML을 생성합니다. 이 렌더링은 요소 내의 Web.config 파일에서 다음 옵션을 사용하여 사용하도록 설정됩니다 `<system.Web>` . `<pages controlRenderingCompatibilityVersion="4.0"/>` 이 옵션은 기본적으로 4.0으로 설정됩니다. Visual Studio 2008에서 업그레이드된 웹 프로젝트에는 호환성을 위해 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# 코드 컴파일러	`Compiler`네임스페이스에 있던 `CompilerError` , `ErrorLevel`및 Microsoft.CSharp 클래스는 더 이상 사용할 수 없으며 해당 어셈블리(cscompmgd.dll)는 더 이상 .NET Framework에 포함되지 않습니다.	CodeDomProvider 클래스 및 기타 클래스를 System.CodeDom.Compiler 네임스페이스에서 사용합니다. 자세한 내용은 CodeDOM 사용을 참조하세요.
호스팅 (관리되지 않는 API)	호스팅 기능을 개선하기 위해 일부 호스팅 활성화 API는 더 이상 사용되지 않습니다. In-Process 병렬 실행 기능을 사용하면 애플리케이션이 동일한 프로세스에서 여러 버전의 .NET Framework를 로드하고 시작할 수 있습니다. 예를 들어 동일한 프로세스에서 .NET Framework 2.0 SP1 및 .NET Framework 4를 기반으로 하는 추가 기능을 기반으로 하는 추가 기능(또는 구성 요소)을 로드하는 애플리케이션을 실행할 수 있습니다. 이전 구성 요소는 이전 .NET Framework 버전을 계속 사용하고 새 구성 요소는 새 .NET Framework 버전을 사용합니다.	In-Process 병렬 실행에 설명된 구성을 사용합니다.
새 보안 모델	.NET Framework 4의 보안 변경 내용에 설명된 대로 CAS(코드 액세스 보안) 정책이 해제되고 간소화된 모델로 대체되었습니다.	애플리케이션에서 CAS를 사용하는 경우 수정이 필요할 수 있습니다. 자세한 내용은 코드 액세스 보안 정책 호환성 및 마이그레이션을 참조하세요.

날짜 및 시간

네임스페이스: System

어셈블리: mscorlib(in mscorlib.dll)

특징	3.5 SP1의 차이점	권장되는 변경 내용
일광 절약	시스템 클록과 일치하기 위해 시간 속성(예: Local 및 Now)은 이제 일광 절약 시간 작업에 다른 .NET Framework 데이터 대신 운영 체제 규칙을 사용합니다.	없음.
문자열 서식 지정	문화권에 민감한 서식을 지원하기 위해 TimeSpan 구조에는 `ToString`, `Parse`, 및 `TryParse` 메서드의 새로운 오버로드뿐만 아니라 새롭게 추가된 `ParseExact` 및 `TryParseExact` 메서드가 포함됩니다.	없음.

세계화

새로운 중립 및 특정 문화권 목록을 보려면 세계화 및 지역화의 새로운 정보를 참조하십시오.

네임스페이스: System.Globalization

어셈블리: mscorlib(in mscorlib.dll)

특징	3.5 SP1의 차이점	권장되는 변경 내용
문화권 이름	다음 이름 변경은 독일어, 디비 및 아프리카 문화권에 영향을 줍니다. * CurrencyEnglishName: 독일(스위스)(de-CH) 문화권의 통화 이름이 "sFr"에서 "Fr"으로 변경되었습니다. * LongDatePattern: Divehi(몰디브)(dv-MV) 문화권의 긴 날짜 패턴이 "dd/MMMM/yyyy"에서 "dd/MM/yyyy"로 변경되었습니다. * PMDesignator: 아프리칸스(남아프리카 공화국)(af-ZA) 문화권의 P.M. 지정자가 "nm"에서 "PM"으로 변경되었습니다.	문화권 이름 변경에 주의하세요.
LCID 매개 변수	자동화 서버 설정에서 예상되는 동작과 일치하기 위해 CLR은 더 이상 매개 변수의 `LCID` 현재 문화권을 관리되지 않는 COM 기반 애플리케이션에 전달하지 않습니다. 대신 문화 코드로 1033(en-us)을 전달합니다.	지정된 문화권이 필요한 네이티브 애플리케이션을 제외하고는 수정이 필요하지 않습니다.
구식의 문화 유형	CultureTypes 문화권 유형과 CultureTypes 문화권 유형은 이제는 구식입니다. 이전 버전과의 호환성을 위해, CultureTypes는 이전 .NET Framework에 포함된 중립 및 특정 문화권을 이제 반환하며, CultureTypes는 빈 목록을 반환합니다.	열거형의 CultureTypes 다른 값을 사용합니다.
문화 획득	Windows 7부터 .NET Framework 4는 데이터 자체를 저장하는 대신 운영 체제에서 문화권 정보를 검색합니다. 또한 .NET Framework는 데이터를 정렬하고 대/소문자 구분하기 위해 Windows와 동기화합니다.	없음.
유니코드 5.1 표준	.NET Framework는 이제 약 1,400자를 추가하여 모든 유니코드 5.1자를 지원합니다. 추가 문자에는 새로운 기호, 화살표, 발음, 문장 부호, 수학적 기호, CJK 스트로크 및 표기법, 추가 말라얄람어 및 텔루구어 숫자 문자, 다양한 미얀마어, 라틴어, 아랍어, 그리스어, 몽골어 및 키릴 자모 문자가 포함됩니다. 유니코드 5.1에서 지원되는 새로운 스크립트는 Sundanese, Lepcha, Ol Chiki, Vai, Saurashtra, Kayah Li, Rejang, Gurmukhi, Odia, Tamil, Telugu 및 Malayalam 문자 및 참입니다.	없음.

예외

네임스페이스: System, System.Runtime.ExceptionServices

어셈블리: mscorlib(in mscorlib.dll)

특징	3.5 SP1의 차이점	권장되는 변경 내용
손상된 프로세스 상태에 대한 예외	CLR은 더 이상 손상된 프로세스 상태에 대한 예외를 관리 코드의 예외 처리기에 제공하지 않습니다.	이러한 예외는 프로세스의 상태가 손상되었음을 나타냅니다. 이 상태에서 애플리케이션을 실행하는 것은 권장되지 않습니다. 자세한 내용은 MSDN 잡지의 HandleProcessCorruptedStateExceptionsAttribute 및 손상된 상태 예외 처리 항목을 참조하세요.
실행 엔진 예외	ExecutionEngineException 는 이제 사용되지 않습니다. 이는 포착 가능한 예외로 인해 불안정한 프로세스가 계속 실행될 수 있기 때문입니다. 이러한 변경으로 런타임의 예측 가능성과 안정성이 향상됩니다.	조건을 InvalidOperationException 신호로 보낼 수 있습니다.

성찰

네임스페이스: System.Reflection

어셈블리: mscorlib(in mscorlib.dll)

특징	3.5 SP1의 차이점	권장되는 변경 내용
어셈블리 해시 알고리즘	어셈블리가 로드되지 않은 경우 런타임이 참조된 어셈블리의 해시 알고리즘을 알 수 없기 때문에 이제 HashAlgorithm 속성이 AssemblyHashAlgorithm을 반환합니다. 이는 GetReferencedAssemblies 메서드가 반환한 것과 같은 참조된 어셈블리에서 속성을 사용하는 것을 의미합니다.	없음.
어셈블리 로딩	어셈블리의 중복 로드를 방지하고 가상 주소 공간을 절약하기 위해 CLR은 이제 Win32 `MapViewOfFile` 함수만 사용하여 어셈블리를 로드합니다. 더 이상 `LoadLibrary` 함수도 호출하지 않습니다. 이 변경은 다음과 같은 방법으로 진단 애플리케이션에 영향을 줍니다. * A ProcessModuleCollection 는 호출 `Process.GetCurrentProcess().Modules`에서 가져온 클래스 라이브러리(.dll 파일)의 모듈을 더 이상 포함하지 않습니다. * `EnumProcessModules` 함수를 사용하는 Win32 애플리케이션은 모든 관리 모듈이 나열되지 않습니다.	없음.
형식 선언	이제 형식에 DeclaringType 선언 형식이 없는 경우 속성이 null을 올바르게 반환합니다.	없음.
대표자	대리자 생성자에 null 값이 전달될 때, 대리자는 이제 ArgumentNullException를 던지며, 대신에 NullReferenceException를 던집니다.	예외 처리가 발생할 경우 이를 적절히 포착하는지 확인하십시오 ArgumentNullException.
전역 어셈블리 캐시 위치 변경	.NET Framework 4 어셈블리의 경우 전역 어셈블리 캐시가 Windows 디렉터리(%WINDIR%)에서 Microsoft.Net 하위 디렉터리(%WINDIR%\Microsoft.Net)로 이동되었습니다. 이전 버전의 어셈블리는 이전 디렉터리에 남아 있습니다. 관리되지 않는 ASM_CACHE_FLAGS 열거형에는 새 `ASM_CACHE_ROOT_EX` 플래그가 포함됩니다. 이 플래그는 GetCachePath 함수에서 가져올 수 있는 .NET Framework 4 어셈블리의 캐시 위치를 가져옵니다.	애플리케이션이 어셈블리에 대한 명시적 경로를 사용하지 않는다고 가정하면 문제가 없습니다. 명시적 경로 사용은 권장되지 않습니다.
전역 어셈블리 캐시 도구	Gacutil.exe(전역 어셈블리 캐시 도구)는 더 이상 셸 플러그 인 뷰어를 지원하지 않습니다.	없음.

상호 운용성

네임스페이스: System.Runtime.InteropServices

어셈블리: mscorlib(in mscorlib.dll)

특징	3.5 SP1의 차이점	권장되는 변경 내용
버퍼 길이 (관리되지 않는 API)	메모리를 절약하기 위해 `pBufferLengthOffset` 매개 변수의 기능이 매개 변수와 일치하도록 `pStringLengthOffset` 메서드에 변경되었습니다. 이제 두 매개 변수 모두 문자열 길이의 오프셋 위치를 가리킵니다. 버퍼 길이가 문자열 클래스의 표현에서 제거되었습니다.	버퍼 길이에 대한 종속성을 제거합니다.
JIT 디버깅	JIT(Just-In-Time) 디버깅에 대한 등록을 간소화하기 위해 .NET Framework 디버거는 이제 네이티브 코드에 대한 JIT 디버깅 동작을 제어하는 AeDebug 레지스트리 키만 사용합니다. 이렇게 변경하면 다음과 같은 결과가 발생합니다. * 관리 코드와 네이티브 코드에 대해 두 개의 서로 다른 디버거를 더 이상 등록할 수 없습니다. * 비대화형 프로세스에 대해 더 이상 디버거를 자동으로 시작할 수 없지만 사용자에게 대화형 프로세스를 요청하는 메시지를 표시할 수 있습니다. * 디버거가 시작되지 않거나 시작해야 하는 등록된 디버거가 없을 때 더 이상 알림이 표시되지 않습니다. * 애플리케이션의 상호 작용에 의존하는 자동 시작 정책은 더 이상 지원되지 않습니다.	필요에 따라 디버깅 작업을 조정합니다.
플랫폼 호출	관리되지 않는 코드와의 상호 운용성에서 성능을 향상시키기 위해 플랫폼 호출의 잘못된 호출 규칙으로 인해 애플리케이션이 실패합니다. 이전 버전에서 마샬링 계층은 스택에서 이러한 오류를 해결했습니다.	Microsoft Visual Studio에서 애플리케이션을 디버깅하면 이러한 오류를 수정할 수 있도록 경고합니다. 업데이트할 수 없는 이진 파일이 있는 경우 애플리케이션의 구성 파일에 NetFx40_PInvokeStackResilience< 요소를 포함>하여 호출 오류를 이전 버전과 같이 스택에서 해결할 수 있도록 할 수 있습니다. 그러나 이는 애플리케이션의 성능에 영향을 줄 수 있습니다.
제거된 인터페이스 (관리되지 않는 API)	개발자 혼동을 방지하기 위해 유용한 런타임 시나리오를 제공하지 않았고 CLR에서 구현을 제공하거나 수락하지 않았기 때문에 다음 인터페이스가 제거되었습니다. * INativeImageINativeImageDependency * INativeImageInstallInfo * INativeImageEvaluate * INativeImageConverter * ICorModule * IMetaDataConverter	없음.

데이터

이 섹션에서는 데이터 집합 및 SQL 클라이언트, Entity Framework, LINQ to SQL 및 WCF 데이터 서버(이전의 ADO.NET Data Services)를 사용하기 위한 마이그레이션 문제에 대해 설명합니다.