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

아티클
05/10/2023

이 문서에서는 수정, 표준 준수 및 보안에 대한 변경 내용, 고객 피드백 기반의 변경 내용을 포함하여 .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 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 애플리케이션에서 시작되지 않음) 섹션을 참조하세요.
ClientID 변경 내용	ASP.NET 4의 새로운 `clientIDMode` 설정을 통해 ASP.NET이 HTML 요소에 대해 `id` 특성을 생성하는 방법을 지정할 수 있습니다. ASP.NET의 이전 버전에서는 기본 동작이 `clientIDMode`의 `AutoID` 설정과 동일합니다. 이제 기본 설정은 `Predictable`입니다. 자세한 내용은 ASP.NET 웹 서버 컨트롤 식별을 참조하세요.	Visual Studio를 사용하여 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 애플리케이션은 다양한 보안 예외와 함께 실패할 수 있습니다. 컴퓨터 CAS 정책에 대한 광범위한 수정에 의존하는 부분 신뢰 애플리케이션도 실패하고 보안 예외를 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의 프로젝트 업그레이드 도구를 사용하여 ASP.NET 3.5 애플리케이션을 ASP.NET 4로 업그레이드하세요. Visual Studio 2010은 ASP.NET 3.5 애플리케이션의 Web.config 파일을 자동으로 수정하여 ASP.NET 4에 대한 적절한 설정을 포함합니다. 그러나 다시 컴파일하지 않고 .NET Framework 4를 사용하여 ASP.NET 3.5 애플리케이션을 실행할 수 있습니다. 이 경우 .NET Framework 4 및 IIS 7 또는 IIS 7.5에서 애플리케이션을 실행하기 전에 애플리케이션의 Web.config 파일을 수동으로 수정해야 할 수 있습니다. 반드시 변경해야 하는 구체적인 내용은 SP(서비스 팩) 릴리스를 비롯하여 작업 중인 소프트웨어의 조합에 따라 다릅니다. 이 변경으로 인해 영향을 받을 수 있는 소프트웨어 조합 및 특정 조합의 문제를 해결하는 방법에 대한 자세한 내용은 ASP.NET 웹 사이트에 있는 ASP.NET 4 Breaking Changes(ASP.NET 4 주요 변경 내용) 문서의 “Configuration Errors Related to New ASP.NET 4 Root Configuration”(새 ASP.NET 4 루트 구성과 관련된 구성 오류) 섹션을 참조하세요.
컨트롤 렌더링	이전 버전의 ASP.NET에서는 일부 컨트롤에서 비활성화할 수 없는 태그를 내보냈습니다. 기본적으로 이 형식의 태그는 ASP.NET 4에서 더 이상 생성되지 않습니다. 이러한 렌더링 변경은 다음 컨트롤에 영향을 줍니다. * `Image` 및 `ImageButton` 컨트롤은 더 이상 `border="0"` 특성을 렌더링하지 않습니다. * `BaseValidator` 클래스와 그로부터 파생된 유효성 검사 컨트롤은 더 이상 기본적으로 빨간색 텍스트를 렌더링하지 않습니다. * `HtmlForm` 컨트롤은 `name` 특성을 렌더링하지 않습니다. * `Table` 컨트롤이 더 이상 `border="0"` 특성을 렌더링하지 않습니다. 사용자 입력용으로 디자인되지 않은 컨트롤(예: `Label` 컨트롤)은 `Enabled` 속성이 `false`로 설정된 경우(또는 컨테이너 컨트롤에서 이 설정을 상속하는 경우) 더 이상 `disabled="disabled"` 특성을 렌더링하지 않습니다.	Visual Studio를 사용하여 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(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 통합 모드의 기본 문서에서 이벤트 처리기가 작동하지 않을 수 있음) 섹션을 참조하세요.
해시 알고리즘	ASP.NET은 암호화 및 해시 알고리즘을 모두 사용하여 양식 인증 쿠키 및 보기 상태와 같은 데이터를 보호합니다. 기본적으로 ASP.NET 4는 쿠키 및 보기 상태의 해시 작업에 HMACSHA256 알고리즘을 사용합니다. 이전 버전의 ASP.NET에서는 이전 HMACSHA1 알고리즘을 사용했습니다.	양식 인증 쿠키와 같은 데이터가 .NET Framework 버전 전체에서 작동해야 하는, ASP.NET 2.0 및 ASP.NET 4가 혼합된 애플리케이션을 실행하는 경우, Web.config 파일에서 다음 설정을 추가하여 ASP.NET 4 웹 애플리케이션이 이전 HMACSHA1 알고리즘을 사용하도록 구성하세요. `<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 메서드	HttpUtility 및 HttpServerUtility 클래스의 `HtmlEncode` 및 `UrlEncode` 메서드가 다음과 같이 작은따옴표 문자(')를 인코딩하도록 업데이트되었습니다. * `HtmlEncode` 메서드는 작은따옴표의 인스턴스를 `'`로 인코딩합니다. * `UrlEncode` 메서드는 작은따옴표의 인스턴스를 `%27`로 인코딩합니다.	`HtmlEncode` 및 `UrlEncode` 메서드를 사용하는 장소에 대한 코드를 검사하고 인코딩의 변경으로 인해 애플리케이션에 영향을 주는 변경이 발생하지 않는지 확인하세요.
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 4 주요 변경 내용) 문서의 “ASP.NET 2.0 Applications Might Generate HttpException Errors That Reference eurl.axd”(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 속성을 설정하는 대신 부모 Menu 컨트롤의 StaticPopOutImageUrl 또는 DynamicPopOutImageUrl을 설정하세요. 또는 MenuRenderingMode를 `Table`, MenuRenderingMode를 `Default`, ControlRenderingCompatibilityVersion을 `3.5`로 설정하세요. 이렇게 설정하면 Menu 컨트롤이 이전 버전의 ASP.NET에서 사용한 HTML 테이블 기반 레이아웃을 사용하게 합니다. StaticPopOutImageUrl 또는 DynamicPopOutImageUrl 속성의 경로에 백슬래시(\)가 포함되어 있으면 슬래시 문자(/)를 대체하세요.
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에서는 `Location="ServerAndClient"`를 출력 캐시 설정으로 지정한 캐시된 페이지가 응답에서 `Vary:` HTTP 헤더를 내보내는 버그가 있었습니다. 이로 인해 클라이언트 브라우저가 페이지를 로컬에 캐시하지 못했습니다. ASP.NET 1.1에서는 `Vary:` 헤더를 억제하기 위해 호출할 수 있는 SetOmitVaryStar 메서드가 추가되었습니다. 그러나 버그 보고서에 따르면 개발자는 기존의 `SetOmitVaryStar` 동작을 인식하지 못합니다. ASP.NET 4에서는 다음 지시문을 지정하는 응답에서 더 이상 `Vary:` HTTP 헤더를 내보내지 않습니다. `<%@ OutputCache Location="ServerAndClient" %>` 결과적으로 `Vary:` 헤더를 억제하기 위해 SetOmitVaryStar 메서드가 더 이상 필요하지 않습니다. `Location` 특성에 대해 “ServerAndClient”를 지정하는 애플리케이션에서는 SetOmitVaryStar를 호출할 필요 없이 브라우저에서 페이지를 캐시할 수 있습니다.	애플리케이션의 페이지가 `Vary:`을 내보내야 하는 경우 다음 예제와 같이 AppendHeader 메서드를 호출합니다. `System.Web.HttpResponse.AppendHeader("Vary","");` 또는 출력 캐싱 `Location` 특성의 값을 “Server”로 변경할 수 있습니다.
페이지 구문 분석	ASP.NET 웹 페이지(.aspx 파일) 및 사용자 컨트롤(.ascx 파일)의 페이지 파서는 이전 버전의 ASP.NET보다 ASP.NET 4에서 더 엄격하며, 이전 버전보다 더 많은 태그를 잘못된 것으로 표시합니다.	페이지가 실행될 때 생성되는 오류 메시지를 검사하고 잘못된 태그에서 발생하는 오류를 수정하세요.
Passport 형식	ASP.NET 2.0에 내장된 Passport 지원은 사용되지 않으며 Passport(이제 Live ID SDK)의 변경으로 인해 지원되지 않습니다. 그 결과 System.Web.Security의 Passport와 관련된 형식이 이제 `ObsoleteAttribute` 특성으로 표시됩니다.	System.Web.Security 네임스페이스(예: PassportIdentity)에서 Passport 형식을 사용하는 코드를 Windows Live ID SDK를 사용하도록 변경하세요.
FilePath 속성의 PathInfo 정보	ASP.NET 4는 FilePath, AppRelativeCurrentExecutionFilePath, CurrentExecutionFilePath와 같은 속성의 반환 값에 더 이상 `PathInfo` 값을 포함하지 않습니다. 대신, `PathInfo` 정보를 PathInfo에서 사용할 수 있습니다. 예를 들어 다음과 같은 URL 조각을 가정해 보겠습니다. `/testapp/Action.mvc/SomeAction` 이전 버전의 ASP.NET에서 HttpRequest 속성은 다음과 같은 값을 갖습니다. * FilePath: `/testapp/Action.mvc/SomeAction` * PathInfo: (empty) 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'.`	지금은 ASP.NET과 호환되는 SharePoint 버전이 없습니다. 따라서 ASP.NET 4 웹 사이트를 SharePoint 웹 사이트의 자식으로 실행해서는 안 됩니다.
XHTML 1.1 표준	새로운 웹 사이트에 XHTML 1.1 규격을 사용하기 위해 .NET Framework 4의 ASP.NET 컨트롤은 XHTML 1.1 규격 HTML을 생성합니다. `<system.Web>` 요소 내부의 Web.config 파일에서 다음 옵션을 사용하여 이 렌더링을 사용하도록 설정할 수 있습니다. `<pages controlRenderingCompatibilityVersion="4.0"/>` 이 옵션은 기본적으로 4.0으로 설정됩니다. Visual Studio 2008에서 업그레이드되는 웹 프로젝트는 호환성을 위해 3.5 설정을 사용합니다.	없음

핵심