.NET Core와 .NET Standard Class Library 프로젝트 유형의 차이점은 무엇입니까?

Visual Studio에는 만들 수있는 클래스 라이브러리 유형이 3 가지 이상 있습니다.

• 클래스 라이브러리 (.NET Framework)
• 클래스 라이브러리 (.NET 표준)
• 클래스 라이브러리 (.NET Core)

첫 번째는 우리가 수년간 사용해온 것이지만, 내가 겪었던 혼란의 주요 지점은 .NET 표준 및 .NET Core 클래스 라이브러리 유형을 사용할 때입니다. 나는이 최근에 시도 할 때 물린 봤는데 멀티 타겟 다른 프레임 워크 버전 및 단위 테스트 프로젝트를 생성 .

그렇다면 클래스 라이브러리 (.NET 표준) 와 클래스 라이브러리 (.NET 코어) 의 차이점은 무엇이며 왜 둘 다 존재하며 언제 서로를 사용해야합니까?

우리는 언제 다른 것을 사용해야합니까?

결정은 호환성과 API 액세스 간의 절충입니다.

라이브러리와 호환되는 앱 수를 늘리고 싶을 때 .NET 표준 라이브러리를 사용하고 라이브러리가 액세스 할 수있는 .NET API 노출 영역을 줄여도됩니다.

라이브러리가 액세스 할 수있는 .NET API 노출 영역을 늘리고 싶을 때 .NET Core 라이브러리를 사용하고 .NET Core 앱만 라이브러리와 호환되도록 허용해도됩니다.

예를 들어 .NET Standard 1.3을 대상으로하는 라이브러리는 .NET Framework 4.6, .NET Core 1.0, Universal Windows Platform 10.0 및 .NET Standard 1.3을 지원하는 기타 플랫폼을 대상 으로하는 앱 과 호환됩니다 . 그러나 라이브러리는 .NET API의 일부에 액세스 할 수 없습니다. 예를 들어 Microsoft.NETCore.CoreCLR패키지는 .NET Core와 호환되지만 .NET Standard와는 호환되지 않습니다.

클래스 라이브러리 (.NET 표준)와 클래스 라이브러리 (.NET 코어)의 차이점은 무엇입니까?

패키지 기반 프레임 워크 섹션 에서는 차이점을 설명합니다.

호환성 : .NET Standard를 대상으로하는 라이브러리는 .NET Core, .NET Framework, Mono / Xamarin과 같은 .NET Standard 호환 런타임에서 실행됩니다. 반면 .NET Core를 대상으로하는 라이브러리는 .NET Core 런타임에서만 실행할 수 있습니다.

API Surface Area : .NET 표준 라이브러리에는 모든 것이 포함되어 NETStandard.Library있고 .NET Core 라이브러리에는 모든 것이 포함되어 Microsoft.NETCore.App있습니다. 후자는 약 20 개의 추가 라이브러리를 포함하며,이 중 일부는 .NET 표준 라이브러리 (예 :)에 수동으로 추가 할 수 System.Threading.Thread있고 일부는 .NET 표준 (예 :Microsoft.NETCore.CoreCLR .

또한 .NET Core 라이브러리는 런타임을 지정하고 응용 프로그램 모델과 함께 제공됩니다. 예를 들어 단위 테스트 클래스 라이브러리를 실행 가능하게 만드는 것이 중요합니다.

왜 둘 다 존재합니까?

라이브러리를 잠시 무시하면 .NET 표준이 존재하는 이유는 이식성 때문입니다. .NET 플랫폼이 구현하기로 동의 한 API 세트를 정의합니다. .NET 표준을 구현하는 모든 플랫폼은 해당 .NET 표준을 대상으로하는 라이브러리와 호환됩니다. 이러한 호환 가능한 플랫폼 중 하나는 .NET Core입니다.

라이브러리로 돌아와서 .NET 표준 라이브러리 템플릿은 API 런타임 영역을 희생하면서 여러 런타임에서 실행되도록 존재합니다. 반대로 .NET Core 라이브러리 템플릿은 더 많은 API 노출 영역에 액세스하고 (호환성을 희생하면서) 실행 파일을 빌드 할 플랫폼을 지정하기 위해 존재합니다.

다음은 어떤 .NET 표준이 어떤 .NET 구현을 지원하고 얼마나 많은 API 표면 영역을 지원하는지 보여주는 대화 형 매트릭스 입니다.

.NET 코어 클래스 라이브러리 에 내장되어 .NET 표준 . .NET Framework로 이식 가능한 라이브러리를 구현하려면 . .NET Core 및 Xamarin , .NET 표준 라이브러리 선택

.NET Core는 궁극적으로 .NET Standard 2를 구현할 것입니다 ( Xamarin 및 .NET Framework와 동일 ).

.NET 코어 , 자 마린 과 .NET 프레임 워크는 따라서으로 식별 할 수 있습니다 맛 의 .NET 표준

코드 공유 및 재사용을 위해 애플리케이션을 미래에 대비하려면 .NET 표준 라이브러리를 구현하는 것이 좋습니다.

또한 휴대용 클래스 라이브러리 대신 .NET 표준 을 사용하는 것이 좋습니다. .

MSDN을 신뢰할 수있는 출처로 인용 하기 위해 .NET Standard 는 모든 것을 지배하는 하나의 라이브러리가 되어야 합니다. 그림이 천 단어의 가치가 있기 때문에 다음은 매우 명확합니다.

1. 현재 응용 프로그램 시나리오 (조각화)

우리 대부분과 마찬가지로, 아마도 아래 상황에 처해있을 것입니다.

2. .NET 표준 라이브러리가 지원하는 것 (프레임 워크 호환성)

.NET 표준 라이브러리를 구현하면 다음과 같은 다양한 특성을 통해 코드를 공유 할 수 있습니다.

참을성이없는 사람 :

1. .NET Standard 는 데스크톱 환경, 모바일 앱 및 게임, 클라우드 서비스 등 필요한 환경에서 기대하고 좋아하는 모든 API를 제공하여 모든 플랫폼에서 .NET 개발자의 코드 공유 문제를 해결합니다.
2. .NET 표준 A는 API를 세트의 모든 .NET 플랫폼을 구현해야한다 . 이것은 닷넷 플랫폼 통합 및 방지 미래의 조각을 .
3. .NET Standard 2.0 은 .NET Framework 에서 구현됩니다 . NET 코어 및 자 마린 . 대한 .NET 코어 이 요청 된 기존의 API의 많은 추가됩니다.
4. .NET Standard 2.0 에는 .NET Framework에 대한 호환성 shim이 포함되어 있습니다. 바이너리에 .NET Standard 라이브러리에서 참조 할 수있는 라이브러리 세트가 크게 증가합니다.
5. .NET 표준 은 다중 플랫폼 .NET 라이브러리를 구축하기위한 툴링 스토리로 PCL (Portable Class Libraries)을 대체 합니다.

실행할 .NET 플랫폼에 따라 대상으로 지정할 수있는 최고 .NET 표준 버전을 이해하는 데 도움이되는 표를 보려면 여기로 이동하십시오. .

출처 : MSDN : .NET 표준 소개

따라서 짧은 대답은 다음과 같습니다.

IAnimal == .NetStandard (General)
ICat == .NetCore (Less General)
IDog == .NetFramework (Specific / oldest and has the most features)

.NET 및 .NET Core 는 .NET 런타임의 서로 다른 두 가지 구현입니다. 코어와 프레임 워크 (특히 프레임 워크)는 설치 위치와 프로파일에 따라 Microsoft가 .NET 용으로 생성 한 많은 API와 어셈블리 중에서 더 크거나 작은 (또는 단순한 다른) 선택을 포함하는 다른 프로파일을 가지고 있습니다.

예를 들어 유니버설 Windows 앱에서 "일반"Windows 프로필과 다른 API를 사용할 수 있습니다. Windows에서도 "클라이언트"프로파일과 "전체"프로파일이있을 수 있습니다. 또한 Mono 와 같은 다른 구현이 있습니다. 자체 라이브러리 세트 )도 있습니다.

.NET Standard 는 API 라이브러리 및 어셈블리 세트를 사용할 수 있어야하는 사양입니다. .NET Standard 1.0 용으로 작성된 앱은 .NET Standard 1.0 라이브러리 컬렉션 지원을 알리는 모든 버전의 Framework, Core, Mono 등으로 컴파일하고 실행할 수 있어야합니다. .NET Standard 1.1, 1.5, 1.6, 2.0 등에서도 마찬가지입니다. 런타임이 프로그램이 대상으로하는 Standard 버전을 지원하는 한, 프로그램이 거기서 실행되어야합니다.

Standard 버전을 대상으로하는 프로젝트는 해당 표준 개정판에 포함되지 않은 기능을 사용할 수 없습니다. 그렇다고 다른 어셈블리 나 다른 공급 업체에서 게시 한 API (예 : NuGet의 항목)에 의존 할 수는 없습니다. 그러나 귀하가 취하는 모든 종속성에는 귀하의 .NET 표준 버전에 대한 지원도 포함되어야합니다. .NET Standard는 빠르게 발전하고 있지만 여전히 새로운 기능이며 일부 작은 런타임 프로필을 충분히 고려하여 이러한 제한으로 인해 어려움을 겪을 수 있습니다. (1 년 반 후 참고 : 현재 변경되고 있으며 최근의 .NET 표준 버전이 훨씬 더 훌륭하고 모든 기능을 갖추고 있습니다.)

반면에 표준을 대상으로하는 앱 은 이론적으로는 매력적인 약속의 넓은 분포를 찾고 클래스 라이브러리 프로젝트의 경우, 등 코어, 프레임 워크, 모노, 실행할 수 있기 때문에 더 많은 배포 상황에서 사용될 수 . 내부 목적으로 주로 사용되는 클래스 라이브러리 프로젝트의 경우 큰 문제가되지 않을 수 있습니다.

.NET Standard는 시스템 관리자 팀이 철학적이거나 비용적인 이유로 Windows의 ASP.NET에서 Linux의 .NET Core 용 ASP.NET으로 이동하려는 경우에도 유용 할 수 있지만 개발 팀은 계속해서 작업하고 싶어합니다. Windows의 Visual Studio에서 NET Framework.

.NET Framework와 .NET Core는 모두 프레임 워크입니다.

.NET 표준은 표준 (즉, 사양)입니다.

.NET Framework 및 .NET Core를 사용하여 콘솔 응용 프로그램 또는 ASP.NET 응용 프로그램과 같은 실행 가능 프로젝트를 만들 수 있지만 .NET Standard는 사용할 수 없습니다.

.NET Standard를 사용하면 독립형으로 실행할 수없고 다른 .NET Core 또는 .NET Framework 실행 파일 프로젝트에서 참조해야하는 클래스 라이브러리 프로젝트 만 만들 수 있습니다.

이것이 .NET 표준 API 표면과 다른 .NET 플랫폼 간의 관계 를 이해하는 데 도움이되기를 바랍니다 . 각 인터페이스는 대상 프레임 워크를 나타내며 메소드는 해당 대상 프레임 워크에서 사용 가능한 API 그룹을 나타냅니다.

namespace Analogy
{
  // .NET Standard

interface INetStandard10
{
    void Primitives();
    void Reflection();
    void Tasks();
    void Xml();
    void Collections();
    void Linq();
}

interface INetStandard11 : INetStandard10
{
    void ConcurrentCollections();
    void LinqParallel();
    void Compression();
    void HttpClient();
}

interface INetStandard12 : INetStandard11
{
    void ThreadingTimer();
}

interface INetStandard13 : INetStandard12
{
    //.NET Standard 1.3 specific APIs
}

// And so on ...


// .NET Framework 

interface INetFramework45 : INetStandard11
{
    void FileSystem();
    void Console();
    void ThreadPool();
    void Crypto();
    void WebSockets();
    void Process();
    void Drawing();
    void SystemWeb();
    void WPF();
    void WindowsForms();
    void WCF();
}

interface INetFramework451 : INetFramework45, INetStandard12
{
    // .NET Framework 4.5.1 specific APIs
}

interface INetFramework452 : INetFramework451, INetStandard12
{
    // .NET Framework 4.5.2 specific APIs
}

interface INetFramework46 : INetFramework452, INetStandard13
{
    // .NET Framework 4.6 specific APIs
}

interface INetFramework461 : INetFramework46, INetStandard14
{
    // .NET Framework 4.6.1 specific APIs
}

interface INetFramework462 : INetFramework461, INetStandard15
{
    // .NET Framework 4.6.2 specific APIs
}

// .NET Core
interface INetCoreApp10 : INetStandard15
{
    // TODO: .NET Core 1.0 specific APIs
}
// Windows Universal Platform
interface IWindowsUniversalPlatform : INetStandard13
{
    void GPS();
    void Xaml();
}

// Xamarin 
interface IXamarinIOS : INetStandard15
{
    void AppleAPIs();
}

interface IXamarinAndroid : INetStandard15
{
    void GoogleAPIs();
}    
// Future platform

interface ISomeFuturePlatform : INetStandard13
{
    // A future platform chooses to implement a specific .NET Standard version.
    // All libraries that target that version are instantly compatible with this new
    // platform
}
}

출처

필사자들은 기존 도구와 프레임 워크 (Xamarin, Unity 등)를 사용하여 작업을 수행하므로 차이점을 설명하는 또 다른 방법은 실제 사례를 사용하는 것입니다.

따라서 .NET Framework를 사용하면 모든 .NET 도구를 사용할 수 있지만 Windows 응용 프로그램 (UWP, Winforms, ASP.NET 등) 만 대상으로 지정할 수 있습니다. .NET Framework는 비공개 소스이므로 별다른 문제가 없습니다.

.NET Core를 사용하면 도구 수가 적지 만 기본 데스크톱 플랫폼 (Windows, Linux, Mac)을 대상으로 할 수 있습니다. 이는 Linux에서 Asp.net을 호스팅 할 수 있기 때문에 ASP.NET Core 응용 프로그램에 특히 유용합니다 (저렴한 호스팅 가격). 이제 .NET Core는 공개 소스이므로 다른 플랫폼을위한 라이브러리를 기술적으로 개발할 수 있습니다. 그러나 그것을 지원하는 프레임 워크가 없기 때문에 좋은 생각은 아닙니다.

.NET Standard를 사용하면 도구 수가 적지 만 모든 플랫폼을 타겟팅 할 수 있습니다. Xamarin 덕분에 모바일을 타겟팅 할 수 있으며 Mono / Unity 덕분에 게임 콘솔을 대상으로 할 수도 있습니다. 업데이트 : UNO 플랫폼과 Blazor를 사용하여 웹 클라이언트를 대상으로 할 수도 있습니다 (두 가지 모두 현재 실험 중이지만).

실제 응용 프로그램에서는 모든 응용 프로그램을 사용해야합니다. 예를 들어 다음 아키텍처를 가진 POS 응용 프로그램을 개발했습니다.

서버와 클라이언트 모두 공유 :

• 내 응용 프로그램의 모델을 처리하는 .NET 표준 라이브러리.
• 클라이언트가 보낸 데이터의 유효성 검사를 처리하는 .NET 표준 라이브러리.

.NET 표준 라이브러리이므로 다른 프로젝트 (클라이언트 및 서버)에서 사용할 수 있습니다.

또한 서버와 클라이언트에 동일한 유효성 검사가 적용되는지 확인할 수 있기 때문에 .NET 표준 라이브러리에서 유효성 검사를 수행하면 좋은 이점이 있습니다. 서버는 필수이며 클라이언트는 선택 사항이며 트래픽을 줄이는 데 유용합니다.

서버 측 (웹 API) :

• 모든 데이터베이스 연결을 처리하는 .NET 표준 (Core 일 수도 있음) 라이브러리

• Rest API를 처리하고 데이터베이스 라이브러리를 사용하는 .NET Core 프로젝트.

이것이 .NET Core에서 개발되었으므로 Linux 서버에서 응용 프로그램을 호스팅 할 수 있습니다.

클라이언트 측 (WPF + Xamarin.Forms Android / IOS가 포함 된 VMVM) :

• 클라이언트 API 연결을 처리하는 .NET 표준 라이브러리.

• ViewModels 논리를 처리하는 .NET 표준 라이브러리. 모든보기에서 사용됩니다.

• Windows 응용 프로그램의 WPF보기를 처리하는 .NET Framework WPF 응용 프로그램 업데이트 : WPF 응용 프로그램은 현재 Windows에서만 작동하지만 .NET 코어 일 수 있습니다. AvaloniaUI는 다른 데스크탑 플랫폼 용 데스크탑 GUI 응용 프로그램을 만들기위한 좋은 대안입니다.

• Xamarin Forms보기를 처리하는 .NET 표준 라이브러리.

• Xamarin Android 및 Xamarin IOS 프로젝트

따라서 .NET 표준 라이브러리 (클라이언트 API 및 ViewModels)를 모두 재사용하고 WPF, Xamarin 및 IOS 응용 프로그램에 대한 논리없이 뷰를 만들 수 있기 때문에 응용 프로그램의 클라이언트 측에서 큰 이점이 있음을 알 수 있습니다.

.NET 표준 : 큰 표준 라이브러리로 생각하십시오. 이것을 종속성으로 사용하면 실행 파일이 아닌 라이브러리 (.DLL) 만 만들 수 있습니다. .NET 표준으로 종속성으로 만든 라이브러리를 Xamarin.Android, Xamarin.iOS, .NET Core Windows / OS X / Linux 프로젝트에 추가 할 수 있습니다.

.NET Core : 기존 .NET 프레임 워크의 연속이라고 생각하십시오. 오픈 소스이고 일부는 아직 구현되지 않았으며 일부는 더 이상 사용되지 않습니다. 추가 기능으로 .NET 표준을 확장하지만 데스크톱 에서만 실행됩니다 . 이것을 의존성으로 추가하면 Windows, Linux 및 OS X에서 실행 가능한 응용 프로그램을 만들 수 있습니다. (현재 콘솔 만 GUI는 없음). 따라서 .NET Core = .NET Standard + 데스크톱 전용 항목입니다.

또한 UWP 는이를 사용하고 새로운 ASP.NET Core 는이를 종속성으로 사용합니다.

.NET 표준은 주로 코드 공유를 개선하고 각 .NET 구현에서 API를보다 일관성있게 만들기 위해 존재합니다.

라이브러리를 만드는 동안 대상 라이브러리를 .NET Standard 2.0으로 만들 수 있으므로 생성 된 라이브러리가 .NET Core, Mono 등을 포함한 다른 버전의 .NET Framework와 호환 될 수 있습니다 .

위의 답변은 net core, net standard 및 net framwork의 차이점에 대한 최상의 이해를 설명 할 수 있으므로 이것을 선택할 때 내 경험을 공유하고 싶습니다.

프로젝트에서 .NET Framework, .NET Core 및 .NET Standard를 혼합해야합니다. 예를 들어, .NET Core 1.0으로 시스템을 구축 할 때 .net 코어로 호스팅되는 Window Services는 지원되지 않습니다.

다음 이유는 .NET Core를 지원하지 않는 Active Report를 사용했기 때문입니다. 따라서 우리는 .NET Core (asp.net 코어)와 Windows 서비스 및보고 (.NET Framework) 모두에 사용할 수있는 인프라 라이브러리를 구축하려고합니다. .NET 표준을 선택한다는 것은 라이브러리의 모든 클래스가 단순하고 .NET (핵심, 프레임 워크, 표준)이어야한다는 점을주의해서 고려해야한다는 의미입니다.

결론:

• 인프라 라이브러리 및 공유 공통을위한 .NET 표준. 이 lib는 .NET Framework 및 .NET Core에서 참조 할 수 있습니다.
• Active Report, Window Services (현재는 .NET 3.0에서 지원)와 같은 지원되지 않는 기술을위한 .NET Framework.
• 물론 ASP.NET Core를위한 .NET Core.

Microsoft는 방금 .NET 5를 발표했습니다. https://devblogs.microsoft.com/dotnet/introducing-net-5/

.NET Framework Windows Form, ASP.NET 및 WPF 응용 프로그램은 .NET Framework 라이브러리를 사용하여 개발해야합니다.

.NET 표준 Xamarin, IO 및 MAC OSx 애플리케이션은 .NET 표준 라이브러리를 사용하여 폐기해야합니다.

.NET Core
UWP (유니버설 Windows 플랫폼) 및 Linux 응용 프로그램은 .NET Core 라이브러리를 사용하여 개발해야합니다. API는 C ++로 구현되며 C ++, VB.NET, C #, F # 및 Javascript 언어를 사용할 수 있습니다.

.Net 핵심 클래스 라이브러리는 .Net 표준을 기반으로합니다. .Net Framework, .Net Core 및 Xamarin으로 이식 가능한 라이브러리를 구현하려면 .Net 표준 라이브러리를 선택하십시오.