.NET6 웹 어플리케이션 Debug를 로컬 PC의 IIS에 올려서 개발 및 테스트 진행하려고 하는데요…
IIS 어플리케이션 풀과 사이트 설정 후 (http, 80포트) 사이트 접근하면 아래와 같은 에러가 발생하면서
사이트가 올라가지 않는데요…
호스팅 번들 설치하고 버전이랑 설정을 여러가지 변경해봐도 해결이 안되네요…
다른 방법으로 IIS 설정을 https와 443포트로 변경하니 사이트는 올라갔는데 Release로 올라간 거 같고 dll 파일들을 IIS worker process가 잡고 있어서 빌드 시 계속 dll 파일들을 제거할 수 없다고 나오네요… 제거 안되도 빌드되고 하는데는 문제는 없긴 한데 프로젝트 디버깅 시 프로세스 연결도 안되고 여간 불편하네요…
닷넷 프레임워크 때 문제없이 사용하던 부분이라 닷넷코어로도 문제없이 될 거 같았는데 이것저것 뭔가 설정이 더 필요한건지…
혹시 저와 비슷한 오류를 겪어보신 분, 해결해 보신 분 있으실까요?
혹시 연결 된 응용프로그램 풀의 .NET CLR 버전을 “관리 코드 없음” 으로 설정 하셨나요?
같은 닷넷 기술이니 당연히 최신 버전의 IIS에서 지원이 잘 될거라고 생각하기 쉬운데요, .NET Core 계열 런타임은 IIS의 입장에서 PHP나 일반적인 FastCGI 애플리케이션과 취급이 다르지 않습니다. IIS가 .NET Core 계열 런타임을 잘 지원하기 위해 최적화를 하거나 미리 연동하는 부분이 전혀 없기 때문에 그렇습니다.
그래서 꼭 필요한 상황이 아니라면, IIS에 호스팅하는 방식보다는 Kestrel (독립 웹 서버)을 사용하는 편이 훨씬 배포가 간단하고, 다른 OS에서 실행하는 경우도 넓게 커버할 수 있어 Kestrel 사용을 강력하게 권장합니다.
그럼에도 불구하고 실제 배포 환경이 IIS여서 IIS를 계속 고려하셔야 한다면, ANCM (ASP.NET Core Module) 설정을 IIS에 정교하게 잘 적용하셔야 하는데요,
공식 가이드의 내용을 정독해서 설정을 하나씩 따져보고 천천히 검토해보시는 것을 권해드립니다. (지금 배포된 IIS AppPool 모델 구성에 따라 설정이 복잡할 수 있습니다.)
네, 기본적인 구성들은 맞게 설정은 되어 있습니다.
공유주신 문서의 가이드에서 일부 config를 추가하니 되네요!! 감사합니다~~
기존에 IIS로 서비스를 운영해온 기조가 있어서 아직은 유지할 거 같네요
다른 분들을 위해 부연 설명을 좀 더 달면, IIS는 IIS 7에서 아키텍처를 의도적으로 .NET Framework와 결합하도록 재설계한 이후로 윈도우 서버 2022가 출시된 지금까지 거의 동일한 런타임 모델을 계속 채택하고 있습니다.
다른 웹 애플리케이션 환경은 이 부분을 명시적으로 분리하여 두 프로세스 사이를 IPC나 소켓 연결로 잇는 방식을 사용하지만, ASP.NET (.NET Framework) 계열에서는 이것을 한 프로세스 안에서 소화하도록 매우 가깝게 연결시킨 것이라고 볼 수 있고요. (사족으로 종종 웹 애플리케이션에 문제가 발생해서 502 Bad Gateway 같은 메시지가 보이는 이유는 바로 이런 아키텍처를 따르는 웹 애플리케이션에 런타임 오류가 발생했기 때문이라고 보시면 얼추 맞습니다 ㅎㅎ)
앞서 @navy5058 님께서 말씀해주신 "관리 코드 없음"의 관리 코드란 .NET Framework의 런타임 초기화 함수를 App Pool 프로세스 안에서 부를 것인지 아닐지를 정하는 부분이라고 보시면 좋을 것 같고요, 당연히 이는 .NET Core나 .NET 5 ~ 7 쪽의 초기화 코드가 아닙니다. 그러므로 저기서 말하는 관리 코드에 관련된 설정은 .NET Core와는 아무런 상관이 없으니 불필요하게 구동 속도를 느리게 만들거나 메모리 추가 사용을 유도하는 코드를 넣을 이유도 없습니다.
ANCM이 굳이 따로 존재하는 이유는 IIS와 .NET Core 런타임을 이어주기 위한 장치이고, 조금 다르게 보면 흔히 사용하는 웹 서버 + 애플리케이션 서버 조합을 IIS에서도 채택한 것으로 볼 수 있습니다. 그래서 IIS에 ANCM을 사용하지 않는다면, nginx에 Kestrel 조합을 사용하게 되는 것이죠!
IIS에 InProcess Model로 잘 배포해서 사용하고 있습니다.
메시지 내용을 보니까 Visual Studio에서 Publishing 할 때 .NET 런타임을 Self-Contained로 하신 것 같은데 Self-Contained 말고 다른 옵션으로(옵션 이름 기억이 안나네요^^) Publising하시면 배포 폴더에 적절한 web.config 가 생성됩니다. 배포할 윈도우 서버에 .NET Core Hosting Bundle을 설치하신 후 위 web.config 파일 사용하시고 응용프로그램 풀 생성 시 관리코드 없음으로 하시면 됩니다.
그리고, 이 역시 과거에 찾아봤던 기억에 의존해서 적는 것이긴 한데 Kestrel에서는 IIS만큼 다양한 보안/고급 기능이 지원되지 않기 때문에 Kestrel을 직접 웹서버로 사용하는 경우는 잘 없어서 윈도우 서버로 운영하실 경우에는 IIS In-Process Model이 가장 간편하면서도 IIS 관리자에서 설정할 수 있는 IIS 기능들을 손쉽게 사용할 수 있습니다.
윈도우 서버가 아닌 경우에도 Kestrel을 직접 웹서버로 사용하지는 않고 nginx와 함께 사용하는 경우가 많다고 봤네요.
조금 지난 이슈지만 이 이슈가 발생한 것에 대해 정확한 원인 파악이 되어서 공유 겸 댓글 남깁니다…
결론적으로 원인은 async/await 구문을 싹 빼니 더 이상 iis worker process가 bin 하위 폴더의 dll을 잡고 있지 않네요…
MS 개발자 커뮤니티에서 어떤 댓글에서 멀티 쓰레딩 구조에서 발생하는 것 같다고 해서 혹시나해서 async/await 구문을 싹 뺐더니 잘 되네요… async/await을 사용하면서 해결할 수 있는 방법을 찾는 여정을 시작해봐야겠네요…
