ASP.NET 4 주요 변경 내용

이 문서에서는 ASP.NET 4 베타 1 및 베타 2 릴리스를 포함하여 이전 릴리스를 사용하여 만든 애플리케이션에 영향을 줄 수 있는 .NET Framework 버전 4 릴리스에 대해 변경된 내용을 설명합니다.

이 백서 다운로드

콘텐츠

Web.config 파일의 ControlRenderingCompatibilityVersion 설정
ClientIDMode 변경 내용
HtmlEncode 및 UrlEncode 이제 작은따옴표 인코딩
ASP.NET 페이지(.aspx) 파서가 더 엄격합니다.
브라우저 정의 파일 업데이트됨
웹 구성 파일에서 _Toc256770146System.Web.Mobile.dll 제거됨
ASP.NET 요청 유효성 검사
기본 해시 알고리즘은 이제 HMACSHA256입니다.
새 ASP.NET 4 루트 구성과 관련된 구성 오류
ASP.NET 4 자식 애플리케이션이 ASP.NET 2.0 또는 ASP.NET 3.5 애플리케이션에서 시작할 수 없습니다.
ASP.NET 4개의 웹 사이트가 SharePoint가 설치된 컴퓨터에서 시작하지 못
HttpRequest.FilePath 속성에 PathInfo 값이 더 이상 포함되어 있지 않습니다.
ASP.NET 2.0 애플리케이션은 eurl.axd를 참조하는 HttpException 오류를 생성할 수 있습니다.
IIS 7 또는 IIS 7.5 통합 모드의 기본 문서에서 이벤트 처리기가 발생하지 않을 수 있습니다.
ASP.NET CAS(코드 액세스 보안) 구현에 대한 변경 내용
System.Web.Security 네임스페이스의 MembershipUser 및 기타 형식이 이동되었습니다.
다양한 출력 캐싱 변경 내용 * HTTP 헤더
Passport용 System.Web.Security 형식은 사용되지 않습니다.
menuItem.PopOutImageUrl 속성이 ASP.NET 4에서 이미지를 렌더링하지 못함
경로에 백슬래시가 포함되어 있을 때 Menu.StaticPopOutImageUrl 및 Menu.DynamicPopOutImageUrl에서 이미지를 렌더링하지 못
면책 조항

Web.config 파일의 ControlRenderingCompatibilityVersion 설정

ASP.NET 컨트롤이 태그를 렌더링하는 방법을 보다 정확하게 지정할 수 있도록 .NET Framework 버전 4에서 수정되었습니다. 이전 버전의 .NET Framework 일부 컨트롤은 사용하지 않도록 설정할 방법이 없는 태그를 내보냅니다. 기본적으로 ASP.NET 4에서는 이 유형의 태그가 더 이상 생성되지 않습니다.

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" />

새 동작에서 가져오는 주요 렌더링 변경 내용은 다음과 같습니다.

• Image 및 ImageButton 컨트롤은 더 이상 특성을 렌더링하지 border="0" 않습니다.
• BaseValidator 클래스 및 유효성 검사 컨트롤에서 파생된 컨트롤은 기본적으로 더 이상 빨간색 텍스트를 렌더링하지 않습니다.
• HtmlForm 컨트롤은 이름 특성을 렌더링하지 않습니다.
• Table 컨트롤은 더 이상 특성을 렌더링하지 border="0" 않습니다.
• 사용자 입력(예: 레이블 컨트롤)을 위해 디자인되지 않은 컨트롤은 Enabled 속성이 false로 설정되거나 컨테이너 컨트롤에서 이 설정을 상속하는 경우 특성을 더 이상 렌더링 disabled="disabled" 하지 않습니다.

ClientIDMode 변경 내용

ASP.NET 4의 ClientIDMode 설정을 사용하면 ASP.NET HTML 요소에 대한 ID 특성을 생성하는 방법을 지정할 수 있습니다. 이전 버전의 ASP.NET 기본 동작은 ClientIDMode의 AutoID 설정과 동일합니다. 그러나 기본 설정은 이제 예측 가능입니다.

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" />

HtmlEncode 및 UrlEncode 이제 작은따옴표 인코딩

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

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

ASP.NET 페이지(.aspx) 파서가 더 엄격합니다.

ASP.NET 페이지(.aspx 파일) 및 사용자 컨트롤(.ascx 파일)에 대한 페이지 파서는 ASP.NET 4에서 더 엄격하며 잘못된 태그의 더 많은 인스턴스를 거부합니다. 예를 들어 다음 두 코드 조각은 ASP.NET 이전 릴리스에서 성공적으로 구문 분석되지만 이제 ASP.NET 4에서 파서 오류가 발생합니다.

<asp:HiddenField runat="server" ID="SomeControl" Value="sampleValue"  ; />

HiddenField 태그 끝에 잘못된 세미콜론이 있습니다.

<asp:LinkButton runat="server" ID="SomeControl" onclick="someControlClicked"
      style="display:inline;  CssClass="searchLink"  />

CssClass 특성으로 실행되는 닫지 않은 스타일 특성을 확인합니다.

브라우저 정의 파일 업데이트됨

브라우저 정의 파일은 새롭고 업데이트된 브라우저 및 디바이스에 대한 정보를 포함하도록 업데이트되었습니다. Netscape Navigator와 같은 오래된 브라우저와 디바이스는 제거되었으며 Google Chrome 및 Apple iPhone과 같은 최신 브라우저와 디바이스가 추가되었습니다.

애플리케이션에 제거된 브라우저 정의 중 하나를 상속하는 사용자 지정 브라우저 정의가 포함되어 있으면 오류가 표시됩니다. 예를 들어 폴더에 App_Browsers IE2 브라우저 정의에서 상속되는 브라우저 정의가 포함된 경우 다음 구성 오류 메시지가 표시됩니다.

• ID가 'IE2'인 브라우저 또는 게이트웨이 요소를 찾을 수 없습니다.

참고

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 명령줄 도구를 실행합니다.

루트 웹 구성 파일에서 제거된 System.Web.Mobile.dll

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

System.Web.Mobile.dll 어셈블리는 ASP.NET 4에 포함되지만 더 이상 사용되지 않습니다. System.Web.Mobile.dll 어셈블리의 형식을 사용하려면 이 어셈블리에 대한 참조를 루트 Web.config 파일 또는 애플리케이션 Web.config 파일에 추가합니다. 예를 들어(사용되지 않는) ASP.NET 모바일 컨트롤을 사용하려는 경우 파일에 System.Web.Mobile.dll 어셈블리에 대한 참조를 Web.config 추가해야 합니다.

ASP.NET 요청 유효성 검사

ASP.NET 요청 유효성 검사 기능은 XSS(교차 사이트 스크립팅) 공격에 대해 특정 수준의 기본 보호를 제공합니다. 이전 버전의 ASP.NET 요청 유효성 검사가 기본적으로 사용하도록 설정되었습니다. 그러나 ASP.NET 페이지(.aspx 파일 및 해당 클래스 파일)와 해당 페이지가 실행 중일 때만 적용되었습니다.

ASP.NET 4에서는 기본적으로 HTTP 요청의 BeginRequest 단계 이전에 사용하도록 설정되므로 모든 요청에 대해 요청 유효성 검사가 사용하도록 설정됩니다. 따라서 요청 유효성 검사는 .aspx 페이지 요청뿐만 아니라 모든 ASP.NET 리소스에 대한 요청에 적용됩니다. 여기에는 웹 서비스 호출 및 사용자 지정 HTTP 처리기와 같은 요청이 포함됩니다. 사용자 지정 HTTP 모듈이 HTTP 요청의 내용을 읽는 경우에도 요청 유효성 검사가 활성화됩니다.

따라서 이전에 오류를 트리거하지 않은 요청에 대해 요청 유효성 검사 오류가 발생할 수 있습니다. ASP.NET 2.0 요청 유효성 검사 기능의 동작에 되돌리기 파일에 다음 설정을 Web.config 추가합니다.

<httpRuntime requestValidationMode="2.0" />

그러나 요청 유효성 검사 오류를 분석하여 기존 처리기, 모듈 또는 기타 사용자 지정 코드가 XSS 공격 벡터일 수 있는 잠재적으로 안전하지 않은 HTTP 입력에 액세스하는지 여부를 확인하는 것이 좋습니다.

기본 해시 알고리즘은 이제 HMACSHA256입니다.

ASP.NET은 암호화 및 해시 알고리즘을 모두 사용하여 양식 인증 쿠키 및 보기 상태와 같은 데이터를 보호합니다. 기본적으로 ASP.NET 4는 이제 쿠키 및 뷰 상태에 대한 해시 작업에 HMACSHA256 알고리즘을 사용합니다. 이전 버전의 ASP.NET 이전 HMACSHA1 알고리즘을 사용했습니다.

양식 인증 쿠키와 같은 데이터가 프레임워크 버전에서 작동해야 하는 혼합 ASP.NET 2.0/ASP.NET 4 환경을 실행하는 경우 애플리케이션이 영향을 받을 수 across.NET. 이전 HMACSHA1 알고리즘을 사용하도록 ASP.NET 4 웹 애플리케이션을 구성하려면 파일에 다음 설정을 Web.config 추가합니다.

<machineKey validation="SHA1" />

새 ASP.NET 4 루트 구성과 관련된 구성 오류

.NET Framework 4(machine.config따라서 ASP.NET 4)에 대한 루트 구성 파일(파일 및 루트 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 파일을 자동으로 수정합니다.

그러나 다시 컴파일하지 않고 .NET Framework 4를 사용하여 ASP.NET 3.5 애플리케이션을 실행하는 것은 지원되는 시나리오입니다. 이 경우 .NET Framework 4 및 IIS 7 또는 IIS 7.5에서 애플리케이션을 실행하기 전에 애플리케이션의 Web.config 파일을 수동으로 수정해야 할 수 있습니다.

다음 두 섹션에서는 소프트웨어의 서로 다른 조합에 대해 수행해야 할 수 있는 변경 내용에 대해 설명합니다.

핫픽스 KB958854 또는 SP2가 설치되지 않은 Windows Vista SP1 또는 Windows Server 2008 SP1. 이 구성에서 IIS 7 구성 시스템은 애플리케이션 수준 Web.config 파일을 ASP.NET 2.0 machine.config 파일과 비교하여 애플리케이션의 관리되는 구성을 잘못 병합합니다. 이 때문에 iiS 7 유효성 검사 실패를 일으키지 않으려면 .NET Framework 3.5 이상의 애플리케이션 수준 Web.config 파일에 system.web.extensions 구성 섹션 정의(요소)가 있어야 합니다.

그러나 Visual Studio 2008에서 도입된 원래 상용구 구성 섹션 정의와 정확하게 일치하지 않는 애플리케이션 수준 Web.config 파일 항목을 수동으로 수정하면 ASP.NET 구성 오류가 발생합니다. (Visual Studio 2008에서 생성된 기본 구성 항목이 올바르게 작동합니다.) 일반적인 문제는 수동으로 수정된 Web.config 파일이 allowDefinition 을 벗어나고 다양한 구성 섹션 정의에서 찾을 수 있는 Permission 구성 특성이 필요하다는 것입니다. 이로 인해 애플리케이션 수준 Web.config 파일의 약어 구성 섹션과 ASP.NET 4 machine.config 파일의 전체 정의가 일치하지 않습니다. 결과적으로 런타임에 ASP.NET 4 구성 시스템에서 구성 오류를 throw합니다.

Windows Vista SP2, Windows Server 2008 SP2, Windows 7, Windows Server 2008 R2 및 핫픽스 KB958854가 설치된 Windows Vista SP1 및 Windows Server 2008 SP1도 있습니다.

이 시나리오에서 IIS 7 및 IIS 7.5 네이티브 구성 시스템은 관리되는 구성 섹션 처리기에 대해 정의된 형식 특성에 대한 텍스트 비교를 수행하므로 구성 오류를 반환합니다. Visual Studio 2008 및 Visual Studio 2008 SP1에서 생성된 모든 Web.config 파일에 system.web.extensions (및 관련) 구성 섹션 처리기의 형식 문자열에 "3.5"가 있으므로 ASP.NET 4 machine.config 파일에는 동일한 구성 섹션 처리기의 형식 특성에 "4.0"이 있으므로 Visual Studio 2008 또는 Visual Studio 2008 SP1에서 생성된 애플리케이션은 항상 IIS 7 및 IIS 7.5에서 구성 유효성 검사에 실패합니다.

이러한 문제 해결

첫 번째 시나리오의 해결 방법은 Visual Studio 2008에서 자동으로 생성된 파일의 Web.config 상용구 구성 텍스트를 포함하여 애플리케이션 수준 Web.config 파일을 업데이트하는 것입니다.

첫 번째 시나리오의 다른 해결 방법은 IIS 구성 시스템의 잘못된 구성 병합 동작을 수정하기 위해 컴퓨터에 Vista 또는 Windows Server 2008용 서비스 팩 2를 설치하는 것입니다. 그러나 이러한 작업 중 하나를 수행한 후 애플리케이션은 두 번째 시나리오에 대해 설명된 문제로 인해 구성 오류가 발생할 수 있습니다.

두 번째 시나리오의 해결 방법은 애플리케이션 수준 Web.config 파일에서 모든 system.web.extensions 구성 섹션 정의 및 구성 섹션 그룹 정의를 삭제하거나 주석으로 처리합니다. 이러한 정의는 일반적으로 애플리케이션 수준 Web.config 파일의 맨 위에 있으며 configSections 요소 및 해당 자식으로 식별할 수 있습니다.

두 시나리오 모두 필수는 아니지만 system.codedom 섹션도 수동으로 삭제하는 것이 좋습니다.

ASP.NET 4 자식 애플리케이션이 ASP.NET 2.0 또는 ASP.NET 3.5 애플리케이션에서 시작되지 못

이전 버전의 ASP.NET을 실행하는 애플리케이션의 자식으로서 구성된 ASP.NET 4 애플리케이션은 구성 또는 컴파일 오류로 인해 시작하지 못할 수 있습니다. 다음 예제에서는 영향을 받는 애플리케이션에 대 한 디렉터리 구조를 보여 집니다.

/parentwebapp (ASP.NET 2.0 또는 ASP.NET 3.5를 사용하도록 구성됨)
/childwebapp (ASP.NET 4를 사용하도록 구성됨)

폴더의 childwebapp 애플리케이션은 IIS 7 또는 IIS 7.5에서 시작되지 않으며 구성 오류를 보고합니다. 오류 텍스트에는 다음과 유사한 메시지가 포함됩니다.

• The requested page cannot be accessed because the related configuration data for the page is invalid.

• The configuration section 'configSections' cannot be read because it is missing a section declaration.

IIS 6에서는 폴더의 childwebapp 애플리케이션도 시작되지 않지만 다른 오류를 보고합니다. 예를 들어 오류 텍스트에 다음이 표시될 수 있습니다.

• The value for the 'compilerVersion' attribute in the provider options must be 'v4.0' or later if you are compiling for version 4.0 or later of the .NET Framework. To compile this Web application for version 3.5 or earlier of the .NET Framework, remove the 'targetFramework' attribute from the element of the Web.config file

이러한 시나리오는 폴더에 있는 부모 애플리케이션의 구성 정보가 폴더의 자식 웹 childwebapp 애플리케이션에서 parentwebapp 사용하는 최종 병합된 구성 설정을 결정하는 구성 정보 계층 구조의 일부이기 때문에 발생합니다. ASP.NET 4 웹 애플리케이션이 IIS 7(또는 IIS 7.5) 또는 IIS 6에서 실행되는지 여부에 따라 IIS 구성 시스템 또는 ASP.NET 4 컴파일 시스템에서 오류가 반환됩니다.

이 문제를 resolve 자식 ASP.NET 4 애플리케이션이 작동하도록 하기 위해 수행해야 하는 단계는 ASP.NET 4 애플리케이션이 IIS 6 또는 IIS 7(또는 IIS 7.5)에서 실행되는지 여부에 따라 달라집니다.

1단계(IIS 7 또는 IIS 7.5만 해당)

이 단계는 Windows Vista, Windows Server 2008, Windows 7 및 Windows Server 2008 R2를 포함하는 IIS 7 또는 IIS 7.5를 실행하는 운영 체제에서만 필요합니다.

부모 애플리케이션의 파일(Web.configASP.NET 2.0 또는 ASP.NET 3.5를 실행하는 애플리케이션)의 configSections 정의를 the.NET Framework 2.0의 루트 Web.config 파일로 이동합니다. IIS 7 및 IIS 7.5 네이티브 구성 시스템은 구성 파일의 계층 구조를 병합할 때 configSections 요소를 검사합니다. 부모 웹 애플리케이션의 Web.config 파일에서 루트 Web.config 파일로 configSections 정의를 이동하면 자식 ASP.NET 4 애플리케이션에 대해 발생하는 구성 병합 프로세스에서 요소가 효과적으로 숨겨집니다.

32비트 운영 체제 또는 32비트 애플리케이션 풀의 경우 ASP.NET 2.0 및 ASP.NET 3.5에 대한 루트 Web.config 파일은 일반적으로 다음 폴더에 있습니다.

C:\Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG

64비트 운영 체제 또는 64비트 애플리케이션 풀의 경우 ASP.NET 2.0 및 ASP.NET 3.5에 대한 루트 Web.config 파일은 일반적으로 다음 폴더에 있습니다.

C:\Windows\Microsoft.NET\Framework64\v2.0.50727\CONFIG

64비트 컴퓨터에서 32비트 및 64비트 웹 애플리케이션을 모두 실행하는 경우 configSections 요소를 32비트 및 64비트 시스템 모두에 대한 루트 Web.config 파일로 이동해야 합니다.

configSections 요소를 루트 Web.config 파일에 넣으면 구성 요소 바로 다음에 섹션을 붙여넣습니다. 다음 예제에서는 요소 이동을 마쳤을 때 루트 Web.config 파일의 위쪽 부분이 어떻게 표시되는지 보여 있습니다.

참고

다음 예제에서는 가독성을 위해 줄이 래핑되었습니다.

<?xml version="1.0" encoding="utf-8"?>
<!-- The root web configuration file -->
<configuration>
  <configSections>
    <sectionGroup name="system.web.extensions"
        type="System.Web.Configuration.SystemWebExtensionsSectionGroup, 
      System.Web.Extensions, Version=3.5.0.0, Culture=neutral,  
      PublicKeyToken=31BF3856AD364E35">

      <sectionGroup name="scripting"
        type="System.Web.Configuration.ScriptingSectionGroup, 
        System.Web.Extensions, Version=3.5.0.0, Culture=neutral, 
        PublicKeyToken=31BF3856AD364E35">

        <section name="scriptResourceHandler"
          type="System.Web.Configuration.ScriptingScriptResourceHandlerSection, 
          System.Web.Extensions, Version=3.5.0.0, Culture=neutral, 
          PublicKeyToken=31BF3856AD364E35" requirePermission="false"
          allowDefinition="MachineToApplication" />

        <sectionGroup name="webServices"
          type="System.Web.Configuration.ScriptingWebServicesSectionGroup,
          System.Web.Extensions, Version=3.5.0.0, Culture=neutral, 
          PublicKeyToken=31BF3856AD364E35">

          <section name="jsonSerialization"
            type="System.Web.Configuration.ScriptingJsonSerializationSection, 
            System.Web.Extensions, Version=3.5.0.0, Culture=neutral, 
            PublicKeyToken=31BF3856AD364E35" requirePermission="false"
            allowDefinition="Everywhere" />

          <section name="profileService"
            type="System.Web.Configuration.ScriptingProfileServiceSection, 
            System.Web.Extensions, Version=3.5.0.0, Culture=neutral, 
            PublicKeyToken=31BF3856AD364E35" requirePermission="false"
            allowDefinition="MachineToApplication" />
          <section name="authenticationService"
            type="System.Web.Configuration.ScriptingAuthenticationServiceSection, 
          System.Web.Extensions, Version=3.5.0.0, Culture=neutral, 
          PublicKeyToken=31BF3856AD364E35" requirePermission="false"
            allowDefinition="MachineToApplication" />

          <section name="roleService"
            type="System.Web.Configuration.ScriptingRoleServiceSection, 
          System.Web.Extensions, Version=3.5.0.0, Culture=neutral, 
          PublicKeyToken=31BF3856AD364E35" requirePermission="false"
            allowDefinition="MachineToApplication" />

        </sectionGroup>
      </sectionGroup>
    </sectionGroup>
  </configSections>

2단계(IIS의 모든 버전)

이 단계는 ASP.NET 4 자식 웹 애플리케이션이 IIS 6 또는 IIS 7(또는 IIS 7.5)에서 실행되는지 여부에 관계없이 필요합니다.

Web.config ASP.NET 2 또는 ASP.NET 3.5를 실행하는 부모 웹 애플리케이션의 파일에서 구성 항목이 부모 웹 애플리케이션에만 적용되는 (IIS 및 ASP.NET 구성 시스템 모두에 대해) 명시적으로 지정하는 위치 태그를 추가합니다. 다음 예제에서는 추가할 location 요소의 구문을 보여줍니다.

<location path="" inheritInChildApplications="false" >
  <!-- Additional settings -->
</location>

다음 예제에서는 위치 태그를 사용하여 appSettings 섹션부터 system.webServer 섹션으로 끝나는 모든 구성 섹션을 래핑하는 방법을 보여 줍니다.

<location path="" inheritInChildApplications="false" >
  <appSettings />
  <connectionStrings />
  <system.web>
    <!-- Removed for brevity -->
  </system.web>
  <system.codedom>
    <!-- Removed for brevity -->
  </system.codedom>
  <system.webServer>
    <!-- Removed for brevity -->
</system.webServer>
</location>

1단계와 2단계를 완료하면 자식 ASP.NET 4 웹 애플리케이션이 오류 없이 시작됩니다.

ASP.NET 4개의 웹 사이트가 SharePoint가 설치된 컴퓨터에서 시작하지 못

SharePoint를 실행하는 웹 서버에는 Web.config SharePoint 웹 사이트의 루트에 배포된 파일이 있습니다(예 c:\inetpub\wwwroot\web.config : 기본 웹 사이트). 이 Web.config 파일에서 SharePoint는 WSS_Minimal 라는 사용자 지정 부분 신뢰 수준을 설정합니다.

이 유형의 SharePoint 웹 사이트의 자식으로 배포된 ASP.NET 4 웹 사이트를 실행하려고 하면 다음 오류가 표시됩니다.

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

이 오류는 ASP.NET 4 CAS(코드 액세스 보안) 인프라가 ASP.NET 권한 집합을 찾기 때문에 발생합니다. 그러나 WSS_Minimal 참조하는 부분 신뢰 구성 파일에는 해당 이름의 권한 집합이 포함되어 있지 않습니다.

현재 ASP.NET 호환되는 사용 가능한 SharePoint 버전이 없습니다. 따라서 SharePoint 웹 사이트 아래에서 ASP.NET 4 웹 사이트를 자식 사이트로 실행하려고 시도해서는 안 됩니다.

HttpRequest.FilePath 속성에 PathInfo 값이 더 이상 포함되어 있지 않습니다.

이전 버전의 ASP.NET HttpRequest.FilePath, HttpRequest.AppRelativeCurrentExecutionFilePath 및 HttpRequest.CurrentExecutionFilePath를 비롯한 다양한 파일 경로 관련 속성에서 반환된 값에 PathInfo 값이 포함되어 있습니다. ASP.NET 4에는 이러한 속성의 반환 값에 PathInfo 값이 더 이상 포함되어 있지 않습니다. 대신 PathInfo 정보는 HttpRequest.PathInfo에서 사용할 수 있습니다. 예를 들어 다음과 같은 URL 조각을 가정해 보겠습니다.

/testapp/Action.mvc/SomeAction

이전 버전의 ASP.NET HttpRequest 속성에는 다음 값이 있습니다.

HttpRequest.FilePath: /testapp/Action.mvc/SomeAction

HttpRequest.PathInfo: (비어 있음)

ASP.NET 4에서 HttpRequest 속성에는 다음 값이 대신 있습니다.

HttpRequest.FilePath: /testapp/Action.mvc

HttpRequest.PathInfo: SomeAction

ASP.NET 2.0 애플리케이션은 eurl.axd를 참조하는 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 웹 사이트가 ASP.NET 4를 사용하도록 구성된 것을 감지할 때 ASP.NET 4의 네이티브 구성 요소가 추가 처리를 위해 ASP.NET 관리되는 부분에 확장 없는 URL을 전달하기 때문에 발생합니다. 그러나 ASP.NET 4 웹 사이트 아래에 있는 가상 디렉터리에서 ASP.NET 2.0을 사용하도록 구성된 경우 이러한 방식으로 확장 없는 URL을 처리하면 "eurl.axd" 문자열이 포함된 수정된 URL이 생성됩니다. 그러면 이 수정된 URL이 ASP.NET 2.0 애플리케이션으로 전송됩니다. ASP.NET 2.0은 "eurl.axd" 형식을 인식할 수 없습니다. 따라서 ASP.NET 2.0은 라는 eurl.axd 파일을 찾아 실행하려고 시도합니다. 이러한 파일이 없으므로 HttpException 예외로 인해 요청이 실패합니다.

다음 옵션 중 하나를 사용하여 이 문제를 해결할 수 있습니다.

옵션 1

웹 사이트를 실행하기 위해 ASP.NET 4가 필요하지 않은 경우 ASP.NET 2.0을 사용하도록 사이트를 다시 매핑합니다.

옵션 2

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

옵션 3

웹 사이트를 ASP.NET 2.0으로 다시 매핑하거나 가상 디렉터리의 위치를 변경하는 것이 실용적이지 않은 경우 ASP.NET 4에서 확장 없는 URL 처리를 명시적으로 사용하지 않도록 설정합니다. 이렇게 하려면 다음 절차를 수행합니다.

1. Windows 레지스트리에서 다음 노드를 엽니다.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ASP.NET\4.0.30319.0

1. EnableExtensionlessUrls라는 새 DWORD 값을 만듭니다.
2. EnableExtensionlessUrls를 0으로 설정합니다. 이렇게 하면 확장 없는 URL 동작이 비활성화됩니다.
3. 레지스트리 값을 저장하고 레지스트리 편집기를 닫습니다.
4. IIS가 새 레지스트리 값을 읽도록 하는 iisreset 명령줄 도구를 실행합니다.

참고

EnableExtensionlessUrls를 1로 설정하면 확장 없는 URL 동작이 가능합니다. 값이 지정되지 않은 경우 기본 설정입니다.

IIS 7 또는 IIS 7.5 통합 모드의 기본 문서에서 이벤트 처리기가 발생하지 않을 수 있습니다.

ASP.NET 4에는 확장 없는 URL이 기본 문서로 확인될 때 HTML 양식 요소의 작업 특성이 렌더링되는 방식을 변경하는 수정 사항이 포함되어 있습니다. 기본 문서로 확인되는 확장 없는 URL의 예는 이고 http://contoso.com/, 그 결과 에 대한 요청이 발생합니다 http://contoso.com/Default.aspx.

이제 ASP.NET 4는 기본 문서가 매핑된 확장 없는 URL에 대한 요청이 수행되면 HTML 양식 요소의 작업 특성 값을 빈 문자열로 렌더링합니다. 예를 들어 ASP.NET 이전 릴리스에서는 에 대한 요청 http://contoso.com 으로 인해 에 대한 요청이 발생합니다 Default.aspx. 해당 문서에서 여는 양식 태그는 다음 예제와 같이 렌더링됩니다.

<form action="Default.aspx" />

ASP.NET 4에서 에 대한 http://contoso.com 요청은 에 대한 요청도 발생합니다 Default.aspx. 그러나 이제 ASP.NET 다음 예제와 같이 HTML 여는 양식 태그를 렌더링합니다.

<form action="" />

작업 특성이 렌더링되는 방식의 이러한 차이로 인해 IIS 및 ASP.NET 양식 게시물이 처리되는 방식이 약간 변경될 수 있습니다. 작업 특성이 빈 문자열이면 IIS DefaultDocumentModule 개체가 에 대한 자식 요청을 Default.aspx만듭니다. 대부분의 조건에서 이 자식 요청은 애플리케이션 코드에 투명하며 Default.aspx 페이지는 정상적으로 실행됩니다.

그러나 관리 코드와 IIS 7 또는 IIS 7.5 통합 모드 간의 잠재적 상호 작용으로 인해 관리되는 .aspx 페이지가 자식 요청 중에 제대로 작동하지 않을 수 있습니다. 다음 조건이 발생하면 문서에 대한 Default.aspx 자식 요청으로 인해 오류가 발생하거나 예기치 않은 동작이 발생합니다.

1. 양식 요소의 작업 특성이 ""로 설정된 브라우저로 .aspx 페이지가 전송됩니다.
2. 양식이 ASP.NET에 다시 게시됩니다.
3. 관리되는 HTTP 모듈은 엔터티 본문의 일부를 읽습니다. 예를 들어 모듈은 Request.Form 또는 Request.Params를 읽습니다. 이렇게 하면 POST 요청의 엔터티 본문이 관리되는 메모리로 읽힙니다. 결과적으로 IIS 7 또는 IIS 7.5 통합 모드에서 실행 중인 모든 네이티브 코드 모듈에서 더 이상 엔터티 본문을 사용할 수 없습니다.
4. IIS DefaultDocumentModule 개체는 결국 실행되고 문서에 대한 자식 요청을 Default.aspx 만듭니다. 그러나 엔터티 본문은 이미 관리 코드에 의해 읽혔기 때문에 자식 요청에 보낼 수 있는 엔터티 본문이 없습니다.
5. 자식 요청에 대해 HTTP 파이프라인이 실행되면 파일 처리기는 .aspx 처리기 실행 단계에서 실행됩니다.
6. 엔터티 본문이 없으므로 폼 변수와 뷰 상태가 없으므로 .aspx 페이지 처리기에서 발생해야 하는 이벤트(있는 경우)를 결정하는 데 사용할 수 있는 정보가 없습니다. 그 결과, 영향을 받는 .aspx 페이지의 포스트백 이벤트 처리기는 실행되지 않습니다.

다음과 같은 방법으로 이 동작을 해결할 수 있습니다.

• 기본 문서 요청 중에 요청의 엔터티 본문에 액세스하는 HTTP 모듈을 식별하고 관리되는 요청에 대해서만 실행되도록 구성할 수 있는지 여부를 확인합니다. IIS 7 및 IIS 7.5 모두에 대한 통합 모드에서 HTTP 모듈은 다음 특성을 모듈의 system.webServer/modules 항목에 추가하여 관리되는 요청에 대해서만 실행되도록 표시할 수 있습니다.

• precondition="managedHandler"

• 이 설정은 IIS 7 및 IIS 7.5에서 관리되는 요청이 아닌 것으로 판단되는 요청에 대해 모듈을 사용하지 않도록 설정합니다. 기본 문서 요청의 경우 첫 번째 요청은 확장 없는 URL에 대한 것입니다. 따라서 IIS는 초기 요청 처리 중에 관리되는 처리기의 전제 조건으로 표시된 관리되는 모듈을 실행하지 않습니다. 결과적으로 관리되는 모듈은 실수로 엔터티 본문을 읽지 않으므로 엔터티 본문을 계속 사용할 수 있으며 자식 요청 및 기본 문서에 전달됩니다.

• 문제가 있는 HTTP 모듈이 모든 요청에 대해 실행해야 하는 경우(정적 파일의 경우, DefaultDocumentModule 개체에 resolve 확장 없는 URL, 관리되는 요청 등) 페이지의 System.Web.UI.HtmlControls.HtmlForm 컨트롤의 Action 속성을 비어 있지 않은 문자열로 명시적으로 설정하여 영향을 받는 .aspx 페이지를 수정합니다. 예를 들어 기본 문서가 인 Default.aspx경우 페이지의 코드를 수정하여 HtmlForm 컨트롤의 Action 속성을 "Default.aspx"로 명시적으로 설정합니다.

ASP.NET CAS(코드 액세스 보안) 구현에 대한 변경 내용

2.0을 ASP.NET 3.5에 추가된 ASP.NET 기능을 확장하여 .NET Framework 1.1 및 2.0 CAS(코드 액세스 보안) 모델을 사용합니다. 그러나 ASP.NET 4의 CAS 구현은 크게 개선되었습니다. 따라서 GAC(전역 어셈블리 캐시)에서 실행되는 신뢰할 수 있는 코드를 사용하는 부분 신뢰 ASP.NET 애플리케이션은 다양한 보안 예외로 인해 실패할 수 있습니다. 머신 CAS 정책에 대한 광범위한 수정을 사용하는 부분 신뢰 애플리케이션도 보안 예외로 인해 실패할 수 있습니다.

다음 예제와 같이 신뢰 구성 요소의 새 legacyCasModel 특성을 사용하여 4개 애플리케이션을 ASP.NET 1.1 및 2.0의 동작에 부분 신뢰 ASP.NET 되돌리기 수 있습니다.

<trust level= "Medium" legacyCasModel="true" />

레거시 CAS 모델을 되돌리기 경우 다음과 같은 이전 CAS 동작이 사용하도록 설정됩니다.

• 컴퓨터 CAS 정책이 적용됩니다.
• 단일 애플리케이션 도메인에서 여러 가지 사용 권한 집합이 허용됩니다.
• ASP.NET 또는 다른 .NET Framework 코드가 스택에 있을 때만 호출되는 GAC의 어셈블리에는 명시적 권한 어설션이 필요하지 않습니다.

한 가지 시나리오는 .NET Framework 4에서 되돌릴 수 없습니다. 비 웹 부분 신뢰 애플리케이션은 더 이상 System.Web.dll 및 System.Web.Extensions.dll 특정 API를 호출할 수 없습니다. 이전 버전의 .NET Framework 웹이 아닌 부분 신뢰 애플리케이션에 AspNetHostingPermission 권한을 명시적으로 부여할 수 있었습니다. 그런 다음 이러한 애플리케이션은 System.Web.HttpUtility, System.Web.ClientServices.* 네임스페이스의 형식 및 멤버 자격, 역할 및 프로필과 관련된 형식을 사용할 수 있습니다. 웹이 아닌 부분 신뢰 애플리케이션에서 이러한 형식을 호출하는 것은 더 이상 .NET Framework 4에서 지원되지 않습니다.

참고

System.Web.HttpUtility 클래스의 HtmlEncode 및 HtmlDecode 기능이 새 .NET Framework 4 System.Net.WebUtility 클래스로 이동되었습니다. 사용 중인 유일한 ASP.NET 기능인 경우 새 WebUtility 클래스를 대신 사용하도록 애플리케이션의 코드를 수정합니다.

다음은 ASP.NET 4의 기본 CAS 구현에 대한 변경 내용에 대한 개략적인 요약입니다.

• ASP.NET 애플리케이션 도메인은 이제 같은 유형의 애플리케이션 도메인입니다. 부분 신뢰 및 완전 신뢰 부여 집합만 애플리케이션 도메인에서 사용할 수 있습니다.
• ASP.NET 부분 신뢰 부여 집합은 엔터프라이즈 수준, 머신 수준 또는 사용자 수준 CAS 정책과 독립적입니다.
• 3.5 및 3.5 SP1로 제공된 ASP.NET 어셈블리는 .NET Framework 4 투명도 모델을 사용하도록 변환되었습니다.
• ASP.NET AspNetHostingPermission 특성의 사용이 크게 감소했습니다. 이 특성의 대부분의 인스턴스는 공용 ASP.NET API에서 제거되었습니다.
• ASP.NET 빌드 공급자가 만든 동적으로 컴파일된 어셈블리가 어셈블리를 투명으로 명시적으로 표시하도록 업데이트되었습니다.
• 이제 모든 ASP.NET 어셈블리는 APTCA 특성이 웹 호스팅 환경에서만 적용되는 방식으로 표시됩니다. ClickOnce와 같은 부분적으로 신뢰할 수 있는 비 웹 호스팅 환경은 ASP.NET 어셈블리를 호출할 수 없습니다.

새 ASP.NET 4 코드 액세스 보안 모델에 대한 자세한 내용은 MSDN 웹 사이트의 ASP.NET 애플리케이션에서 코드 액세스 보안 사용을 참조하세요.

System.Web.Security 네임스페이스의 MembershipUser 및 기타 형식이 이동되었습니다.

ASP.NET 멤버 자격에 사용되는 일부 형식은 에서 System.Web.dll 새 System.Web.ApplicationServices.dll 어셈블리로 이동되었습니다. 클라이언트 형식 및 확장된 .NET Framework SKU 형식 간 아키텍처 계층화 종속성을 해결하기 위해 형식을 이동했습니다.

System.Web.ApplicationServices.dll ASP.NET 컴파일 시스템에서 기본적으로 사용되는 참조된 어셈블리 목록에 추가되었기 때문에 이러한 형식을 이동한 결과 웹 사이트 프로젝트에는 문제가 없습니다. 이전 버전의 ASP.NET 사용하여 만든 웹 사이트 프로젝트를 Visual Studio 2010에서 열어 ASP.NET 4로 업그레이드하는 경우 프로젝트는 오류 없이 컴파일됩니다.

마찬가지로 이전 버전의 ASP.NET 만든 웹 애플리케이션 프로젝트를 Visual Studio 2010에서 열어 ASP.NET 4로 업그레이드하는 경우 업그레이드 프로세스는 프로젝트에 System.Web.ApplicationServices.dll 대한 참조를 추가합니다. 따라서 업그레이드된 웹 애플리케이션 프로젝트도 오류 없이 컴파일됩니다.

이전 버전의 ASP.NET 사용하여 만든 컴파일된(이진) 파일도 멤버 자격 유형이 다른 어셈블리로 이동되더라도 ASP.NET 4에서 오류 없이 실행됩니다. 형식 전달 정보가 이러한 형식의 런타임 참조를 형식의 System.Web.dll 새 위치로 자동으로 라우팅하는 ASP.NET 4 버전에 추가되었습니다.

그러나 특정 멤버 자격 유형을 사용하고 이전 버전의 ASP.NET 업그레이드된 클래스 라이브러리는 ASP.NET 4 프로젝트에서 사용할 때 컴파일되지 않습니다. 예를 들어 클래스 라이브러리 프로젝트는 다음과 같은 오류를 컴파일하고 보고하지 못할 수 있습니다.

• The type 'System.Web.Security.MembershipUser' is defined in an assembly that is not referenced. You must add a reference to assembly 'System.Web.ApplicationServices, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'.

• The type name 'MembershipUser' could not be found. This type has been forwarded to assembly 'System.Web.ApplicationServices, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'. Consider adding a reference to that assembly.

클래스 라이브러리 프로젝트에서 참조를 추가하여 이 문제를 해결할 수 System.Web.ApplicationServices.dll.

다음 목록에서는 에서 System.Web.dll System.Web.ApplicationServices.dll 이동한 System.Web.Security 형식을 보여 있습니다.

• System.Web.Security.MembershipCreateStatus
• System.Web.Security.Membership.CreateUserException
• System.Web.Security.MembershipPasswordException
• System.Web.Security.MembershipPasswordFormat
• System.Web.Security.MembershipProvider
• System.Web.Security.MembershipProviderCollection
• System.Web.Security.MembershipUser
• System.Web.Security.MembershipUserCollection
• System.Web.Security.MembershipValidatePasswordEventHandler
• System.Web.Security.ValidatePasswordEventArgs
• System.Web.Security.RoleProvider
• System.Web.Configuration.MembershipPasswordCompatibilityMode

변경 내용에 대한 출력 캐싱 변경 내용 * HTTP 헤더

ASP.NET 1.0에서 버그로 인해 출력 캐시 설정으로 지정된 캐시된 Location="ServerAndClient" 페이지가 응답에서 HTTP 헤더를 Vary:* 내보낸 것입니다. 이로 인해 클라이언트 브라우저가 페이지를 로컬에 캐시하지 못했습니다.

ASP.NET 1.1에서는 헤더를 표시하지 않는 호출할 수 있는 System.Web.HttpCachePolicy.SetOmitVaryStar 메서드가 Vary:* 추가되었습니다. 이 메서드는 내보낸 HTTP 헤더를 변경할 때 잠재적으로 호환성이 손상되는 변경으로 간주되었기 때문에 선택되었습니다. 그러나 개발자는 ASP.NET 동작으로 인해 혼란스러워했으며 버그 보고서에 따르면 개발자는 기존 SetOmitVaryStar 동작을 인식하지 못합니다.

ASP.NET 4에서는 근본 문제를 해결하기로 결정했습니다. Vary:* HTTP 헤더는 다음 지시문을 지정하는 응답에서 더 이상 내보내지지 않습니다.

<%@OutputCache Location="ServerAndClient" %>

따라서 헤더를 표시하지 않 Vary:* 으려면 SetOmitVaryStar가 더 이상 필요하지 않습니다.

페이지의 @ OutputCache 지시문에 를 지정 Location="ServerAndClient" 하는 애플리케이션에서 이제 Location 특성 값의 이름으로 암시된 동작이 표시됩니다. 즉, SetOmitVaryStar 메서드를 호출하지 않고도 브라우저에서 페이지를 캐시할 수 있습니다.

애플리케이션의 페이지가 를 내보내 Vary:*야 하는 경우 다음 예제와 같이 AppendHeader 메서드를 호출합니다.

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

또는 출력 캐싱 위치 특성의 값을 "서버"로 변경할 수 있습니다.

Passport용 System.Web.Security 형식은 사용되지 않습니다.

ASP.NET 2.0에 기본 제공되는 Passport 지원은 Passport(현재 LiveID)의 변경으로 인해 몇 년 동안 사용되지 않고 지원되지 않습니다. 따라서 이제 System.Web.Security 의 Passport와 관련된 5가지 형식이 ObsoleteAttribute 특성으로 표시됩니다.

MenuItem.PopOutImageUrl 속성이 ASP.NET 4에서 이미지를 렌더링하지 못함

ASP.NET 3.5에서 MenuItem.PopOutImageUrl 속성을 사용하면 메뉴 항목에 표시되는 이미지의 URL을 지정하여 메뉴 항목에 동적 하위 메뉴가 있음을 나타낼 수 있습니다. 다음 예제에서는 ASP.NET 3.5의 태그에서 이 속성을 지정하는 방법을 보여 줍니다.

<asp:menu id="NavigationMenu"
    staticdisplaylevels="1"
    staticsubmenuindent="10" 
    orientation="Vertical" 
    target="_blank"  
    runat="server">
  <items>
    <asp:menuitem navigateurl="default2.aspx" 
        text="Home" 
        PopOutImageUrl="~/Images/Popout.gif"   
        tooltip="Home">
      <asp:menuitem navigateurl="default3.aspx"
          text="Movies"
          PopOutImageUrl="~/Images/Popout.gif"
          tooltip="Movies"> 
      </asp:menuitem>
    </asp:menuitem>
  </items>
</asp:menu>

ASP.NET 4의 디자인 변경으로 인해 속성이 MenuItem 클래스에 대해 설정된 경우 PopOutImageUrl에 대한 출력이 렌더링되지 않습니다. 대신 StaticPopOutImageUrl 속성 또는 DynamicPopOutImageUrl 속성을 사용하여 메뉴 컨트롤에서 직접 이미지 URL을 지정해야 합니다. 정적 메뉴를 사용하는 경우 Menu.StaticPopOutImageUrl 속성은 다음 예제와 같이 정적 메뉴 항목에 하위 메뉴가 있음을 나타내기 위해 표시되는 이미지의 URL을 지정합니다.

<asp:menu id="NavigationMenu"
    staticdisplaylevels="1"
    staticsubmenuindent="10" 
    orientation="Vertical" 
    target="_blank" 
    StaticPopOutImageTextFormatString="More..."
    StaticPopOutImageUrl="Images/Popout.gif"   
    runat="server">
  <items>
    <asp:menuitem navigateurl="default2.aspx" 
        text="Home" 
        tooltip="Home">
      <asp:menuitem navigateurl="default3.aspx"
          text="Movies"
          tooltip="Movies"> 
      </asp:menuitem>
    </asp:menuitem>
  </items>
</asp:menu>

동적 메뉴를 사용하는 경우 Menu.DynamicPopOutImageUrl 속성을 사용하여 동적 메뉴 항목에 하위 메뉴가 있음을 나타내는 이미지의 URL을 지정합니다. 다음 예제는 이전 예제와 비슷하지만 동적 메뉴에 대해 DynamicPopOutImageUrl 속성을 설정하는 방법을 보여 주세요.

<asp:menu id="NavigationMenu"
    staticdisplaylevels="1"
    staticsubmenuindent="10" 
    orientation="Vertical" 
    target="_blank" 
    DynamicPopOutImageTextFormatString="More..."
    DynamicPopOutImageUrl="Images/Popout.gif" 
    runat="server">
  <items>
    <asp:menuitem navigateurl="default2.aspx" 
        text="Home" 
        tooltip="Home">
      <asp:menuitem navigateurl="default3.aspx"
          text="Movies"
          tooltip="Movies"> 
      </asp:menuitem>
    </asp:menuitem>
  </items>
</asp:menu>

Menu.DynamicPopOutImageUrl 속성이 설정되지 않고 Menu.DynamicEnableDefaultPopOutImage 속성이 false로 설정된 경우 이미지가 표시되지 않습니다. 마찬가지로 StaticPopOutImageUrl 속성이 설정되지 않고 StaticEnableDefaultPopOutImage 속성이 false로 설정된 경우 이미지가 표시되지 않습니다.

이러한 속성에 대한 경로를 설정할 때 백슬래시() 대신 슬래시(/)를 사용합니다. 자세한 내용은 Menu.StaticPopOutImageUrl 및 Menu.DynamicPopOutImageUrl 경로에 이 문서의 다른 곳에 백슬래시가 포함되어 있으면 이미지를 렌더링하지 못합니다 .

Menu.StaticPopOutImageUrl 및 Menu.DynamicPopOutImageUrl 경로에 백슬래시가 포함되어 있을 때 이미지를 렌더링하지 못

ASP.NET 4에서 Menu.StaticPopOutImageUrl 및 Menu.DynamicPopOutImageUrl 속성을 사용하여 지정한 이미지는 경로에 백래시()가 포함된 경우 렌더링되지 않습니다. 이는 이전 버전의 ASP.NET 변경된 것입니다.

메뉴 컨트롤 태그 의 다음 예제에서는 백슬래시가 포함된 경로를 사용하여 설정된 StaticPopOutImageUrl 속성을 보여 줍니다. ASP.NET 4에서는 속성에 지정된 이미지가 렌더링되지 않습니다.

<asp:menu id="NavigationMenu"
    staticdisplaylevels="1"
    staticsubmenuindent="10" 
    orientation="Vertical 
    target="_blank" 
    StaticPopOutImageTextFormatString="More..."
    StaticPopOutImageUrl="Images\Popout.gif"   
    runat="server">
  <items>
    <asp:menuitem navigateurl="default2.aspx" 
        text="Home" 
        tooltip="Home">
      <asp:menuitem navigateurl="default3.aspx"
          text="Movies"
          tooltip="Movies"> 
      </asp:menuitem>
    </asp:menuitem>
  </items>
</asp:menu>

이 문제를 해결하려면 정방향 슬래시(/)를 사용하도록 StaticPopOutImageUrl 및 DynamicPopOutImageUrl 속성에 지정된 경로 값을 변경합니다. 다음 예제에서는 이 변경 사항을 보여줍니다.

<asp:menu id="NavigationMenu"
    staticdisplaylevels="1"
    staticsubmenuindent="10" 
    orientation="Vertical 
    target="_blank" 
    StaticPopOutImageTextFormatString="More..."
    StaticPopOutImageUrl="Images/Popout.gif"   
    runat="server">
  <items>
    <asp:menuitem navigateurl="default2.aspx" 
        text="Home" 
        tooltip="Home">
      <asp:menuitem navigateurl="default3.aspx"
          text="Movies"
          tooltip="Movies"> 
      </asp:menuitem>
    </asp:menuitem>
  </items>
</asp:menu>

MenuItem.PopOutImageUrl 속성이 변경되었으므로 이전 버전의 ASP.NET ASP.NET 4로 마이그레이션된 애플리케이션도 영향을 받을 수 있습니다. 자세한 내용은 MenuItem.PopOutImageUrl 속성이 이 문서의 다른 ASP.NET 4에서 이미지를 렌더링하지 못함 을 참조하세요.

고지 사항

본 문서는 예비 문서이며, 여기에 설명한 소프트웨어의 최종 상업적 출시 전에 크게 변경될 수 있습니다.

이 문서에 포함된 정보는 게시 날짜 당시 논의된 문제에 대한 Microsoft Corporation의 현재 관점을 나타냅니다. Microsoft는 변화하는 시장 상황에 대응해야 하므로 Microsoft의 약속으로 해석되지 않아야 하며, Microsoft는 게시 날짜 이후 제시된 정보의 정확성을 보증하지 않습니다.

이 백서는 정보 제공만을 목적으로 합니다. Microsoft는 이 문서에 있는 정보에 대한 명시적 또는 묵시적, 법적인 보증을 하지 않습니다.

해당 저작권법을 준수하는 것은 사용자의 책임입니다. 저작권에서의 권리와는 별도로 이 설명서의 어떠한 부분도 Microsoft의 명시적인 서면 승인 없이는 어떠한 형식이나 수단(전기적, 기계적, 복사기에 의한 복사, 디스크 복사 또는 다른 방법) 또는 목적으로도 복제되거나 검색 시스템에 저장 또는 도입되거나 전송될 수 없습니다.

Microsoft는 이 설명서 본안에 관련된 특허권, 상표권, 저작권, 또는 기타 지적 재산권 등을 보유할 수도 있습니다. 서면 사용권 계약에 따라 Microsoft로부터 귀하에게 명시적으로 제공된 권리 이외에, 이 설명서의 제공은 귀하에게 이러한 특허권, 상표권, 저작권 또는 기타 지적 재산권 등에 대한 어떠한 사용권도 허용하지 않습니다.

달리 명시되지 않는 한, 예제 회사, 조직, 제품, 도메인 이름, 전자 메일 주소, 로고, 사람, 장소 및 이벤트는 가상이며 실제 회사, organization, 제품, 도메인 이름, 전자 메일 주소, 로고, 사람, 장소 또는 이벤트와의 연관이 없거나 유추되어야 합니다.

© 2010 Microsoft Corporation. All rights reserved.

Microsoft 및 Windows는 미국 및/또는 기타 국가에서 Microsoft Corporation의 상표이거나 등록된 상표입니다.

여기에 언급된 실제 회사와 제품의 이름은 각각 해당 소유자의 상표일 수 있습니다.