-
ASP.NET Core .NET 8 지원 종료: IIS에서 먼저 확인할 5가지실전 개발/ASP.NET Core · Web API 2026. 10. 12. 11:49반응형
하이롱! 오늘은 ASP.NET Core 오류에 대해서 확인해보겠습니다!!
서버를 셋팅할 때, 서버에 최신 .NET을 깔았다고, 돌아가는 중인 웹서비스까지 최신이 되는 건 아니에요.
(NET 8 지원 종료일은 2026년 11월 10일입니다.)
IIS에서 ASP.NET Core를 운영한다면 설치 파일부터 받기보다 앱 대상 버전, 배포 방식, 서버 런타임을 먼저 맞춰보세요.
핵심은 세 가지입니다. Hosting Bundle 설치는 앱 업그레이드와 다르고, 자체 포함 배포는 서버 런타임을 바꿔도 함께 바뀌지 않으며, 화면이 열린다고 전환 점검이 끝나지는 않아요.
버전 지원 종료일 전환 판단 .NET 8 LTS 2026-11-10 종료 전 전환 계획 필요 .NET 9 STS 2026-11-10 8에서 9로 옮겨도 지원 기간이 늘지 않음 .NET 10 LTS 2028-11-14 운영 앱의 전환 후보 지원 종료가 그날 프로그램을 강제로 멈춘다는 뜻은 아니에요. 이후 수정·업데이트·기술 지원이 끝난다는 뜻입니다. 또 .NET 8과 기존 VB.NET WinForms의 .NET Framework 4.x는 별도 제품입니다. 이 날짜를 모든 VB.NET 프로그램에 적용하면 안 됩니다.
1. 프로젝트 버전과 실제 배포본부터 맞추기
개발 소스의 .csproj에서 TargetFramework를 확인합니다.
<PropertyGroup> <TargetFramework>net8.0</TargetFramework> </PropertyGroup>다음은 IIS 사이트의 실제 경로입니다. 그 폴더에 배포된 앱의 *.runtimeconfig.json을 열어 tfm과 framework/frameworks를 확인하세요. 앱에 따라 includedFrameworks가 들어갈 수도 있습니다.
소스는 net10.0인데 배포본은 net8.0이라면 빌드 결과와 사이트 경로가 어긋난 상태입니다. 게시 프로필, 복사한 폴더, IIS가 바라보는 경로부터 대조합니다. 파일이 없다면 단일 파일 배포 여부와 원래 게시 설정을 확인하세요.
runtimeconfig.json은 대상 프레임워크와 런타임 설정을 확인하는 자료입니다. 현재 프로세스가 선택한 정확한 패치 버전까지 이 파일 하나로 확정할 수는 없습니다.
2. SDK와 서버 런타임을 구분하기
서버에서 아래 명령으로 설치 상태를 확인합니다. 설정을 바꾸거나 IIS를 재시작하는 명령은 아닙니다.
where.exe dotnet dotnet --info dotnet --list-runtimes프레임워크 종속 ASP.NET Core 앱이라면 Microsoft.NETCore.App과 Microsoft.AspNetCore.App의 필요한 버전이 있는지 봅니다. dotnet --version은 SDK 버전이므로 앱 실행 런타임 확인을 대신하지 못합니다.
64비트 서버라도 앱 풀과 게시 대상이 32비트일 수 있습니다. --list-runtimes는 호출한 dotnet의 아키텍처 기준 목록입니다. x86 앱이면 x86 설치도 별도로 확인해야 합니다.
또 이 목록은 서버에 설치된 버전이지, 해당 IIS 앱이 지금 쓰는 버전은 아닙니다. .NET 10이 보인다는 이유로 net8.0 앱이 자동 전환됐다고 판단하지 마세요. 기본 롤포워드 정책은 메이저 버전을 자동으로 건너뛰지 않습니다. Major/LatestMajor 설정을 임시로 넣어 실행시키는 방법도 호환성 점검을 대신하지 못합니다.
3. 프레임워크 종속인지, 자체 포함인지 확인하기
배포 방식 런타임 위치 패치 반영 방법 프레임워크 종속(FDD) 서버에 설치된 런타임 같은 계열 런타임 패치 후 앱 재시작·동작 확인 자체 포함(SCD) 앱 배포물에 포함 업데이트된 런타임으로 다시 게시·배포 게시 프로필과 .csproj, CI에서 사용한 dotnet publish 옵션을 함께 봅니다. .exe가 있다는 이유만으로 자체 포함 배포라고 판단하면 안 됩니다. 프레임워크 종속 배포에도 실행 파일이 생길 수 있습니다.
자체 포함 앱은 서버의 공유 런타임 패치를 자동으로 받지 않습니다. 빌드 환경을 업데이트하고 새 배포물을 만들어야 합니다. IIS에 올리는 자체 포함 앱도 ASP.NET Core Module이 필요하므로 Hosting Bundle 점검을 생략할 수 없습니다.
4. Hosting Bundle과 서버 운영체제를 따로 확인하기
Hosting Bundle은 IIS 연동에 필요한 ASP.NET Core Module과 런타임 등을 설치합니다. 새 번들을 설치했다고 기존 앱의 TargetFramework나 NuGet 패키지가 바뀌지는 않습니다.
확인할 순서는 운영체제 지원 조건 → 목표 버전 Hosting Bundle → 앱 풀 아키텍처 → 설치 후 재시작 계획입니다. IIS보다 번들을 먼저 설치했다면 IIS 설치 후 번들 복구가 필요합니다.
운영체제도 지원 기간과 필요한 업데이트를 따로 확인하세요. 설치가 가능하다는 사실과 지원받는 운영 환경이라는 판단은 다릅니다.
번들 설치 뒤 IIS 재시작이 필요할 수 있습니다. 운영 서버 전체 재시작 명령을 무심코 실행하지 말고 같은 서버의 다른 사이트 영향과 작업 시간을 먼저 정합니다. 기존 .NET 8 앱이 남아 있다면 런타임부터 제거하지 않습니다.
5. 개발 도구·패키지·롤백을 한 번에 점검하기
전환 작업은 별도 브랜치와 테스트 IIS 사이트에서 시작합니다. .NET 10을 대상으로 빌드할 SDK와 개발 도구부터 준비하세요. Windows 설치 문서 기준, Visual Studio에서 .NET 10을 대상으로 개발하려면 Visual Studio 2026 18.0 이상이 필요합니다. 기존 Visual Studio 2022 환경이라면 도구 전환도 일정에 포함합니다.
global.json으로 SDK를 고정했다면 설치된 .NET 10 SDK의 전체 버전으로 맞춥니다. 프로젝트 대상은 net10.0으로 변경하되, 그것만으로 완료하지 않습니다. EF Core·DB 공급자·인증·JSON·서드파티 패키지 호환성과 .NET 9·10의 호환성 변경을 함께 확인합니다. 중간 버전의 변경 문서를 읽는 것과 운영 서비스를 9로 한 번 배포하는 것은 별개입니다.
아래는 목표 SDK와 패키지 정리를 마친 뒤 개발·빌드 환경에서 실행할 최소 흐름입니다. SampleWeb은 예제 이름이며, 게시 결과는 운영 폴더와 분리합니다.
dotnet --list-sdks dotnet restore .\SampleWeb.csproj dotnet build .\SampleWeb.csproj -c Release --no-restore dotnet publish .\SampleWeb.csproj -c Release -f net10.0 ` --self-contained false -o .\publish-test이 명령은 프레임워크 종속 배포 예시입니다. 기존 앱이 자체 포함이라면 배포 방식과 RID를 먼저 확인해 별도로 게시합니다. 빌드가 성공해도 IIS 실행, 로그인, DB 조회·저장까지 통과한 건 아닙니다.
확인할 동작 기대 결과 앱 풀 재시작 후 첫 요청 정상 기동, 반복되는 시작 오류 없음 로그인·로그아웃·권한 기존 접근 제한과 인증 흐름 유지 DB 조회·저장 결과와 트랜잭션 처리 유지 중복 요청·결제 콜백이 있는 앱 중복 반영 없이 기존 규칙 유지 JSON·날짜·파일 처리 응답 형식, 시간 기준, 업로드·다운로드 유지 롤백에는 이전 게시물뿐 아니라 사이트 설정, 환경 변수 복구 방법, DB 변경 여부도 들어갑니다. 앱 전환과 DB 스키마 변경을 한꺼번에 하면 이전 DLL만 돌려놓아도 복구되지 않을 수 있습니다. DB 변경은 별도 작업으로 나누거나 되돌릴 수 있는지 먼저 확인하세요.
전환 완료 기준은 “.NET 10 설치됨”이 아니라 “새 배포본이 목표 런타임에서 실행되고, 기존 업무 흐름과 복구 절차까지 확인됨”으로 잡으면 됩니다.
함께 볼 글
공식 자료
반응형