Microsoft MVP성태의 닷넷 이야기
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일
 
(연관된 글이 2개 있습니다.)
(시리즈 글이 15개 있습니다.)
오류 유형: 2. [COM+] CreateObject 와 HTTP 500 - Internal server error
; https://www.sysnet.pe.kr/2/0/242

오류 유형: 111. IIS - 500.19 오류 (0x8007000d)
; https://www.sysnet.pe.kr/2/0/976

오류 유형: 201. ASP.NET 웹 사이트를 IIS 7 이상의 환경에서 호스팅할 때 500 오류 발생
; https://www.sysnet.pe.kr/2/0/1563

오류 유형: 219. IIS 500 Internal Server Error - Skydrive에 공유된 경우
; https://www.sysnet.pe.kr/2/0/1612

오류 유형: 232. IIS 500 Internal Server Error - NTFS 암호화된 폴더에 웹 애플리케이션이 위치한 경우
; https://www.sysnet.pe.kr/2/0/1722

오류 유형: 340. HTTP Error 500.23 - Internal Server Error
; https://www.sysnet.pe.kr/2/0/10997

오류 유형: 360. IIS - 500.19 오류 (0x80070021)
; https://www.sysnet.pe.kr/2/0/11061

개발 환경 구성: 307. ASP.NET Core Web Application을 IIS에서 호스팅하는 방법
; https://www.sysnet.pe.kr/2/0/11120

오류 유형: 580. HTTP Error 500.0/500.33 - ANCM In-Process Handler Load Failure
; https://www.sysnet.pe.kr/2/0/12064

오류 유형: 631. .NET Core 웹 응용 프로그램 오류 - HTTP Error 500.35 - ANCM Multiple In-Process Applications in same Process
; https://www.sysnet.pe.kr/2/0/12268

오류 유형: 662. ASP.NET Core와 500.19, 500.21 오류 (0x8007000d)
; https://www.sysnet.pe.kr/2/0/12356

개발 환경 구성: 635. 비주얼 스튜디오에서 실행하던 ASP.NET Core (.NET Framework) 응용 프로그램을 명령행에서 실행하는 방법 (2)
; https://www.sysnet.pe.kr/2/0/12955

.NET Framework: 1164. HTTP Error 500.31 - ANCM Failed to Find Native Dependencies
; https://www.sysnet.pe.kr/2/0/12982

오류 유형: 884. HTTP 500.0 - 명령행에서 실행한 ASP.NET Core 응용 프로그램을 실행하는 방법
; https://www.sysnet.pe.kr/2/0/13488

오류 유형: 899. HTTP Error 500.32 - ANCM Failed to Load dll
; https://www.sysnet.pe.kr/2/0/13579




ASP.NET Core Web Application을 IIS에서 호스팅하는 방법

Visual Studio 2015에서 "ASP.NET Core Web Application(.Net Core)" 프로젝트 템플릿을 선택하고 "Web Application" 유형으로 만들면 기본적인 웹 응용 프로그램이 나옵니다.

빌드하고, IIS 웹 사이트로 연결했는데요. 웹 브라우저로 방문하니 다음과 같은 오류가 발생합니다.

HTTP Error 500.19 - Internal Server Error

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

Detailed Error Information:

Module
   IIS Web Core 

Notification
   Unknown 

Handler
   Not yet determined 

Error Code
   0x8007000d 

Requested URL
   http://localhost:8087/ 

More Information:
This error occurs when there is a problem reading the configuration file for the Web server or Web application. In some cases, the event logs may contain more information about what caused this error. 

이 오류가 났던 적이 있었군요. ^^

IIS - 500.19 오류 (0x8007000d)
; https://www.sysnet.pe.kr/2/0/976

즉, web.config 파일에 지정된 모듈이 인식되지 않았던 것인데요. 실제로 asp.net core 웹 응용 프로그램의 기본 web.config 파일을 보면,

<?xml version="1.0" encoding="utf-8"?>
<configuration>

  <system.webServer>
    <handlers>
      <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModule" resourceType="Unspecified"/>
    </handlers>
    <aspNetCore processPath="%LAUNCHER_PATH%" arguments="%LAUNCHER_ARGS%" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" forwardWindowsAuthToken="false"/>
  </system.webServer>
</configuration>

AspNetCoreModule 모듈이 지정된 것을 볼 수 있습니다. 당연히 기본 설치된 Windows Server에는 관련 모듈이 없습니다. 따라서, IIS에서 .NET Core를 호스팅 할 수 있도록 부가 작업을 해야 합니다.

Install the .NET Core Windows Server Hosting bundle
; https://learn.microsoft.com/en-us/aspnet/core/publishing/iis

위의 글에 나온 것처럼, ".NET Core Windows Server Hosting bundle"을 설치하면 되는데요.

.NET Core Windows Server Hosting bundle (DotNetCore.1.1.0-WindowsHosting.exe)
; https://download.microsoft.com/download/F/6/E/F6ECBBCC-B02F-424E-8E03-D47E9FA631B7/DotNetCore.1.1.0-WindowsHosting.exe

위의 설치 파일은 ".NET Core Runtime"과 ".NET Core Library" 및 IIS에서 요청을 처리하는 ASP.NET Core 모듈을 설치합니다. 그런데, 이런 상태에서도 다음과 같은 오류를 내면서 실행이 안됩니다.

HTTP Error 502.5 - Process Failure 

Common causes of this issue: 
* The application process failed to start 
* The application process started but then stopped 
* The application process started but failed to listen on the configured port 

Troubleshooting steps: 
* Check the system event log for error messages 
* Enable logging the application process’ stdout messages 
* Attach a debugger to the application process and inspect 

이때의 이벤트 로그를 보면 다음과 같은 항목이 보입니다.

Log Name:      Application
Source:        IIS AspNetCore Module
Date:          2016-12-25 오후 8:27:18
Event ID:      1000
Task Category: None
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      TESTPC
Description:
Application 'MACHINE/WEBROOT/APPHOST/COREWEBAPP' with physical root 'D:\temp\coreapp\' failed to start process with commandline '"%LAUNCHER_PATH%" %LAUNCHER_ARGS%', ErrorCode = '0x80070002 : 0.

보아하니, 이것은 web.config의 설정값입니다.

<aspNetCore processPath="%LAUNCHER_PATH%" arguments="%LAUNCHER_ARGS%" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" forwardWindowsAuthToken="false"/>

이 설정으로 검색해 보면,

ASP.Net Core 1.0 RC2 : What are LAUNCHER_PATH and LAUNCHER_ARGS mentioned in web.config?
; http://stackoverflow.com/questions/37463186/asp-net-core-1-0-rc2-what-are-launcher-path-and-launcher-args-mentioned-in-web

web.config에 저런 식으로 processPath="%LAUNCHER_PATH%" arguments="%LAUNCHER_ARGS%"로 설정된 것은 Visual Studio 내에서만 유효한 것입니다. 따라서, Visual Studio에서 개발할 때는 저 설정으로 빌드/실행하는 것은 가능하지만 IIS 웹 서버로 배포할 때는 그에 맞게 web.config이 변경되어야 합니다. 바로 이 작업을, Visual Studio의 "Publish" 명령으로 하는 것입니다.

이를 위해, Visual Studio에서 해당 Core 웹 프로젝트를 우 클릭한 후 "Publish..." 메뉴를 선택해 줍니다.

aspnet_core_on_iis_1.png

그럼 배포(Publish) 마법사가 뜨는데, "Custom" 항목을 선택하고 뜨는 "New Custom Profile" 창에서 배포 설정을 특정할 이름을 (원하는 대로) 지정해 줍니다. (이 배포 이름으로 저장된 설정은 나중에 재사용이 가능합니다.)

aspnet_core_on_iis_2.png

그다음 배포 경로를 지정하고, (아래의 화면에서는 기본값 그대로 "/bin/Release/PublishOutput")

aspnet_core_on_iis_3.png

마지막 배포 설정을 명시해주고 "Publish" 버튼을 눌러주면,

aspnet_core_on_iis_4.png

./bin/Release/PublishOutput 폴더에 실제 IIS 웹 서버에 배포할 바이너리 이미지들이 생성됩니다. 이렇게 배포된 PublishOutput 폴더의 web.config을 보면 다음과 같은 내용을 담고 있습니다.

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <!--
    Configure your application settings in appsettings.json. Learn more at http://go.microsoft.com/fwlink/?LinkId=786380
  -->
  <system.webServer>
    <handlers>
      <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModule" resourceType="Unspecified" />
    </handlers>
    <aspNetCore processPath="dotnet" arguments=".\WebApplication1.dll" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" forwardWindowsAuthToken="false" />
  </system.webServer>
</configuration>
<!--ProjectGuid: 028962a2-4bfe-4352-8f7d-6ee7fb543516-->

보시는 것처럼 processPath가 "%LAUNCHER_PATH%"에서 "dotnet"으로, arguments는 "%LAUNCHER_ARGS%"에서 ".\WebApplication1.dll"로 바뀌었습니다. 이렇게 바뀌어야 정상적으로 IIS에서 ASP.NET Core Web Application이 동작합니다.



그러니까, 결국 IIS에서의 ASP.NET Core 웹 응용 프로그램 실행은 다음과 같은 구조를 갖게 됩니다.

aspnet_core_on_iis_5.png

재미있는 것은, 요청을 AspNetCoreModule의 handler에서 받기 때문에 요청까지는 IIS의 관리를 받는다는 것입니다. 이로 인해 "Web Garden"을 2개 이상으로 지정해도 동일한 w3wp.exe가 2개 뜨고 그 각각의 하위에 다시 dotnet.exe가 자식 프로세스로 연결됩니다. 물론, 포트 충돌 문제는 없습니다. 이때의 dotnet.exe에 있는 ASP.NET Core 웹 응용 프로그램은 포트를 점유하지 않고 요청만 처리해 주는 별도 프로세스로 동작하는 것뿐입니다.




[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]

[연관 글]






[최초 등록일: ]
[최종 수정일: 8/10/2023]

Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.
by SeongTae Jeong, mailto:techsharer at outlook.com

비밀번호

댓글 작성자
 




... 61  62  63  64  65  66  67  68  69  70  71  72  73  74  [75]  ...
NoWriterDateCnt.TitleFile(s)
12153정성태2/23/202024384.NET Framework: 898. Trampoline을 이용한 후킹의 한계파일 다운로드1
12152정성태2/23/202021411.NET Framework: 897. 실행 시에 메서드 가로채기 - CLR Injection: Runtime Method Replacer 개선 - 세 번째 이야기(Trampoline 후킹)파일 다운로드1
12151정성태2/22/202024053.NET Framework: 896. C# - Win32 API를 Trampoline 기법을 이용해 C# 메서드로 가로채는 방법 - 두 번째 이야기 (원본 함수 호출)파일 다운로드1
12150정성태2/21/202024119.NET Framework: 895. C# - Win32 API를 Trampoline 기법을 이용해 C# 메서드로 가로채는 방법 [1]파일 다운로드1
12149정성태2/20/202021038.NET Framework: 894. eBEST C# XingAPI 래퍼 - 연속 조회 처리 방법 [1]
12148정성태2/19/202025719디버깅 기술: 163. x64 환경에서 구현하는 다양한 Trampoline 기법 [1]
12147정성태2/19/202021022디버깅 기술: 162. x86/x64의 기계어 코드 최대 길이
12146정성태2/18/202022218.NET Framework: 893. eBEST C# XingAPI 래퍼 - 로그인 처리파일 다운로드1
12145정성태2/18/202023836.NET Framework: 892. eBEST C# XingAPI 래퍼 - Sqlite 지원 추가파일 다운로드1
12144정성태2/13/202024012.NET Framework: 891. 실행 시에 메서드 가로채기 - CLR Injection: Runtime Method Replacer 개선 - 두 번째 이야기파일 다운로드1
12143정성태2/13/202018425.NET Framework: 890. 상황별 GetFunctionPointer 반환값 정리 - x64파일 다운로드1
12142정성태2/12/202022341.NET Framework: 889. C# 코드로 접근하는 MethodDesc, MethodTable파일 다운로드1
12141정성태2/10/202021340.NET Framework: 888. C# - ASP.NET Core 웹 응용 프로그램의 출력 가로채기 [2]파일 다운로드1
12140정성태2/10/202022702.NET Framework: 887. C# - ASP.NET 웹 응용 프로그램의 출력 가로채기파일 다운로드1
12139정성태2/9/202022387.NET Framework: 886. C# - Console 응용 프로그램에서 UI 스레드 구현 방법
12138정성태2/9/202028600.NET Framework: 885. C# - 닷넷 응용 프로그램에서 SQLite 사용 [6]파일 다운로드1
12137정성태2/9/202020243오류 유형: 592. [AhnLab] 경고 - 디버거 실행을 탐지했습니다.
12136정성태2/6/202021892Windows: 168. Windows + S(또는 Q)로 뜨는 작업 표시줄의 검색 바가 동작하지 않는 경우
12135정성태2/6/202027688개발 환경 구성: 468. Nuget 패키지의 로컬 보관 폴더를 옮기는 방법 [2]
12134정성태2/5/202024965.NET Framework: 884. eBEST XingAPI의 C# 래퍼 버전 - XingAPINet Nuget 패키지 [5]파일 다운로드1
12133정성태2/5/202022707디버깅 기술: 161. Windbg 환경에서 확인해 본 .NET 메서드 JIT 컴파일 전과 후 - 두 번째 이야기
12132정성태1/28/202025728.NET Framework: 883. C#으로 구현하는 Win32 API 후킹(예: Sleep 호출 가로채기) [1]파일 다운로드1
12131정성태1/27/202024463개발 환경 구성: 467. LocaleEmulator를 이용해 유니코드를 지원하지 않는(한글이 깨지는) 프로그램을 실행하는 방법 [1]
12130정성태1/26/202022031VS.NET IDE: 142. Visual Studio에서 windbg의 "Open Executable..."처럼 EXE를 직접 열어 디버깅을 시작하는 방법
12129정성태1/26/202029037.NET Framework: 882. C# - 키움 Open API+ 사용 시 Registry 등록 없이 KHOpenAPI.ocx 사용하는 방법 [3]
12128정성태1/26/202023168오류 유형: 591. The code execution cannot proceed because mfc100.dll was not found. Reinstalling the program may fix this problem.
... 61  62  63  64  65  66  67  68  69  70  71  72  73  74  [75]  ...