.NET 8용 SDK 및 도구의 새로운 기능

아티클
02/17/2024

이 문서에서는 .NET SDK의 새로운 기능과 .NET 8용 도구에 대해 설명합니다.

SDK

이 섹션에는 다음 하위 항목이 포함되어 있습니다.

CLI 기반 프로젝트 평가
터미널 빌드 출력
간소화된 출력 경로
'dotnet workload clean' 명령
'dotnet publish' 및 'dotnet pack' 자산
템플릿 엔진
소스 링크
원본 빌드 SDK

CLI 기반 프로젝트 평가

MSBuild에는 MSBuild의 데이터를 스크립트나 도구에 더 쉽게 통합할 수 있는 새로운 기능이 포함되어 있습니다. CI 파이프라인 및 다른 곳에서 사용할 데이터를 가져오기 위해 dotnet publish와 같은 CLI 명령에 다음과 같은 새 플래그를 사용할 수 있습니다.

Flag	설명
`--getProperty:<PROPERTYNAME>`	지정된 이름을 가진 MSBuild 속성을 검색합니다.
`--getItem:<ITEMTYPE>`	지정된 형식의 MSBuild 항목을 검색합니다.
`--getTargetResults:<TARGETNAME>`	지정된 대상을 실행하여 출력을 검색합니다.

값은 표준 출력에 기록됩니다. 다음 예에 표시된 것처럼 여러 값 또는 복잡한 값이 JSON으로 출력됩니다.

>dotnet publish --getProperty:OutputPath
bin\Release\net8.0\

>dotnet publish -p PublishProfile=DefaultContainer --getProperty:GeneratedContainerDigest --getProperty:GeneratedContainerConfiguration
{
  "Properties": {
    "GeneratedContainerDigest": "sha256:ef880a503bbabcb84bbb6a1aa9b41b36dc1ba08352e7cd91c0993646675174c4",
    "GeneratedContainerConfiguration": "{\u0022config\u0022:{\u0022ExposedPorts\u0022:{\u00228080/tcp\u0022:{}},\u0022Labels\u0022...}}"
  }
}

>dotnet publish -p PublishProfile=DefaultContainer --getItem:ContainerImageTags
{
  "Items": {
    "ContainerImageTags": [
      {
        "Identity": "latest",
        ...
    ]
  }
}

터미널 빌드 출력

dotnet build에는 더욱 현대화된 빌드 출력을 생성하는 새로운 옵션이 있습니다. 이 터미널 로거 출력은 오류가 발생한 프로젝트와 함께 오류를 그룹화하고 다중 대상 프로젝트에 대한 다양한 대상 프레임워크를 더 잘 구별하며 빌드가 수행 중인 작업에 대한 실시간 정보를 제공합니다. 새 출력을 옵트인하려면 --tl 옵션을 사용합니다. 이 옵션에 대한 자세한 내용은 dotnet 빌드 옵션을 참조하세요.

간소화된 출력 경로

.NET 8에는 빌드 출력의 출력 경로와 폴더 구조를 간소화하는 옵션이 도입되었습니다. 이전에 .NET 앱은 다양한 빌드 아티팩트에 대한 깊고 복잡한 출력 경로 집합을 생성했습니다. 새롭고 간소화된 출력 경로 구조는 모든 빌드 출력을 공통 위치로 수집하므로 도구에서 더 쉽게 예측할 수 있습니다.

자세한 내용은 Artifacts 출력 레이아웃을 참조하세요.

`dotnet workload clean` 명령

.NET 8에는 여러 .NET SDK 또는 Visual Studio 업데이트를 통해 남겨질 수 있는 워크로드 팩을 정리하는 새로운 명령이 도입되었습니다. 워크로드를 관리할 때 문제가 발생하면 다시 시도하기 전에 workload clean을(를) 사용하여 알려진 상태로 안전하게 복원하는 것이 좋습니다. 이 명령에는 두 가지 모드가 있습니다.

dotnet workload clean

파일 기반 또는 MSI 기반 워크로드에 대해 작업 가비지 수집을 실행하여 분리된 팩을 정리합니다. 분리된 팩은 제거된 버전의 .NET SDK 또는 팩에 대한 설치 기록이 더 이상 존재하지 않는 팩에서 나온 것입니다.

Visual Studio가 설치된 경우 이 명령은 Visual Studio를 사용하여 수동으로 정리해야 하는 워크로드도 나열합니다.
dotnet workload clean --all

이 모드는 더욱 공격적이며 현재 SDK 워크로드 설치 형식(Visual Studio가 아님) 컴퓨터의 모든 팩을 정리합니다. 또한 실행 중인 .NET SDK 기능 밴드 이하에 대한 모든 워크로드 설치 기록을 제거합니다.

`dotnet publish` 및 `dotnet pack` 자산

dotnet publish 및 dotnet pack 명령은 프로덕션 자산을 생성하기 위한 것이므로 이제 기본적으로 Release 자산을 생성합니다.

다음 출력은 dotnet build와(과) dotnet publish 사이의 다양한 동작과 PublishRelease 속성을 false(으)로 설정하여 Debug 자산 게시로 되돌릴 수 있는 방법을 보여 줍니다.

/app# dotnet new console
/app# dotnet build
  app -> /app/bin/Debug/net8.0/app.dll
/app# dotnet publish
  app -> /app/bin/Release/net8.0/app.dll
  app -> /app/bin/Release/net8.0/publish/
/app# dotnet publish -p:PublishRelease=false
  app -> /app/bin/Debug/net8.0/app.dll
  app -> /app/bin/Debug/net8.0/publish/

자세한 내용은 'dotnet pack'이 릴리스 구성을 사용함 및 'dotnet publish'가 릴리스 구성을 사용함을 참조하세요.

`dotnet restore` 보안 감사

.NET 8부터 종속성 패키지가 복원될 때 알려진 취약성에 대한 보안 검사를 옵트인할 수 있습니다. 이 감사에서는 영향을 받은 패키지 이름, 취약성의 심각도 및 자세한 내용을 볼 수 있는 권고 링크가 포함된 보안 취약성 보고서를 생성합니다. dotnet add 또는 dotnet restore을(를) 실행하면 발견된 모든 취약성에 대해 경고 NU1901-NU1904가 표시됩니다. 자세한 내용은 보안 취약성 감사를 참조하세요.

템플릿 엔진

템플릿 엔진은 NuGet의 보안 관련 기능 중 일부를 통합하여 .NET 8에서 더욱 안전한 환경을 제공합니다. 다음과 같은 향상 된 기능

기본적으로 http:// 피드에서 패키지 다운로드를 방지합니다. 예를 들어, 다음 명령은 원본 URL이 HTTPS를 사용하지 않기 때문에 템플릿 패키지를 설치하지 못합니다.

dotnet new install console --add-source "http://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet-public/nuget/v3/index.json"

--force 플래그를 사용하여 이 제한 사항을 재정의할 수 있습니다.
dotnet new, dotnet new install 및 dotnet new update의 경우 템플릿 패키지에서 알려진 취약성을 확인합니다. 취약성이 발견되어 계속 진행하려면 --force 플래그를 사용해야 합니다.
dotnet new의 경우 템플릿 패키지 소유자에 대한 정보를 제공합니다. 소유권은 NuGet 포털을 통해 확인되며 신뢰할 수 있는 특성으로 간주될 수 있습니다.
dotnet search 및 dotnet uninstall의 경우 템플릿이 "신뢰할 수 있는" 패키지에서 설치되었는지 여부를 나타냅니다. 즉, 예약된 접두사를 사용합니다.

소스 링크

이제 Source Link가 .NET SDK에 포함됩니다. 목표는 Source Link를 SDK에 묶음하여 패키지에 대해 별도의 <PackageReference>을(를) 요구하는 대신 기본적으로 더 많은 패키지에 이 정보가 포함되도록 하는 것입니다. 해당 정보는 개발자의 IDE 환경을 개선시킬 것입니다.

참고 항목

이 변경의 부작용으로 커밋 정보는 빌드된 라이브러리 및 애플리케이션(.NET 7 또는 이전 버전을 대상으로 하는 라이브러리 및 애플리케이션 포함)의 InformationalVersion 값에 포함됩니다. 자세한 내용은 .NET SDK에 포함된 Source Link를 참조하세요.

원본 빌드 SDK

Linux 배포 기반(원본 빌드) SDK에는 이제 원본 빌드 런타임 패키지를 사용하여 자체 포함 애플리케이션을 빌드할 수 있는 기능이 있습니다. 배포판별 런타임 패키지는 원본 빌드 SDK와 함께 번들로 제공됩니다. 자체 포함 배포 중에 이 번들 런타임 패키지가 참조되어 사용자를 위한 기능을 사용하도록 설정합니다.

네이티브 AOT 지원

네이티브 AOT로 게시 옵션은 .NET 7에서 처음 도입되었습니다. 네이티브 AOT를 사용하여 앱을 게시하면 런타임이 필요하지 않은 완전히 독립된 버전의 앱이 만들어집니다. 모든 것이 단일 파일에 포함됩니다. .NET 8에서는 네이티브 AOT 게시에 다음과 같은 개선 사항을 제공합니다.

macOS에 x64 및 Arm64 아키텍처에 대한 지원을 추가합니다.
Linux의 네이티브 AOT 앱 크기를 최대 50% 줄입니다. 다음 표는 .NET 7과 .NET 8의 전체 .NET 런타임을 포함하는 네이티브 AOT로 게시된 "Hello World" 앱의 크기를 보여 줍니다.

운영 체제 .NET 7 .NET 8

Linux x64(-p:StripSymbols=true 포함) 3.76MB 1.84MB

Windows x64 2.85MB 1.77MB
최적화 기본 설정(크기 또는 속도)을 지정할 수 있습니다. 기본적으로 컴파일러는 애플리케이션의 크기를 고려하면서 빠른 코드를 생성하도록 선택합니다. 그러나 <OptimizationPreference> MSBuild 속성을 사용하여 둘 중 하나에 맞게 특별히 최적화할 수 있습니다. 자세한 내용은 AOT 배포 최적화를 참조하세요.

운영 체제	.NET 7	.NET 8
Linux x64(`-p:StripSymbols=true` 포함)	3.76MB	1.84MB
Windows x64	2.85MB	1.77MB

콘솔 앱 템플릿

이제 기본 콘솔 앱 템플릿에는 기본적으로 AOT에 대한 지원이 포함됩니다. AOT 컴파일용으로 구성된 프로젝트를 만들려면 dotnet new console --aot을(를) 실행하면 됩니다. --aot에 의해 추가된 프로젝트 구성에는 세 가지 효과가 있습니다.

예를 들어, dotnet publish 또는 Visual Studio를 사용하여 프로젝트를 게시할 때 네이티브 AOT를 사용하여 네이티브 자체 포함 실행 파일을 생성합니다.
트리밍, AOT 및 단일 파일에 대한 호환성 분석기를 사용하도록 설정합니다. 이러한 분석기는 프로젝트에서 잠재적으로 문제가 있는 부분을 경고합니다(있는 경우).
AOT 컴파일 없이 프로젝트를 디버그할 때 AOT와 유사한 환경을 가져올 수 있도록 AOT의 디버그 시간 에뮬레이션을 사용하도록 설정합니다. 예를 들어, AOT에 대해 주석이 추가되지 않아 호환성 분석기에서 누락된 NuGet 패키지에서 System.Reflection.Emit을(를) 사용하는 경우 에뮬레이션은 AOT를 사용하여 프로젝트를 게시하는 것이 일반적임을 의미합니다.

네이티브 AOT를 사용하여 iOS와 유사한 플랫폼을 대상 지정

.NET 8은 iOS와 유사한 플랫폼에 대한 네이티브 AOT 지원을 사용하도록 설정하는 작업을 시작합니다. 이제 다음 플랫폼에서 네이티브 AOT를 사용하여 .NET iOS 및 .NET MAUI 애플리케이션을 빌드하고 실행할 수 있습니다.

ios
iossimulator
maccatalyst
tvos
tvossimulator

예비 테스트에 따르면 Mono 대신 네이티브 AOT를 사용하는 .NET iOS 앱의 경우 디스크의 앱 크기가 약 35% 감소하는 것으로 나타났습니다. .NET MAUI iOS 앱용 디스크의 앱 크기가 최대 50% 감소합니다. 또한 작동 시간도 더 빠릅니다. .NET iOS 앱은 작동 시간이 약 28% 더 빠른 반면, .NET MAUI iOS 앱은 Mono에 비해 약 50% 더 나은 시작 성능을 제공합니다. .NET 8 지원은 실험적이며 전체 기능에 대한 첫 번째 단계일 뿐입니다. 자세한 내용은 .NET MAUI의 .NET 8 성능 개선 블로그 게시물을 참조하세요.

네이티브 AOT 지원은 앱 배포를 위한 옵트인 기능으로 제공됩니다. 여전히 Mono는 앱 개발 및 배포를 위한 기본 런타임입니다. iOS 디바이스에서 네이티브 AOT를 사용하여 .NET MAUI 애플리케이션을 빌드하고 실행하려면 dotnet workload install maui을(를) 사용하여 .NET MAUI 워크로드를 설치하고 dotnet new maui -n HelloMaui을(를) 사용하여 앱을 만듭니다. 그런 다음 프로젝트 파일에서 MSBuild 속성 PublishAot을(를) true(으)로 설정합니다.

<PropertyGroup>
  <PublishAot>true</PublishAot>
</PropertyGroup>

다음 예와 같이 필수 속성을 설정하고 dotnet publish을(를) 실행하면 네이티브 AOT를 사용하여 앱이 배포됩니다.

dotnet publish -f net8.0-ios -c Release -r ios-arm64  /t:Run

제한 사항

모든 iOS 기능이 네이티브 AOT와 호환되는 것은 아닙니다. 마찬가지로 iOS에서 일반적으로 사용되는 모든 라이브러리가 NativeAOT와 호환되는 것은 아닙니다. 다음 목록은 기존 네이티브 AOT 배포의 제한 사항 외에도 iOS와 유사한 플랫폼을 대상으로 할 때 다른 제한 사항 중 일부를 보여 줍니다.

네이티브 AOT 사용은 앱 배포(dotnet publish) 중에만 사용하도록 설정됩니다.
관리 코드 디버깅은 Mono에서만 지원됩니다.
.NET MAUI 프레임워크와의 호환성은 제한되어 있습니다.

Android 앱용 AOT 컴파일

앱 크기를 줄이기 위해 Android를 대상으로 하는 .NET 및 .NET MAUI 앱은 릴리스 모드에서 빌드될 때 프로파일링된 AOT(Ahead-of-Time) 컴파일 모드를 사용합니다. 프로파일링된 AOT 컴파일은 일반 AOT 컴파일보다 더 적은 메서드에 영향을 미칩니다. .NET 8에는 Android 앱에 대한 추가 AOT 컴파일을 옵트인하여 앱 크기를 더욱 줄일 수 있는 <AndroidStripILAfterAOT> 속성이 도입되었습니다.

<PropertyGroup>
  <AndroidStripILAfterAOT>true</AndroidStripILAfterAOT>
</PropertyGroup>

기본적으로 AndroidStripILAfterAOT을(를) true(으)로 설정하면 기본 AndroidEnableProfiledAot 설정이 재정의되어 AOT 컴파일된 거의 모든 메서드를 자를 수 있습니다. 두 속성을 모두 true로 명시적으로 설정하여 프로파일링된 AOT 및 IL 제거를 함께 사용할 수도 있습니다.

<PropertyGroup>
  <AndroidStripILAfterAOT>true</AndroidStripILAfterAOT>
  <AndroidEnableProfiledAot>true</AndroidEnableProfiledAot>
</PropertyGroup>

교차 빌드된 Windows 앱

Windows가 아닌 플랫폼에서 Windows를 대상으로 하는 앱을 빌드하면 이제 결과 실행 파일이 지정된 Win32 리소스(예: 애플리케이션 아이콘, 매니페스트, 버전 정보)로 업데이트됩니다.

이전에는 이러한 리소스를 확보하려면 Windows에서 애플리케이션을 빌드해야 했습니다. 교차빌딩 지원에서 이러한 간격을 해결하는 것은 인프라 복잡성과 리소스 사용 모두에 영향을 미치는 중요한 문제점이었기 때문에 대중적인 요청이었습니다.

Linux의 .NET

Linux에 대한 최소 지원 기준

Linux에 대한 최소 지원 기준이 .NET 8에 대해 업데이트되었습니다. .NET은 모든 아키텍처에 대해 Ubuntu 16.04를 대상으로 빌드되었습니다. 이는 .NET 8의 최소 glibc 버전을 정의하는 데 주로 중요합니다. Ubuntu 14.04 또는 Red Hat Enterprise Linux 7과 같은 이전 glibc가 포함된 distro 버전에서는 .NET 8이 시작되지 않습니다.

자세한 내용은 Red Hat Enterprise Linux 제품군 지원을 참조하세요.

Linux에서 고유의 .NET 빌드

이전 .NET 버전에서는 원본에서 .NET을 빌드할 수 있었지만 릴리스에 해당하는 dotnet/installer 리포지토리 커밋에서 "원본 tarball"을 만들어야 했습니다. .NET 8에서는 더 이상 필요하지 않으며 dotnet/dotnet 리포지토리에서 직접 Linux에 .NET을 빌드할 수 있습니다. 해당 리포지토리는 dotnet/source-build를 사용하여 .NET 런타임, 도구 및 SDK를 빌드합니다. 이는 Red Hat과 Canonical이 .NET을 빌드하는 데 사용하는 것과 동일한 빌드입니다.

dotnet-buildtools/prereqs 컨테이너 이미지에는 필요한 모든 종속성이 포함되어 있으므로 컨테이너에서 빌드하는 것은 대부분의 사람들에게 가장 쉬운 방식입니다. 자세한 내용은 빌드 지침을 참조하세요.

NuGet 서명 확인

.NET 8부터 NuGet은 기본적으로 Linux에서 서명된 패키지를 확인합니다. NuGet은 Windows에서도 서명된 패키지를 계속 확인합니다.

대부분의 사용자는 확인을 알 수 없습니다. 그러나 /etc/pki/ca-trust/extracted/pem/objsign-ca-bundle.pem에 기존 루트 인증서 번들이 있는 경우 경고 NU3042와 함께 신뢰 실패가 표시될 수 있습니다.

환경 변수 DOTNET_NUGET_SIGNATURE_VERIFICATION을 false로 설정하여 확인을 옵트아웃할 수 있습니다.

코드 분석

.NET 8에는 .NET 라이브러리 API를 정확하고 효율적으로 사용하고 있는지 확인하는 데 도움이 되는 몇 가지 새로운 코드 분석기와 수정 프로그램이 포함되어 있습니다. 다음 표에는 새로운 분석기가 요약되어 있습니다.

규칙 ID	범주	설명
CA1856	성능	매개 변수에 ConstantExpectedAttribute 특성이 올바르게 적용되지 않으면 발생합니다.
CA1857	성능	매개 변수에 ConstantExpectedAttribute 주석이 추가되었지만 제공된 인수가 상수가 아닌 경우 발생합니다.
CA1858	성능	문자열이 지정된 접두사로 시작하는지 확인하려면 String.IndexOf을(를) 호출한 다음 결과를 0과 비교하는 것보다 String.StartsWith을(를) 호출하는 것이 좋습니다.
CA1859	성능	이 규칙은 가능한 경우 특정 지역 변수, 필드, 속성, 메서드 매개 변수 및 메서드 반환 형식의 형식을 인터페이스 또는 추상 형식에서 구체적인 형식으로 업그레이드하는 것이 좋습니다. 구체적인 형식을 사용하면 생성된 코드의 품질이 높아집니다.
CA1860	성능	컬렉션 형식에 요소가 있는지 확인하려면 Enumerable.Any을(를) 호출하는 것보다 `Length`, `Count` 또는 `IsEmpty`을(를) 사용하는 것이 좋습니다.
CA1861	성능	인수로 전달된 상수 배열은 반복적으로 호출될 때 재사용되지 않습니다. 이는 매번 새 배열이 만들어짐을 의미합니다. 성능을 개선시키려면 배열을 정적 읽기 전용 필드로 추출하는 것이 좋습니다.
CA1865-CA1867	성능	char 오버로드는 단일 문자가 있는 문자열에 대해 더 나은 성능을 제공하는 오버로드입니다.
CA2021	안정성	Enumerable.Cast<TResult>(IEnumerable) 및 Enumerable.OfType<TResult>(IEnumerable)이(가) 올바르게 작동하려면 호환 가능한 형식이 필요합니다. 제네릭 형식에서는 확대 및 사용자 정의 변환이 지원되지 않습니다.
CA1510-CA1513	유지 관리	발생 도우미는 새 예외 인스턴스를 생성하는 `if` 블록보다 더 간단하고 효율적입니다. 이 네 가지 분석기는 ArgumentNullException, ArgumentException, ArgumentOutOfRangeException 및 ObjectDisposedException 예외에 대해 만들어졌습니다.

진단

C# 핫 다시 로드는 제네릭 수정을 지원함

.NET 8부터 C# 핫 다시 로드는 제네릭 형식 및 제네릭 메서드 수정을 지원합니다. Visual Studio를 사용하여 콘솔, 데스크톱, 모바일 또는 WebAssembly 애플리케이션을 디버그하는 경우 C# 코드 또는 Razor 페이지의 일반 클래스 및 제네릭 메서드에 변경 내용을 적용할 수 있습니다. 자세한 내용은 Roslyn에서 지원하는 전체 편집 목록을 참조하세요.

참고 항목

.NET 8의 새로운 기능

다음을 통해 공유

.NET 8용 SDK 및 도구의 새로운 기능

SDK

CLI 기반 프로젝트 평가

터미널 빌드 출력

간소화된 출력 경로

`dotnet workload clean` 명령

`dotnet publish` 및 `dotnet pack` 자산

`dotnet restore` 보안 감사

템플릿 엔진

소스 링크

원본 빌드 SDK

네이티브 AOT 지원

콘솔 앱 템플릿

네이티브 AOT를 사용하여 iOS와 유사한 플랫폼을 대상 지정

제한 사항

Android 앱용 AOT 컴파일

교차 빌드된 Windows 앱

Linux의 .NET

Linux에 대한 최소 지원 기준

Linux에서 고유의 .NET 빌드

NuGet 서명 확인

코드 분석

진단

C# 핫 다시 로드는 제네릭 수정을 지원함

참고 항목

피드백

추가 리소스

다음을 통해 공유

.NET 8용 SDK 및 도구의 새로운 기능

SDK

CLI 기반 프로젝트 평가

터미널 빌드 출력

간소화된 출력 경로

dotnet workload clean 명령

dotnet publish 및 dotnet pack 자산

dotnet restore 보안 감사

템플릿 엔진

소스 링크

원본 빌드 SDK

네이티브 AOT 지원

콘솔 앱 템플릿

네이티브 AOT를 사용하여 iOS와 유사한 플랫폼을 대상 지정

제한 사항

Android 앱용 AOT 컴파일

교차 빌드된 Windows 앱

Linux의 .NET

Linux에 대한 최소 지원 기준

Linux에서 고유의 .NET 빌드

NuGet 서명 확인

코드 분석

진단

C# 핫 다시 로드는 제네릭 수정을 지원함

참고 항목

피드백

추가 리소스

`dotnet workload clean` 명령

`dotnet publish` 및 `dotnet pack` 자산

`dotnet restore` 보안 감사