Windows Vista 및 Windows Server 2008에서 ASP.NET 1.1에서 IIS 7.0으로 업그레이드

IIS 팀별

소개

Windows Vista™ 이상 Windows 운영 체제로 이동하는 ASP.NET 애플리케이션 개발자의 경우 IIS 7.0 이상은 이전 IIS 버전에 비해 상당한 발전을 나타냅니다. IIS 통합 모드는 향상된 보안 및 새로운 애플리케이션 가능성을 제공합니다.

Windows Vista로 이동하는 대부분의 개발자는 Microsoft Windows XP 운영 체제에서 Windows® Vista로 업그레이드하고 프로세스에서 ASP.NET 애플리케이션을 업그레이드합니다. 또는 다른 Windows 운영 체제에서 개발된 ASP.NET 애플리케이션을 Windows Vista에 설치합니다.

이 문서에서는 애플리케이션이 새 운영 체제에서 작동하려면 수행해야 하는 중요한 설치 후 및 업그레이드 후 구성 단계를 자세히 설명합니다. ASP.NET 애플리케이션에 영향을 주는 클래식 모드와 IIS 통합 모드 간의 변경 내용과 이러한 알려진 문제를 해결하는 방법을 설명합니다.

IIS 7.0 이상의 중요한 개선 사항 중 하나는 웹 애플리케이션이 관리 코드 애플리케이션 또는 비관리 코드 애플리케이션에서 단일 요청 처리 파이프라인을 사용할 수 있도록 하는 통합 파이프라인 기능입니다. 또한 새 파이프라인 모델은 동일한 기능의 두 가지 개별 구현에서 발생하는 중복 동작을 줄입니다.

예를 들어 이전 릴리스에서 IIS 및 ASP.NET 이벤트 및 처리기 모듈에 대한 액세스를 공유하지 않는 별도의 요청 파이프라인을 구현했습니다. 인증은 각 파이프라인 내에서 독립적으로 수행되었습니다. 새 모델에서 IIS 및 ASP.NET 인증을 한 번 수행할 수 있습니다.

이 통합의 다른 이점은 다음과 같습니다.

• 양식 인증 및 IIS 콘텐츠 형식(예: 정적 및 클래식 ASP 페이지)을 사용하는 역할과 같은 서비스를 ASP.NET.
• ISAPI 확장 또는 CGI가 아닌 관리 코드 및 ASP.NET 파이프라인 모듈을 사용하여 확장되는 IIS 기능입니다.
• 이벤트 추적 및 오류 로깅의 통합으로 인한 간소화된 문제 해결
• ASP.NET IIS 간에 애플리케이션 구성을 공유합니다.

이 문서에서는 이전 버전의 IIS에서 IIS 7.0 이상으로 마이그레이션하는 ASP.NET 애플리케이션의 호환성 문제를 살펴보고 특히 클래식 모드에서 통합 모드에서 통합 파이프라인 사용으로 전환하는 것과 관련된 차이점에 중점을 둡니다.

ASP.NET 및 IIS 통합의 기능 및 이점에 대한 전체 개요는 IIS 7.0 이상과의 통합 ASP.NET 문서를 참조하세요.

이전 버전의 IIS에서 Windows Vista로 업그레이드

다음 차트는 사용 가능한 Windows Vista 버전에서 IIS 7.0의 가용성을 보여 줍니다.

Windows Vista 버전	IIS 7.0 가용성
Home Basic	N
Home Premium	Y
비즈니스	Y
Ultimate	Y

Windows Vista에서 업그레이드 시나리오 ASP.NET

다음 표에서는 Windows Vista에서 ASP.NET 이전 버전의 Windows 운영 체제에서 ASP.NET 지원되는 업그레이드 경로에 대해 간략하게 설명합니다. 문제가 언급된 경우 업그레이드 제한 사항 및 제한 사항에 대한 자세한 내용은 다음 섹션을 참조하세요.

또한 이 표에서는 서버 OS 버전에서 클라이언트 OS 버전으로의 업그레이드를 사용할 수 없음을 보여 줍니다. 대신 서버 OS가 현재 설치된 컴퓨터에서 Vista의 클린 설치를 수행해야 합니다.

운영 체제	IIS 버전	.NET Framework 버전	Windows Vista/IIS 7.0으로 업그레이드할 때 고려 사항
Windows 2000 Server	IIS 5.0	1.0, 1.1, 2.0	Windows Vista로 업그레이드할 수 없습니다.
Windows 2000 Professional	IIS 5.0	1.0, 1.1, 2.0	OS를 새로 설치해야 합니다.
Windows Server 2003	IIS 6.0	1.0, 1.1, 2.0	Windows Vista로 업그레이드할 수 없습니다.
Windows XP 홈	해당 없음	1.0, 1.1, 2.0	Windows XP Home에는 IIS가 포함되지 않았습니다. 사용자는 Windows Vista에서 IIS 7.0 이상을 새로 설치하기로 결정할 수 있습니다.
Windows XP Professional	IIS 5.1	1.0	.NET Framework 1.0은 Windows Vista에서 지원되지 않습니다. ASP.NET 1.0 애플리케이션은 최소 ASP.NET 1.1(권장 ASP.NET 2.0)으로 업그레이드해야 합니다.
1.1	업그레이드 후에는 수동 구성이 필요합니다(이 문서의 뒷부분 참조).
2.0	ASP.NET 2.0을 통합 모드로 구성하려면 업그레이드 후 IIS 설정 옵션에서 ASP.NET 선택해야 합니다.
Windows XP Tablet PC	IIS 5.1	1.0	.NET Framework 1.0은 Windows Vista에서 지원되지 않습니다. ASP.NET 1.0 애플리케이션은 최소 ASP.NET 1.1(권장 ASP.NET 2.0)으로 업그레이드해야 합니다.
1.1	업그레이드 후에는 수동 구성이 필요합니다(이 문서의 뒷부분 참조).
2.0	ASP.NET 2.0을 통합 모드로 구성하려면 업그레이드 후 IIS 설정 옵션에서 ASP.NET 선택해야 합니다.
Windows XP Professional x64	IIS 5.1	1.1, 2.0	OS를 새로 설치해야 합니다.

설치 후 애플리케이션 구성

설치 또는 Windows Vista로 업그레이드한 직후 사용자는 추가 구성 단계를 수행하여 애플리케이션이 작동할 수 있도록 해야 합니다. 설치 후 구성은 각 애플리케이션에서 사용하는 ASP.NET 버전에 따라 달라집니다.

ASP.NET 1.1 애플리케이션 구성

.NET Framework 1.1(ASP.NET 1.1 애플리케이션을 실행하는 경우 필요)을 설치하기 전에 사용자는 다음 두 단계를 수행하여 ASP.NET 애플리케이션을 사용하도록 설정해야 합니다.

프로시저

ASP.NET 애플리케이션을 실행하는 각 IIS 애플리케이션 풀은 애플리케이션에 사용되는 ASP.NET 버전과 일치하는 .NET Framework 버전을 사용하여 명시적으로 구성해야 합니다. 애플리케이션 풀당 하나의 ASP.NET 버전만 실행할 수 있으므로 각 ASP.NET 버전에 대해 별도의 애플리케이션 풀을 사용해야 합니다.

IIS 관리자 콘솔에서 애플리케이션 풀을 연 다음 애플리케이션 풀을 마우스 오른쪽 단추로 클릭하고 기본 설정을 선택합니다. 그림 1에 표시된 애플리케이션 풀 편집 대화 상자에서 애플리케이션 풀에 구성된 애플리케이션과 일치하는 .NET Framework 버전을 선택한 다음 확인을 클릭합니다.

그림 1: 애플리케이션 풀 설정 편집

클래식 모드에서 ASP.NET 1.1 사용

ASP.NET 1.1은 설치 또는 업그레이드 후 ASP.NET 기본 설정인 클래식 모드에서 실행될 때 IIS ISAPI 확장을 사용합니다(ISAPI 확장이 필요하지 않은 Windows Vista의 통합 모드에서도 ASP.NET 2.0을 실행할 수 있음).

IIS 관리 콘솔에서 ISAPI 및 CGI 제한 구성을 사용하여 애플리케이션에서 사용하는 ASP.NET 버전을 명시적으로 허용해야 합니다. IIS 관리자를 열고 ISAPI 및 CGI 제한을 선택합니다. ISAPI 및 CGI 제한 페이지에서 제한 열에서 허용되지 않음으로 설정된 각 버전의 ASP.NET 선택하고 페이지 오른쪽에 있는 허용됨 링크를 클릭하여 설정을 허용으로 변경합니다.

그림 2는 ASP.NET 1.1에 사용되는 Aspnet_isapi.dll 어셈블리 버전이 선택된 ISAPI 및 CGI 제한 페이지의 예를 보여 줍니다. 그림에서 이 ISAPI 확장에 대한 설정을 허용 안 됨에서 허용됨으로 변경해야 합니다.

그림 2: ISAPI 및 CGI 제한 목록

ASP.NET 2.0 애플리케이션 구성

.NET Framework 2.0은 Windows Vista 설치 중에 설치되므로 ASP.NET 2.0은 설치 후 서버에 이미 있습니다. 그러나 ASP.NET 2.0 애플리케이션에 대한 Vista의 ASP.NET 구성을 완료하려면 사용자는 다음 두 단계를 수행해야 합니다.

1단계

Windows Vista 패키지 관리자(제어판\프로그램 및 기능\Windows 기능 켜기 또는 끄기)에서 그림 3과 같이 ASP.NET 선택하고 확인을 클릭합니다.

참고

이 단계 전에 컴퓨터에 ASP.NET 이미 설치되어 있는 경우 이러한 방식으로 ASP.NET 선택하면 추가 구성 단계가 완료됩니다.

그림 3: Windows Vista 설치 - Windows 기능

2단계

ASP.NET 애플리케이션을 실행하는 각 IIS 애플리케이션 풀은 애플리케이션에 사용되는 ASP.NET 버전과 일치하는 .NET Framework 버전을 사용하여 명시적으로 구성해야 합니다. 애플리케이션 풀당 하나의 ASP.NET 버전만 실행할 수 있으므로 각 ASP.NET 버전에 대해 별도의 애플리케이션 풀을 사용해야 합니다.

IIS 관리자에서 애플리케이션 풀을 연 다음 애플리케이션 풀을 마우스 오른쪽 단추로 클릭하고 기본 설정을 선택합니다. 그림 4에 표시된 애플리케이션 풀 편집 대화 상자에서 애플리케이션 풀에 구성된 애플리케이션과 일치하는 .NET Framework 버전을 선택한 다음 확인을 클릭합니다.

그림 4: 애플리케이션 풀 & 통합 모드

응용 프로그램 풀 설정

이전 버전의 Windows 운영 체제에서 ASP.NET 애플리케이션을 Windows Vista로 업그레이드하는 경우 애플리케이션은 다음과 같이 IIS 애플리케이션 격리 설정을 기반으로 애플리케이션 풀에 구성됩니다.

업그레이드 전 IIS 격리 구성	IIS 응용 프로그램 풀	IIS 애플리케이션 풀 ID
낮음	AppPool Low	NT AUTHORITY\NETWORK SERVICE
중간	AppPool 보통	<IWAM_machine 이름>
높음	애플리케이션은 애플리케이션 이름과 일치하는 애플리케이션 풀에서 구성됩니다.	<IWAM_machine 이름>

ASP.NET v1.0은 Windows Vista에서 지원되지 않습니다.

.NET Framework 1.0은 Windows Vista에서 지원되지 않으므로 ASP.NET 1.0 애플리케이션을 ASP.NET 1.1 이상으로 업그레이드해야 합니다. 최신 버전의 ASP.NET 더 나은 성능 및 유지 관리 기능을 활용하려면 ASP.NET 1.0 애플리케이션을 ASP.NET 2.0으로 업그레이드하는 것이 좋습니다.

HTTP 처리기

Windows Vista에서 IIS 7.0 이상으로 업그레이드하면 전역 수준에서 구성된 사전 조건의 HTTP 처리기만 업그레이드됩니다. 사이트 수준에서 구성된 처리기는 업그레이드되지 않습니다.

병렬 지원

IIS에서 서로 다른 버전의 ASP.NET(예: 1.1 및 2.0)에서 개발된 애플리케이션을 나란히 실행할 수 있습니다. IIS 애플리케이션 풀에서 애플리케이션을 구성해야 합니다. 이 풀은 애플리케이션이 개발된 ASP.NET 버전에 대해 구성되어야 합니다. 애플리케이션 풀당 하나의 ASP.NET 버전만 구성할 수 있습니다.

.NET Framework 1.1에는 64비트 Windows Vista의 WoW 64 구성이 필요합니다.

.NET Framework 1.1이 64비트 버전의 Windows Vista에 설치된 경우 ASP.NET 올바르게 설정되지 않습니다. 64비트 버전의 Windows Vista에 .NET Framework 1.1을 설치한 후에는 IIS 관리 도구를 사용하여 전역 수준에서 WOW 64를 사용하여 실행되도록 애플리케이션을 수동으로 구성해야 합니다.

애플리케이션에서 사용하는 파이프라인 모드 구성

IIS는 새 애플리케이션에 대해 새 통합 모드를 사용하도록 구성됩니다. 기본 동작입니다. 파이프라인 모드는 애플리케이션 풀 설정을 사용하여 구성됩니다. 다음 중 하나를 사용하여 이러한 설정을 변경합니다.

• IIS 관리 도구
• APPCMD.EXE 명령줄 도구
• 텍스트 편집기를 사용하여 애플리케이션 구성 파일을 편집합니다.

기존 컴퓨터를 IIS 7.0 이상으로 업그레이드하는 경우 애플리케이션은 기본적으로 클래식 모드에서 실행되도록 구성됩니다. 클래식 모드는 이전 버전의 IIS에서 HTTP 파이프라인 구현에 대한 특정 종속성이 있는 애플리케이션에 대한 호환성을 제공합니다.

그러나 기존 애플리케이션을 IIS 7.0 이상을 실행하는 컴퓨터로 가져오고 웹 사이트를 복사하는 경우 사용되는 파이프라인 모드는 애플리케이션이 실행되도록 구성된 애플리케이션 풀의 설정에 따라 결정됩니다.

예를 들어 컴퓨터에 애플리케이션을 복사하고 기본 애플리케이션 풀에서 실행되도록 구성하는 경우 기본적으로 통합 모드로 구성된 해당 애플리케이션 풀의 설정을 사용하여 실행됩니다. 애플리케이션의 파이프라인 모드를 변경하려면 기본 애플리케이션 풀 설정을 변경하거나 원하는 설정을 사용하여 새 애플리케이션 풀을 만듭니다.

"ASP.NET 애플리케이션을 IIS 7.0 이상 통합 모드로 마이그레이션" 섹션에서 IIS 7.0 이상과의 통합 ASP.NET 문서에서 통합 모드를 사용하도록 기존 애플리케이션을 구성하는 방법에 대해 자세히 알아보세요. 애플리케이션 구성 설정을 변경하기 위한 지침을 제공합니다.

호환성

이전 버전의 IIS에 대해 개발되고 나중에 IIS 7.0 이상에서 통합 모드를 사용하도록 구성된 ASP.NET 파이프라인 모듈은 동작 또는 기타 호환성 문제에 차이가 발생할 수 있습니다. 이러한 문제는 이전 IIS 버전의 파이프라인과 IIS 7.0 이상의 모듈식 디자인과 통합 HTTP 파이프라인 간의 아키텍처 차이로 인해 발생합니다.

이 문서의 나머지 섹션에서는 애플리케이션에서 발생할 수 있는 잠재적인 호환성 문제에 대해 설명하고 제안된 해결 방법을 포함합니다. 제안된 해결 방법이 구현하기에 실용적이지 않은 경우 호환성 문제를 방지하도록 클래식 모드에서 실행되도록 애플리케이션을 구성합니다.

통합 모드와 클래식 모드의 알려진 차이점

다음은 두 모드 간의 알려진 문제 목록을 제공합니다. 이 목록을 주의 깊게 읽어 보세요.

통합 모드에서는 httpApplication::Init에서 발생하는 예외에 대해 Application_OnError 호출되지 않습니다.

통합 모드에서는 Application.Error 이벤트를 사용하여 애플리케이션 또는 모듈을 초기화하는 동안 발생하는 예외를 가로챌 수 없습니다.

또한 Server.ClearError를 사용하여 오류로부터 복구하는 애플리케이션은 애플리케이션 초기화 중에 오류를 지울 수 없습니다. 초기화 중에 애플리케이션이 오류를 무시하지 못하도록 하기 위한 것입니다. 발생하는 각 예외에 대한 오류 정보를 기록하는 애플리케이션은 애플리케이션 초기화 중에 발생하는 오류를 기록할 수 없지만 이러한 오류는 웹 이벤트 및 HTTP 응답을 사용하여 보고됩니다.

애플리케이션이 초기화 중에 이러한 예외 처리를 구현해야 하는 경우 통합 모드가 아닌 클래식 모드에서 실행되어야 합니다.

EndRequest의 Server.ClearError가 통합 모드에서 예외 메시지를 지우지 않음

통합 모드에서 EndRequest에서 Server.ClearError를 호출하면 이전에 요청 처리에서 예외가 발생한 경우 예외 응답이 지워지지 않습니다. EndRequest에서 예외 메시지를 지우는 애플리케이션은 응답에서 예외 출력을 제거할 수 없습니다.

애플리케이션에서 EndRequest 중에 이러한 예외 처리를 구현해야 하는 경우 통합 모드가 아닌 클래식 모드에서 실행되어야 합니다.

통합 모드 애플리케이션은 예외가 형식화되고 응답에 기록된 후 EndRequest에서 응답에 쓸 수 있습니다.

통합 모드에서는 에 쓰고 예외가 발생한 후 작성된 추가 응답을 표시할 수 있습니다.

클래식 모드에서는 발생하지 않습니다. 요청 중에 오류가 발생하고 예외가 발생한 후 애플리케이션이 EndRequest의 응답에 쓰는 경우 EndRequest로 작성된 응답 정보가 표시됩니다. 이는 처리되지 않은 예외를 포함하는 요청에만 영향을 줍니다.

예외 후 응답에 쓰지 않도록 하려면 애플리케이션이 응답에 쓰기 전에 HttpContext.Error 또는 HttpResponse.StatusCode를 검사 합니다.

통합 모드에서 ASP.NET 응답이 비어 있을 때 콘텐츠 형식을 더 이상 표시하지 않습니다.

통합 모드에서 ASP.NET 처리기는 응답이 비어 있더라도 모듈에서 명시적으로 설정할 때 콘텐츠 형식 헤더를 생성합니다. 일부 애플리케이션은 빈 응답에 대한 콘텐츠 형식을 생성합니다. 원하는 경우 NULL로 설정하여 콘텐츠 형식 헤더를 명시적으로 제거하도록 애플리케이션을 수정합니다.

Forms 인증의 다른 Windows ID

애플리케이션에서 Forms 인증을 사용하고 익명 액세스가 허용되는 경우 통합 모드 ID는 다음과 같은 방식으로 클래식 모드 ID와 다릅니다.

• ServerVariables["LOGON_USER"]가 채워집니다.
• Request.LogognUserIdentity는 [NT AUTHORITY\INTERNET USER] 계정 대신 [NT AUTHORITY\NETWORK SERVICE] 계정의 자격 증명을 사용합니다.

이 동작은 통합 모드의 단일 단계에서 인증이 수행되기 때문에 발생합니다. 반대로 클래식 모드에서는 익명 액세스를 사용하는 IIS에서 먼저 인증을 수행하고 양식 인증을 사용하는 ASP.NET 인증을 사용합니다. 따라서 인증 결과는 항상 단일 사용자(Forms 인증 사용자)입니다. 양식 인증 사용자 자격 증명이 IIS와 ASP.NET 간에 동기화되므로 AUTH_USER/LOGON_USER 동일한 사용자를 반환합니다.

부작용은 LOGON_USER, HttpRequest.LogonUserIdentity 및 가장이 더 이상 클래식 모드를 사용하여 IIS가 인증한 익명 사용자 자격 증명에 액세스할 수 없다는 것입니다.

기본 Authentication_OnAuthenticate 이벤트는 통합 모드에서 발생하지 않습니다.

통합 모드에서는 DefaultAuthenticationModule.Authenticate 이벤트가 더 이상 발생하지 않습니다. 클래식 모드에서는 인증이 발생하지 않은 경우 이 이벤트가 발생합니다. 통합 모드에서 인증 모드=없음을 설정하고 DefaultAuthentication.Authenticate 이벤트를 구독하는 애플리케이션은 이 기능이 통합 모드에서 지원되지 않음을 나타내는 예외를 받습니다. 이 패턴을 사용하는 인증 체계는 작동하지 않습니다.

이 변경을 해결하기 위해 통합 모드 애플리케이션은 AuthenticateRequest를 대신 구독할 수 있습니다.

통합 모드 Request.RawUrl에는 RewritePath가 호출된 후 새 쿼리 문자열이 포함됩니다.

통합 모드에서 새 쿼리 문자열이 있는 URL에서 RewritePath가 호출된 후 Request.RawUrl 속성에는 새 쿼리 문자열이 포함됩니다. 클래식 모드에서는 이전 쿼리 문자열을 포함합니다.

이 변경을 해결하려면 이전 동작에 의존하지 않도록 애플리케이션을 다시 작성합니다.

Passport 네트워크 자격 증명 인증은 Windows Vista에서 지원되지 않습니다.

Passport 네트워크 자격 증명 기능은 Windows Vista 및 Microsoft Windows Server® 2008 운영 체제에서 제거되므로 Passport Network 자격 증명 인증 애플리케이션은 ISAPI 또는 통합 모드에서 기본적으로 작동하지 않습니다.

PassportAuthentication 모듈이 통합 파이프라인의 일부가 아닙니다.

통합 모드에서 ASP.NET Passport 인증 모듈은 기본적으로 파이프라인에서 제거됩니다. 애플리케이션에서 사용하는 경우 파이프라인에 다시 추가될 수 있습니다. 위에서 설명한 대로 기본 Passport Network 자격 증명 기능은 Windows Vista 및 Microsoft Windows Server 2008에서 제거되므로 Passport Network 자격 증명 인증 애플리케이션은 ISAPI 또는 통합 모드에서 기본적으로 작동하지 않습니다.

쿼리 문자열에 있는 크고 유효한 양식 인증 티켓(길이 <= 4096바이트)은 IIS 7.0 이상에서 거부됩니다.

IIS는 Forms 인증, 세션 상태 및 익명 ID에서 총 4096바이트를 초과하는 것과 같이 쿠키가 없는 ASP.NET 티켓이 큰 요청을 거부합니다. 보안상의 이유로 큰 쿼리 문자열을 사용하는 버퍼 오버플로 익스플로잇을 방지합니다. 사용자 지정 데이터를 저장하거나 Forms 인증 티켓에 매우 큰 사용자 이름을 사용하는 애플리케이션은 쿼리 문자열이 너무 커서 요청이 거부되는 것을 볼 수 있습니다.

이 동작을 변경하려면 IIS 요청 필터링 구성 섹션에서 최대 쿼리 문자열 크기를 조정합니다.

통합 모드에서 ASP.NET 요청 시간 제한은 요청 중에 여러 번 적용되므로 요청이 더 오래 실행될 수 있습니다.

통합 모드에서는 파이프라인의 새 전환마다 관리되는 요청 실행 시간 초과가 다시 설정됩니다. 즉, 단일 제한 시간이 제한 시간에 설정된 최대 시간을 초과하지 않는 한 요청은 최대(시간 제한 *(모듈 알림의#))를 사용할 수 있습니다.

ASP.NET 모듈의 수와 이러한 모듈이 얼마나 잘 병합되는지에 따라 느린 요청이 중단되지 않거나 중단되기까지 훨씬 더 오래 걸릴 수 있습니다. 시간 제한 설정의 길이를 줄여 이 동작을 방지합니다.

추적 설정이 Server.Transfer 대상 페이지로 전송되지 않음

통합 모드는 Server.Transfer 작업의 대상으로 추적 설정을 전송하는 것을 지원하지 않습니다.

httpcontext.Current.Response.Write() 메서드는 Application_Onstart()에서 작동할 수 없습니다.

통합 모드에서 애플리케이션은 Application_Onstart() 메서드에서 Http.Current.Response.Write()를 호출할 수 없습니다.

HttpRequest.LogonUserIdentity는 PostAuthenticateRequest 전에 액세스하면 예외를 throw합니다.

통합 모드에서 HttpRequest.LogonUserIdentity 속성은 PostAuthenticateRequest 전에 액세스할 때 예외를 throw합니다. 모듈이 PostAuthenticateRequest 전에 이 속성에 액세스하면 예외가 throw됩니다.

이 동작을 방지하려면 애플리케이션에서 이 속성에 액세스하지 마세요. 또는 PostAuthenticateRequest가 완료된 후에 액세스합니다.

통합 모드에서 ASP.NET 모듈은 익명 인증을 사용하지 않도록 설정된 경우 IIS 7.0 이상에 대한 첫 번째 인증되지 않은 요청을 받습니다.

통합 모드에서 익명 인증 이외의 IIS 인증 체계를 사용하는 경우 필요한 자격 증명을 포함하지 않는 클라이언트의 첫 번째 요청이 BeginRequest 및 AuthenticateRequest 단계의 ASP.NET 모듈에 표시됩니다.

반면 클래식 모드에서는 ASP.NET 처리할 기회가 있기 전에 IIS가 401 챌린지로 거부하기 때문에 ASP.NET 애플리케이션에서 이러한 요청을 볼 수 없습니다.

즉, ASP.NET 모듈은 BeginRequest 및 AuthenticateRequest 단계에서 추가 요청을 볼 수 있습니다. 요청은 웹 이벤트 및 BeginRequest 또는 EndRequest에서 수행된 모든 사용자 지정 로깅에 표시됩니다.

ASP.NET PostAuthenticateRequest까지 클라이언트 ID를 가장할 수 없습니다.

통합 모드에서 ASP.NET 애플리케이션의 Web.config 사용하거나 Machine.config 애플리케이션에 대해 클라이언트 가장을 사용하도록 설정된 경우 PostAuthenticateEvent까지 클라이언트를 가장하지 않습니다.

또한 클라이언트 가장을 사용하도록 설정하면 BeginRequest 및 AuthenticateRequest 이벤트에서 실행되는 모듈이 인증된 사용자의 ID 대신 프로세스 ID로 실행됩니다. 인증된 사용자가 아직 설정되지 않았기 때문에 모듈이 이러한 이벤트의 리소스에 거의 액세스하지 않으므로 문제가 되지 않습니다.

그러나 이 작업을 수행하면 프로세스 ID가 리소스에 액세스하는 데 사용됩니다.

이 변경으로 인해 발생할 수 있는 사용자 권한 상승이 가능하기 때문에 클라이언트 가장을 사용하도록 설정하면 IIS에서 예외가 발생합니다. 이는 애플리케이션을 클래식 모드로 이동하거나 BeginRequest 또는 AuthenticateRequest 이벤트에서 리소스에 액세스하는 것을 확인할 수 있는 경우 이 오류를 해제해야 했음을 나타냅니다.

charset 및 콘텐츠 형식이 빈 문자열로 설정된 경우 Content-Type 헤더가 생성되지 않습니다.

HTTP.sys 명시적으로 String.Empty로 설정된 경우 Content-Type 헤더를 더 이상 생성하지 않습니다. 클라이언트가 빈 Content-Type 헤더를 사용하는 애플리케이션은 이 변경의 영향을 받을 수 있습니다.

통합 모드에서는 다음 모듈이 실행되기 전에 각 모듈에 대해 동기 및 비동기 이벤트가 모두 발생합니다.

통합 모드에서는 서버가 다음 모듈로 이동하기 전에 각 모듈에 대해 동기 및 비동기 이벤트가 모두 발생합니다.

이는 모든 비동기 모듈 알림이 먼저 실행되고 모든 동기 알림이 실행되는 클래식 모드와 다릅니다. 순서에 의존하지 않는 한 애플리케이션에 영향을 주지 않아야 합니다(이 문서의 다른 곳에서는 "통합 모드를 사용할 때 PreSendRequestHeaders 및 PreSendRequestContent에 대해 모듈 순서가 반전됨"참조).

사용자 지정 IHttpModule에서 ClearHeader를 호출한 후 통합 모드에서 응답 헤더가 제거됩니다.

통합 모드에서는 ClearHeaders를 호출해도 기본 헤더가 자동으로 생성되지 않습니다. ClearHeaders를 호출하여 헤더를 .aspx 페이지의 기본 상태로 반환하는 애플리케이션은 대신 모든 응답 헤더를 지웁니다.

통합 모드에서 Windows 및 Forms 인증을 함께 사용하는 것은 지원되지 않습니다.

통합 모드에서 Impersonate=true를 설정하고 Forms 인증을 사용하는 것은 지원되지 않으며 오류 또는 잘못된 동작이 발생합니다.

통합 모드에서 IIS 7.0 이상에서는 항상 응답 헤더의 새 줄을 거부합니다(ASP.NET enableHeaderChecking이 false로 설정된 경우에도).

통합 모드에서 응답 헤더를 \r 또는 \n 포함하는 값으로 설정하려고 하면 예외가 throw됩니다. 클래식 모드에서 이 값은 기본적으로 인코딩되며 헤더 인코딩이 해제된 경우 전달됩니다. 보안상의 이유로 애플리케이션은 헤더 값에 인코딩되지 않은 새 줄을 작성하려고 하면 안 됩니다.

PreSendRequestHeaders 및 PreSendRequestContent 이벤트는 각 모듈에 대해 함께 발생합니다.

통합 모드에서 PreSendRequestHeaders 및 PreSendRequestContent 이벤트를 구독하는 모듈은 PreSendRequestHeaders 및 PreSendRequestContent 이벤트에 대해 함께 알림을 받습니다.

예를 들어 모듈 A가 PreSendRequestHeaders에서 먼저 실행되는 모듈 B에 대한 종속성이 있는 경우, 모듈 A가 PreSendRequestContent에 대해 실행되기 전에(예: 모듈 B가 일부 요청 상태를 수정하고 모듈 A가 이를 사용하는 경우) 애플리케이션이 중단됩니다.

통합 모드를 사용할 때 PreSendRequestHeaders 및 PreSendRequestContent에 대해 모듈 순서가 반전됩니다.

통합 모드에서 PreSendRequestHeaders 및 PreSendRequestContent를 구독하는 모듈은 섹션의 모양과 반대 순서로 알림을 받습니다. 이러한 이벤트 중 하나에서 실행되도록 구성된 여러 모듈이 있는 애플리케이션은 이벤트 순서에 대한 종속성을 공유하는 경우 이 변경의 영향을 받습니다.

이러한 문제를 해결하려면 섹션에서 모듈 순서를 변경하거나 클래식 모드에서 애플리케이션을 실행합니다.

통합 모드에서는 의 스레딩 및 큐 설정이 무시됩니다.

통합 모드에서는 IIS가 아닌 ASP.NET 스레드에 대한 요청을 처리하며 클래식 모드에서 사용되는 스레딩 또는 큐 의미 체계를 사용하지 않습니다. 이러한 차이로 인해 애플리케이션은 클래식 모드에서 실행할 때와 통합 모드에서 처리량 또는 스트레스 동작이 다를 수 있습니다.

통합 모드를 사용할 때 구성 파일 오류가 발생하면 ASP.NET 아닌 IIS가 오류 메시지를 생성합니다.

통합 모드에서 실행되는 애플리케이션의 경우 IIS는 이제 애플리케이션 구성 파일을 읽습니다. 따라서 형식이 잘못된 XML이 Web.config 파일에 있거나 파일에 구성 오류가 있는 경우 IIS는 항상 오류 메시지를 생성하며 ASP.NET 않습니다.

IIS 및 ASP.NET 다른 형식으로 오류를 작성하기 때문에 애플리케이션이 통합 모드 또는 클래식 모드에서 실행되는지 여부에 따라 오류 메시지의 형식이 다릅니다. IIS에서 생성하는 구성 파일 오류의 한 가지 유형 예는 다음과 같습니다. 내부 서버 오류 구성 오류: 구성 파일의 형식이 올바른 XML이 아닙니다.

통합 모드에서 ASP.NET 애플리케이션은 모듈의 Init 호출 중에 파이프라인 이벤트를 구독해야 합니다.

ASP.NET HTTP 파이프라인을 사용하는 ASP.NET 애플리케이션은 파이프라인 외부에서 애플리케이션 이벤트를 구독할 수 있습니다. 그러나 IIS 통합 모드 파이프라인을 사용하는 ASP.NET 애플리케이션은 이제 모듈의 Init() 메서드 중에 항상 이벤트를 구독해야 합니다. 다음 예제에서는 Init에서 이벤트 구독이 구현되는 방법을 보여 줍니다.

Public void Init(httpApplication context)
{
    Context.AuthenticateRequest += new EventHandler(this.AuthenticateUser);
}

IIS 모듈을 만드는 방법에 대한 자세한 내용은 .NET을 사용하여 모듈 개발 문서를 참조하세요.

추가 리소스

Windows Vista에서 IIS 7.0 이상으로 업그레이드하는 방법에 대한 자세한 내용은 Windows Vista의 IIS 7.0 애플리케이션 호환성, Windows Vista의 호환성 및 기능 요구 사항 문서를 참조하세요.