코드 공유 개요
이 문서에서는 플랫폼 간 프로젝트 간에 코드를 공유하는 다양한 방법인 .NET Standard, 공유 프로젝트 및 이식 가능한 클래스 라이브러리를 비교합니다. 여기에는 각 프로젝트의 이점과 단점이 포함됩니다.
플랫폼 간 애플리케이션 간에 코드를 공유하는 방법에는 다음 세 가지가 있습니다.
- .NET 표준 라이브러리 – .NET Standard 프로젝트는 여러 플랫폼에서 공유할 코드를 구현할 수 있으며 버전에 따라 많은 수의 .NET API에 액세스할 수 있습니다. .NET Standard 1.0 - 1.6은 점진적으로 더 큰 API 집합을 구현하는 반면. .NET Standard 2.0은 .NET BCL(Xamarin 앱에서 사용할 수 있는 .NET API 포함)의 최상의 범위를 제공합니다.
- 공유 프로젝트 – 공유 자산 프로젝트 유형을 사용하여 소스 코드를 구성하고 필요에 따라 컴파일러 지시문을 사용하여
#if플랫폼별 요구 사항을 관리합니다. - 이식 가능한 클래스 라이브러리 (사용되지 않음) – PCL(이식 가능한 클래스 라이브러리)은 공통 API 화면이 있는 여러 플랫폼을 대상으로 하고 인터페이스를 사용하여 플랫폼별 기능을 제공할 수 있습니다. PCL은 최신 버전의 Visual Studio에서 더 이상 사용되지 않습니다. 대신 .NET Standard를 사용합니다.
코드 공유 전략의 목표는 여러 플랫폼에서 단일 코드베이스를 활용할 수 있는 이 다이어그램에 표시된 아키텍처를 지원하는 것입니다.
이 문서에서는 애플리케이션에 적합한 프로젝트 유형을 선택하는 데 사용할 수 있는 방법을 비교합니다.
.NET 표준 라이브러리
.NET Standard 라이브러리는 Xamarin.Android 및 Xamarin.iOS와 같은 플랫폼 간 프로젝트를 포함하여 다양한 프로젝트 형식에서 참조할 수 있는 잘 정의된 기본 클래스 라이브러리 집합을 제공합니다. .NET Standard 2.0은 기존 .NET Framework 코드와의 최대 호환성을 위해 권장됩니다.
이점
- 여러 프로젝트에서 코드를 공유할 수 있습니다.
- 리팩터링 작업은 항상 영향을 받는 모든 참조를 업데이트합니다.
- .NET BCL(기본 클래스 라이브러리)의 더 큰 노출 영역은 PCL 프로필보다 사용할 수 있습니다. 특히 .NET Standard 2.0은 .NET Framework와 거의 동일한 API 표면을 가지고 있으며 새 앱 및 기존 PCL 포팅에 권장됩니다.
단점
- 와 같은
#if __IOS__컴파일러 지시문을 사용할 수 없습니다.
설명
.NET Standard는 PCL과 비슷하지만 플랫폼 지원을 위한 더 간단한 모델과 BCL에서 더 많은 수의 클래스를 사용합니다.
공유 프로젝트
공유 프로젝트에 는 해당 파일을 참조하는 모든 프로젝트에 포함된 코드 파일 및 자산이 포함됩니다. 공유 프로젝트는 자체 컴파일된 출력을 생성하지 않습니다.
이 스크린샷은 일반적인 C# 소스 코드 파일이 포함된 공유 프로젝트가 있는 세 개의 애플리케이션 프로젝트(Android, iOS 및 Windows용)가 포함된 솔루션 파일을 보여줍니다.
개념 아키텍처는 각 프로젝트에 모든 공유 소스 파일이 포함된 다음 다이어그램에 나와 있습니다.
예시
iOS, Android 및 Windows를 지원하는 플랫폼 간 애플리케이션에는 각 플랫폼에 대한 애플리케이션 프로젝트가 필요합니다. 공통 코드는 공유 프로젝트에 있습니다.
예제 솔루션에는 다음 폴더와 프로젝트가 포함됩니다(프로젝트 이름은 표현을 위해 선택되었으며 프로젝트는 이러한 명명 지침을 따를 필요가 없습니다.)
- 공유 – 모든 프로젝트에 공통된 코드를 포함하는 공유 프로젝트입니다.
- AppAndroid – Xamarin.Android 애플리케이션 프로젝트입니다.
- AppiOS – Xamarin.iOS 애플리케이션 프로젝트입니다.
- AppWindows – Windows 애플리케이션 프로젝트입니다.
이러한 방식으로 세 애플리케이션 프로젝트는 동일한 소스 코드(공유의 C# 파일)를 공유합니다. 공유 코드에 대한 모든 편집 내용은 세 프로젝트 모두에 걸쳐 공유됩니다.
이점
- 여러 프로젝트에서 코드를 공유할 수 있습니다.
- 공유 코드는 컴파일러 지시문을 사용하여 플랫폼에 따라 분기할 수 있습니다(예: 플랫폼 간 애플리케이션 빌드 문서에서 설명한 대로 사용
#if __ANDROID__). - 애플리케이션 프로젝트에는 공유 코드가 활용할 수 있는 플랫폼별 참조가 포함될 수 있습니다(예: Windows 전화 Tasky 샘플에서 사용
Community.CsharpSqlite.WP7).
단점
- '비활성' 컴파일러 지시문 내의 코드에 영향을 주는 리팩터링이 해당 지시문 내의 코드를 업데이트하지 않습니다.
- 대부분의 다른 프로젝트 형식과 달리 공유 프로젝트에는 '출력' 어셈블리가 없습니다. 컴파일하는 동안 파일은 참조 프로젝트의 일부로 처리되고 해당 어셈블리로 컴파일됩니다. 코드를 어셈블리로 공유하려는 경우 .NET Standard 또는 이식 가능한 클래스 라이브러리가 더 나은 솔루션입니다.
설명
애플리케이션 개발자가 앱에서만 공유하고 다른 개발자에게 배포하지 않는 코드를 작성하는 데 적합한 솔루션입니다.
이식 가능한 클래스 라이브러리
팁
.NET Standard 2.0 라이브러리는 이식 가능한 클래스 라이브러리보다 권장됩니다.
이식 가능한 클래스 라이브러리는 여기에서 자세히 설명합니다.
이점
- 여러 프로젝트에서 코드를 공유할 수 있습니다.
- 리팩터링 작업은 항상 영향을 받는 모든 참조를 업데이트합니다.
단점
- 최신 버전의 Visual Studio에서 사용되지 않는 .NET Standard 라이브러리를 대신 사용하는 것이 좋습니다. PCL과 .NET Standard의 차이점에 대한 이 설명을 참조하세요.
- 컴파일러 지시문을 사용할 수 없습니다.
- 선택한 프로필에 따라 결정되는 .NET Framework의 하위 집합만 사용할 수 있습니다(자세한 내용은 PCL 소개 참조).
설명
PCL 템플릿은 최신 버전의 Visual Studio에서 사용되지 않는 것으로 간주됩니다.
요약
선택하는 코드 공유 전략은 대상으로 하는 플랫폼에 의해 결정됩니다. 프로젝트에 가장 적합한 방법을 선택합니다.
.NET Standard는 공유 가능한 코드 라이브러리(특히 NuGet에 게시)를 빌드하는 데 가장 적합합니다. 공유 프로젝트는 플랫폼 간 앱에서 플랫폼별 기능을 많이 사용하려는 애플리케이션 개발자에게 적합합니다.
PCL 프로젝트는 Visual Studio에서 계속 지원되지만 새 프로젝트에는 .NET Standard를 사용하는 것이 좋습니다.