.NET 애플리케이션 게시 개요

이 문서에서는 .NET 애플리케이션을 게시하는 다양한 방법을 설명합니다. 게시 모드, 실행 파일 및 플랫폼 간 이진 파일을 생성하는 방법, 배포 및 런타임 환경에 대한 각 접근 방식의 영향을 다룹니다. .NET CLI 또는 Visual Studio를 사용하여 .NET 애플리케이션을 게시할 수 있습니다.

게시란?

.NET 앱을 게시한다는 것은 소스 코드를 컴파일하여 배포를 위해 종속성 및 관련 파일과 함께 실행 파일 또는 이진 파일을 만드는 것을 의미합니다. 게시한 후에는 서버, 배포 플랫폼, 컨테이너 또는 클라우드 환경에 앱을 배포합니다. 게시 프로세스는 개발 환경 외부에서 배포 및 사용을 위한 앱을 준비합니다.

게시 모드

앱을 게시하는 두 가지 기본 방법이 있습니다. 이 결정에 영향을 주는 몇 가지 요인으로는 배포 환경에 적절한 .NET 런타임이 설치되어 있는지 여부와 런타임을 앱과 묶어야 하는 특정 컴파일 기능이 필요한지 여부가 포함됩니다. 두 게시 모드는 다음과 같습니다.

• 자체 포함 게시
  이 모드는 앱을 시작하는 데 사용되는 플랫폼별 실행 파일, 앱 코드를 포함하는 컴파일된 이진 파일, 앱 종속성 및 앱을 실행하는 데 필요한 .NET 런타임을 포함하는 게시 폴더를 생성합니다. 앱을 실행하는 환경은 .NET 런타임을 미리 설치할 필요가 없습니다.

• 프레임워크 종속 게시
  이 모드는 앱을 시작하는 데 사용되는 플랫폼별 실행 파일, 앱 코드가 포함된 컴파일된 이진 파일 및 모든 앱 종속성을 포함하는 게시 폴더를 생성합니다. 앱을 실행하는 환경에는 앱에서 사용할 수 있는 .NET 런타임 버전이 설치되어 있어야 합니다. 선택적 플랫폼별 실행 파일을 생성할 수 있습니다.

게시 기본 사항

프로젝트 파일의 설정은 <TargetFramework> 앱을 게시할 때 기본 대상 프레임워크를 지정합니다. 대상 프레임워크를 유효한 TFM(대상 프레임워크 모니커)으로 변경할 수 있습니다. 예를 들어 프로젝트에서 사용하는 <TargetFramework>net9.0</TargetFramework>경우 .NET 9를 대상으로 하는 이진 파일이 만들어집니다.

둘 이상의 프레임워크를 대상으로 지정하려는 경우 설정을 세미콜론으로 구분하여 여러 TFM 값으로 설정할 <TargetFrameworks> 수 있습니다. 앱을 빌드할 때 앱은 프로젝트에서 정의한 각 대상 프레임워크에 대해 빌드됩니다. 그러나 앱을 게시할 때 대상 프레임워크를 지정해야 합니다.

dotnet publish -c Release -f net9.0

이식 가능한 이진 파일

.NET 앱을 게시할 때 특정 플랫폼을 대상으로 지정하거나 이식 가능한 이진 파일을 만들 수 있습니다. 기본적으로 이식 가능한 이진 파일을 만드는 경우에도 .NET은 이 동작을 명시적으로 사용하지 않도록 설정하지 않는 한 이식 가능한 DLL과 함께 플랫폼별 실행 파일을 게시합니다.

플랫폼별 실행 파일은 기본값인 속성 때문에 UseAppHost 만들어집니다 true. 플랫폼별 실행 파일 없이 이식 가능한 DLL만 게시하려면 명령줄(-p:UseAppHost=false) 또는 프로젝트 속성으로 설정합니다 UseAppHostfalse.

특정 플랫폼을 대상으로 하는 이점은 앱에 필요할 수 있는 네이티브 종속성을 처리하여 대상 플랫폼의 특정 요구 사항과의 호환성을 보장할 수 있다는 것입니다.

네이티브 종속성

앱에 네이티브 종속성이 있는 경우 이식 가능한 이진 파일로 게시된 경우 다른 운영 체제에서 실행되지 않을 수 있습니다. 예를 들어 Windows API에 의존하는 앱은 기본적으로 macOS 또는 Linux에서 실행되지 않습니다. 플랫폼별 코드를 제공하고 각 플랫폼에 대한 실행 파일을 컴파일해야 합니다.

또한 참조한 라이브러리가 플랫폼별 종속성을 제공하는 경우 앱이 모든 플랫폼에서 실행되지 않을 수도 있습니다. 그러나 특정 플랫폼을 게시하고 대상으로 지정하면 NuGet 패키지의 플랫폼별 종속성이 게시 폴더에 복사됩니다.

앱이 네이티브 종속성을 사용하여 게시되도록 하려면 특정 플랫폼에 대해 게시합니다.

dotnet publish -c Release -r <RID>

런타임 식별자 목록은 RID(런타임 식별자) 카탈로그를 참조하세요.

프레임워크 종속 배포

프레임워크 종속 배포는 CLI 또는 Visual Studio에서 게시할 때 기본 모드입니다. 이 모드에서는 플랫폼별 실행 파일 호스트를 만들어 플랫폼 간 앱을 호스트합니다. 호스트 실행 파일 이름은 플랫폼마다 다르며 이름이 다음과 유사합니다 <PROJECT-FILE>.exe. 이 실행 파일을 호출 dotnet <PROJECT-FILE>.dll하는 대신 직접 실행할 수 있습니다. 이는 여전히 앱을 실행하는 데 허용되는 방법입니다.

앱은 특정 버전의 .NET을 대상으로 하도록 구성됩니다. 대상 .NET 런타임은 앱이 실행되는 환경에 있어야 합니다. 예를 들어 앱이 .NET 9를 대상으로 하는 경우 앱이 실행되는 모든 환경에 .NET 9 런타임이 설치되어 있어야 합니다.

프레임워크 종속 배포를 게시하면 앱을 실행하는 환경에서 사용할 수 있는 최신 .NET 보안 패치로 자동으로 롤아웃되는 앱이 만들어집니다. 컴파일 시간에 버전 바인딩에 대한 자세한 내용은 사용할 .NET 버전 선택을 참조하세요.

장점

• 소규모 배포: 앱 및 해당 종속성만 배포됩니다. 앱이 실행되는 환경에는 이미 .NET 런타임이 설치되어 있어야 합니다.
• 플랫폼 간: 앱 및 모든 . NET 기반 라이브러리는 다른 운영 체제에서 실행됩니다.
• 패치된 최신 런타임 사용: 앱은 환경에 설치된 최신 런타임을 사용합니다.

단점

• 런타임을 미리 설치해야 합니다. 대상 .NET 버전이 환경에 이미 설치된 경우에만 앱이 실행될 수 있습니다.
• .NET은 변경될 수 있습니다. 앱이 실행되는 환경은 앱 동작을 변경할 수 있는 최신 .NET 런타임을 사용할 수 있습니다.

게시하기

dotnet publish -c Release [-r <RID>]

dotnet publish -c Release [-r <RID>] --self-contained false

.NET 설치 검색 동작 구성

.NET 9 이상 버전에서는 및 속성을 통해 AppHostDotNetSearchAppHostRelativeDotNet 게시된 실행 파일의 .NET 설치 검색 경로를 구성할 수 있습니다.

AppHostDotNetSearch 를 사용하면 실행 파일이 .NET 설치를 찾을 위치를 하나 이상 지정할 수 있습니다.

• AppLocal: 앱 실행 파일의 폴더
• AppRelative: 앱 실행 파일에 상대적인 경로
• EnvironmentVariable: 환경 변수의 DOTNET_ROOT[_<arch>] 값
• Global: 등록된기본 전역 설치 위치

AppHostRelativeDotNet 는 포함할 때 AppHostDotNetSearch 검색될 실행 파일을 기준으로 경로를 지정합니다 AppRelative.

자세한 내용은 apphost에서 위치AppHostRelativeDotNet 옵션을 참조AppHostDotNetSearch하고 설치합니다.

플랫폼 간 DLL 배포

또는 플랫폼별 실행 파일 없이 앱을 플랫폼 간 DLL로 게시할 수 있습니다. 이 모드에서는 <PROJECT-NAME>.dll 게시 출력 폴더에 파일이 만들어집니다. 앱을 실행하려면 출력 폴더로 이동하고 명령을 사용합니다 dotnet <PROJECT-NAME>.dll .

플랫폼 간 DLL로 게시하려면 다음을 수행합니다.

dotnet publish -c Release -p:UseAppHost=false

자체 포함 배포

SCD(자체 포함 배포)를 게시하는 경우 게시 프로세스는 플랫폼별 실행 파일을 만듭니다. SCD 게시에는 앱을 실행하는 데 필요한 모든 .NET 파일이 포함되지만 .NET의 네이티브 종속성은 포함되지 않습니다. 이러한 종속성은 앱이 실행되기 전에 환경에 있어야 합니다.

SCD를 게시하면 사용 가능한 최신 .NET 보안 패치로 롤백되지 않는 앱이 만들어집니다. 컴파일 시간에 버전 바인딩에 대한 자세한 내용은 사용할 .NET 버전 선택을 참조하세요.

장점

• .NET 버전 제어: 앱과 함께 배포되는 .NET 버전을 제어합니다.
• 플랫폼별 대상 지정: 각 플랫폼에 대해 앱을 게시해야 하므로 앱이 실행되는 위치는 분명합니다.

단점

• 대규모 배포: 앱에 .NET 런타임 및 모든 종속성이 포함되어 있으므로 필요한 다운로드 크기와 하드 드라이브 공간이 프레임워크 종속 배포보다 큽니다.
• .NET 버전을 업데이트하기가 더 어렵습니다. .NET 런타임은 새 버전의 앱을 릴리스해야만 업그레이드할 수 있습니다.

게시하기

dotnet publish -c Release -r <RID> --self-contained true

단일 파일 배포

앱을 단일 파일 배포로 게시하면 모든 애플리케이션 종속 파일이 단일 이진 파일로 번들로 제공됩니다. 이 배포 모델은 프레임워크 종속 애플리케이션과 자체 포함 애플리케이션 모두에서 사용할 수 있으므로 애플리케이션을 단일 파일로 배포하고 배포할 수 있는 매력적인 옵션을 제공합니다.

단일 파일 앱은 항상 OS 및 아키텍처에 따라 다릅니다. Linux x64, Linux Arm64, Windows x64 등과 같은 각 구성에 대해 게시해야 합니다.

장점

• 간소화된 배포: 애플리케이션을 단일 실행 파일로 배포 및 배포합니다.
• 파일 혼란 감소: 모든 종속성이 번들로 제공되어 여러 파일을 관리할 필요가 없습니다.
• 간편한 배포: 단일 파일을 복사하여 애플리케이션을 배포합니다.

단점

• 더 큰 파일 크기: 단일 파일에는 모든 종속성이 포함되므로 개별 파일보다 큽 수 있습니다.
• 느린 시작: 런타임에 파일을 추출해야 하므로 시작 성능에 영향을 미칠 수 있습니다.
• 플랫폼별: 각 대상 플랫폼에 대해 별도의 파일을 게시해야 합니다.

추가 최적화를 위해 트리 밍 및 ReadyToRun 컴파일 과 같은 다른 최적화와 단일 파일 배포를 결합할 수 있습니다.

단일 파일 배포에 대한 자세한 내용은 단일 파일 배포를 참조하세요.

게시하기

dotnet publish -c Release -r <RID> -p:PublishSingleFile=true

네이티브 AOT 배포

네이티브 AOT 배포는 네이티브 코드로 직접 앱을 컴파일하므로 런타임이 필요하지 않습니다. 컴파일된 네이티브 코드에는 애플리케이션을 실행하는 데 필요한 모든 항목이 포함되어야 하므로 이 게시 옵션은 자체 포함 배포 모드를 사용합니다. 이로 인해 시작 시간이 빨라지고 메모리 사용량이 감소하지만 지원되는 기능에는 몇 가지 제한 사항이 있습니다.

장점

• 빠른 시작: 런타임에 JIT 컴파일이 필요하지 않으며 애플리케이션 시작 속도가 빨라집니다.
• 메모리 사용량 감소: 기존 .NET 애플리케이션에 비해 메모리 사용량이 낮습니다.
• 런타임 종속성 없음: .NET 런타임 설치 없이 애플리케이션이 실행됩니다.
• 더 작은 배포 크기: 종종 전체 런타임 이 있는 자체 포함 배포 보다 작습니다.

단점

• 제한된 프레임워크 지원: 모든 .NET 기능 및 라이브러리가 네이티브 AOT와 호환되는 것은 아닙니다.
• 빌드 시간 더 길기: 네이티브 코드로 컴파일하는 데 일반 빌드보다 오래 걸립니다.
• 플랫폼별: 각 대상 플랫폼 및 아키텍처에 대해 별도로 컴파일해야 합니다.
• 디버깅 제한 사항: 일반 .NET 애플리케이션에 비해 더 복잡한 디버깅 환경입니다.

네이티브 AOT 배포에 대한 자세한 내용은 네이티브 AOT 배포를 참조하세요.

게시하기

dotnet publish -c Release -r <RID> -p:PublishAot=true

ReadyToRun 배포

ReadyToRun 컴파일을 사용하여 앱을 게시하면 애플리케이션 어셈블리가 R2R(ReadyToRun) 형식으로 컴파일됩니다. R2R은 애플리케이션이 로드될 때 JIT(Just-In-Time) 컴파일러가 수행해야 하는 작업의 양을 줄여 시작 성능을 향상시키는 AOT(Ahead-Of-Time) 컴파일의 한 형태입니다. 이 게시 옵션은 프레임워크 종속 배포 모드와 자체 포함 배포 모드 모두에서 사용할 수 있습니다.

ReadyToRun 이진 파일에는 IL(중간 언어) 코드와 동일한 코드의 네이티브 버전이 모두 포함되어 있습니다. R2R 이진 파일은 일반 어셈블리보다 크지만 더 나은 시작 성능을 제공합니다.

장점

• 시작 시간 개선: 앱은 시작하는 동안 JIT 컴파일러를 실행하는 데 더 적은 시간을 소비합니다.
• 첫 번째 사용 성능 향상: 코드 경로의 처음 실행에 대한 대기 시간 감소.
• 기존 코드와 호환: 대부분의 .NET 라이브러리 및 프레임워크를 수정하지 않고 작동합니다.
• 유연한 배포: 프레임워크 종속 배포 및 자체 포함 배포 모드와 결합할 수 있습니다.

단점

• 더 큰 크기: 앱은 IL 및 네이티브 코드를 모두 포함하기 때문에 디스크에서 더 큽 수 있습니다.
• 빌드 시간이 길다: 컴파일은 표준 게시보다 더 많은 시간이 걸립니다.
• 플랫폼별 최적화: 최상의 성능 향상을 위해서는 특정 플랫폼을 대상으로 지정해야 합니다.

게시하기

dotnet publish -c Release -r <RID> -p:PublishReadyToRun=true

ReadyToRun 배포에 대한 자세한 내용은 ReadyToRun 컴파일을 참조하세요.

컨테이너 배포

앱을 컨테이너로 게시할 때 .NET SDK는 별도의 Dockerfile을 요구하지 않고 애플리케이션 및 해당 종속성을 컨테이너 이미지에 패키지합니다. 이 배포 모드는 Docker 또는 Podman과 같은 모든 컨테이너 런타임에서 실행할 수 있는 전체 컨테이너 이미지를 만듭니다. 컨테이너 배포는 최적화된 기본 이미지를 제공하면서 Dockerfile을 작성하고 유지 관리할 필요가 없도록 하여 컨테이너화 프로세스를 간소화합니다.

.NET SDK 8.0.200부터 컨테이너 지원은 기본적으로 포함되며 추가 NuGet 패키지가 필요하지 않습니다. 콘솔 애플리케이션의 경우 속성을 .로 설정하여 컨테이너 지원을 명시적으로 사용하도록 설정 EnableSdkContainerSupport 해야 할 true수 있습니다.

장점

• 간소화된 컨테이너화: 기본 시나리오를 위해 Dockerfile을 작성하거나 유지 관리할 필요가 없습니다.
• 최적화된 기본 이미지: 최신 보안 업데이트와 함께 Microsoft에서 제공하는 최적화된 기본 이미지를 사용합니다.
• 일관된 환경: 개발, 테스트 및 프로덕션 전반에서 일관된 런타임 환경을 보장합니다.
• 간편한 배포: 컨테이너 이미지를 쉽게 공유하고 다양한 환경에 배포할 수 있습니다.
• 플랫폼 격리: 애플리케이션은 격리된 컨테이너에서 실행되어 애플리케이션 간의 충돌을 줄입니다.

단점

• 컨테이너 런타임 종속성: 대상 환경에 컨테이너 런타임이 설치되어 있어야 합니다.
• 이미지 크기: 컨테이너 이미지는 일반적으로 다른 배포 방법보다 큽합니다.
• 학습 곡선: 컨테이너 개념 및 도구를 이해해야 합니다.
• 제한된 사용자 지정: 복잡한 시나리오의 경우 사용자 지정 Dockerfile에 비해 유연성이 떨어집니다.

게시하기

dotnet publish -c Release [-r <RID>] /t:PublishContainer

dotnet publish -c Release [-r <RID>] -p:PublishProfile=DefaultContainer

컨테이너 배포에 대한 자세한 내용은 .NET SDK 컨테이너 만들기 개요를 참조하세요.

참조

• .NET RID(런타임 식별자) 카탈로그
• 사용할 .NET 버전 선택