다음을 통해 공유

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 and 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 컨트롤은 이름 특성을 렌더링하지 않습니다.
  • 테이블 컨트롤은 더 이상 특성을 렌더링하지 border="0" 않습니다.
  • 사용자 입력(예: 레이블 컨트롤)을 위해 설계되지 않은 컨트롤은 disabled="disabled" 속성이 false로 설정되어 있거나 컨테이너 컨트롤에서 이 설정을 상속하는 경우 특성을 더 이상 렌더링 하지 않습니다.

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

닫히지 않은 style 특성이 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 환경에서, 양식 인증 쿠키와 같은 데이터가 .NET Framework 버전을 넘나들며 작동해야 하는 경우 애플리케이션이 영향을 받을 수 있습니다. 이전 HMACSHA1 알고리즘을 사용하도록 ASP.NET 4 웹 애플리케이션을 구성하려면 파일에 다음 설정을 Web.config 추가합니다.

<machineKey validation="SHA1" />

.NET Framework 4(및 따라서 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 3.5 애플리케이션의 Web.config 파일을 자동으로 수정하여 ASP.NET 4에 대한 적절한 설정을 포함합니다.

그러나 다시 컴파일하지 않고 .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 파일과 비교하여 애플리케이션의 관리되는 구성을 잘못 병합합니다. 따라서 .NET Framework 3.5 이상의 애플리케이션 수준 Web.config 파일에는 IIS 7 유효성 검사 오류가 발생하지 않도록 system.web.extensions 구성 섹션 정의(요소)가 있어야 합니다.

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

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 구성 섹션 정의 및 구성 섹션 그룹 정의를 삭제하거나 주석으로 처리합니다. 이러한 정의는 일반적으로 애플리케이션 수준 Web.config 파일의 맨 위에 있으며 configSections 요소 및 해당 자식으로 식별할 수 있습니다.

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

ASP.NET 2.0 또는 ASP.NET 3.5 애플리케이션 환경에서 ASP.NET 4 자식 애플리케이션이 시작되지 않습니다.

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

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

이 문제를 해결하고 자식 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를 실행하는 운영 체제에서만 필요합니다.

부모 애플리케이션의 파일(ASP.NET 2.0 또는 ASP.NET 3.5를 실행하는 애플리케이션)의 configSections 정의를 Web.config the.NET Framework 2.0의 루트 Web.config 파일로 이동합니다. IIS 7 및 IIS 7.5 네이티브 구성 시스템은 구성 파일의 계층 구조를 병합할 때 configSections 요소를 검색합니다. 부모 웹 애플리케이션의 파일에서 루트 Web.config 파일로 Web.config 정의를 이동하면 자식 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 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 참조하는 부분 신뢰 구성 파일에는 해당 이름의 사용 권한 집합이 포함되어 있지 않습니다.

현재 사용 가능한 SharePoint 버전은 ASP.NET 호환되지 않습니다. 따라서 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에서 실행되는 ASP.NET 2.0 애플리케이션(Windows Server 2003 또는 Windows Server 2003 R2)에서 다음과 같은 오류가 발생할 수 있습니다.

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 페이지는 정상적으로 실행됩니다.

그러나 관리 코드와 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 개체로 확인되는 확장 없는 URL, 관리되는 요청 등)에 대해 실행해야 하는 경우 페이지의 System.Web.UI.HtmlControls.HtmlForm 컨트롤의 Action 속성을 비어 있지 않은 문자열로 명시적으로 설정하여 영향을 받는 .aspx 페이지를 수정합니다. 예를 들어 기본 문서가 있는 Default.aspx경우 HtmlForm 컨트롤의 Action 속성을 "Default.aspx"로 명시적으로 설정하도록 페이지의 코드를 수정합니다.

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

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

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

<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.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를 사용할 필요가 없습니다.

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

애플리케이션에서 페이지가 Vary:*를 내보내야 할 경우, 다음 예제와 같이 AppendHeader 메서드를 호출하십시오.

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

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

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이 경로에 백슬래시가 포함될 때 이미지를 렌더링하지 못함을 참조하세요.

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 Corporation의 명시적인 서면 허가 없이 복제, 저장 또는 검색 시스템에 도입되거나 어떤 형태로든 전송되거나(전자, 기계, 복사, 기록 또는 기타) 목적으로 전송될 수 없습니다.

Microsoft는 이 문서의 주제를 다루는 특허, 특허 출원, 상표, 저작권 또는 기타 지적 재산권을 가질 수 있습니다. 서면 사용권 계약에 따라 Microsoft로부터 귀하에게 명시적으로 제공된 권리 이외에, 이 설명서의 제공은 귀하에게 이러한 특허권, 상표권, 저작권, 또는 기타 지적 재산권 등에 대한 어떠한 사용권도 허용하지 않습니다.

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

© 2010 Microsoft Corporation. 모든 권리 보유.

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

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

  • Last updated on