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

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

---

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

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

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

그렇다면 클래스 라이브러리 (.NET Standard) 와 클래스 라이브러리 (.NET Core) 의 차이점은 무엇이며 둘 다 존재하는 이유는 무엇이며 언제 둘 중 하나를 사용해야합니까?

---

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

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

라이브러리와 호환되는 앱 수를 늘리고 라이브러리에서 액세스 할 수있는 .NET API 노출 영역을 줄여도 괜찮을 때 .NET Standard 라이브러리를 사용합니다.

라이브러리에서 액세스 할 수있는 .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 Standard)와 클래스 라이브러리 (.NET Core)의 차이점은 무엇입니까?

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

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

API 노출 영역 : .NET Standard 라이브러리에는 모든 것이 포함되어있는 NETStandard.Library반면 .NET Core 라이브러리는 Microsoft.NETCore.App. 후자는 약 20 개의 추가 라이브러리를 포함하며, 그중 일부는 .NET Standard 라이브러리 (예 :)에 수동으로 추가 할 수 System.Threading.Thread있고 일부는 .NET Standard (예 :)와 호환되지 않습니다 Microsoft.NETCore.CoreCLR.

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

둘 다 존재하는 이유는 무엇입니까?

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

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

---

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

.Net Core는 궁극적으로 .Net Standard 2를 구현할 것입니다 ( Xamarin 및 .Net Framework 와 마찬가지로 ).

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

코드 공유 및 재사용을 위해 애플리케이션의 미래를 보장하려면 .Net Standard 라이브러리를 구현하는 것이 좋습니다.

또한 이식 가능한 클래스 라이브러리 대신 .NET Standard 를 사용하는 것이 좋습니다 .

MSDN을 신뢰할 수있는 출처로 인용 하기 위해 .Net Standard 는 모두를 지배하는 하나의 라이브러리로 만들어졌습니다 . 사진은 천 단어의 가치가 있으므로 다음은 상황을 매우 명확하게합니다.

1. 현재 애플리케이션 시나리오 (조각화)

우리 대부분과 마찬가지로 다음과 같은 상황에 처해있을 것입니다. (.Net Framework, Xamarin 및 현재 .Net Core 버전 애플리케이션)

2. .Net 표준 라이브러리가 제공하는 것 (프레임 워크 간 호환성)

.Net 표준 라이브러리를 구현하면 다음과 같은 모든 유형에서 코드를 공유 할 수 있습니다.

참을성이없는 사람들 :

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

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

출처 : MSDN : .Net Standard 소개

---

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

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

---

.Net Framework 및 .Net Core 는 .Net 런타임의 두 가지 다른 구현입니다. Core와 Framework (특히 Framework)는 설치 위치와 프로필에 따라 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 버전에 대한 지원을 제공하는 한 프로그램은 그곳에서 실행되어야합니다.

표준 버전을 대상으로하는 프로젝트는 해당 표준 개정판에 포함되지 않은 기능을 사용할 수 없습니다. 그렇다고 다른 어셈블리 나 다른 공급 업체가 게시 한 API (예 : NuGet의 항목)에 대한 종속성을 가질 수 없다는 의미는 아닙니다. 그러나 그것은 당신이 취하는 모든 의존성이 당신의 .Net Standard 버전에 대한 지원도 포함해야 함을 의미합니다. .Net Standard는 빠르게 발전하고 있지만 여전히 새롭고 더 작은 런타임 프로필에 대해 충분히 신경을 써서이 제한이 숨 막힐 수 있습니다. (1 년 반 후 : 이것은 변경되기 시작했으며 최신 .Net Standard 버전은 훨씬 더 멋지고 완전한 기능을 갖추고 있습니다).

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

.Net Standard는 또한 SysAdmin 팀이 철학적 또는 비용상의 이유로 Windows의 ASP.Net에서 Linux의 .Net Core를위한 ASP.Net으로 이동하고 싶지만 개발 팀이 .Net에 대해 계속 작업하고자하는 상황에서도 유용 할 수 있습니다. Windows 용 Visual Studio의 프레임 워크.

---

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

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

.NET Framework 및 .NET Core에서는 실행 가능한 프로젝트 (예 : 콘솔 애플리케이션 또는 ASP.NET 애플리케이션)를 만들 수 있지만 .NET Standard에서는 만들 수 없습니다.

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

---

이것이 .NET Standard 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 등)를 사용하여 작업을 수행하기 때문입니다.

So, with .NET Framework you have all the .NET tools to work with but you can only target Windows applications (UWP, Winforms, ASP.NET, etc). Since .NET Framework is closed source there isn't much to do about it.

With .NET Core you have less tools but you can target the main Desktop Platforms (Windows, Linux, Mac). This is specially useful in ASP.NET Core applications, since you can now host Asp.net in Linux (cheaper hosting prices). Now, since .NET Core was open sourced, it's technically possible to develop libraries for other platforms. But since there aren't frameworks that support it, i don't think that's a good idea.

With .NET Standard you have even less tools but you can target all/most platforms. You can target Mobile thanks to Xamarin, and you can even target Game Consoles thanks to Mono/Unity.

In a real world application you may need to use all of them. For example, i developed a point of sale application that had the following architecture:

Shared both Server and Client:

• A .NET Standard library that handles the Models of my application.

Since it's a .NET Standard library, it can be used in any other library.

Server Side (Web API):

• A .NET Standard (could be Core as well) library that handles all the database connections.

• A .NET Core project that handles the Rest API and makes use of the database library.

As this is developed in .NET Core, i can host the application on a Linux server.

Client Side (MVVM with WPF + Xamarin.Forms Android/IOS):

• A .NET Standard library that handles the client API connection.

• A .NET Standard library that handles the ViewModels Logic. Used in all the views.

• A .NET Framework WPF application that handles the WPF views for a windows application.

• A .NET Standard library that handles Xamarin Forms views.

• A Xamarin Android and Xamarin IOS project.

So you can see that there's a big advantage here in the client side of the application since i can reuse both .NET Standard libraries (Client API and ViewModels) and just make views with no logic for the WPF, Xamarin and IOS applications.

---

.NET Standard: Think of it as a big standard library. When using this as a dependency you can only make libraries (.DLLs), not executables. A library made with .NET standard as a dependency can be added to a Xamarin.Android, a Xamarin.iOS, a .NET Core Windows/OSX/Linux project.

.NET Core: Think of it as the continuation of the old .NET framework, just it's opensource and some stuff is not yet implemented and others got deprecated. It extends the .NET standard with extra functions, but only runs on Desktops. When adding this as a dependency you can make runnable apps on Windows, Linux and OSX. (Although console only for now, no GUIs). So .NET Core = .NET Standard + Desktop specific stuff.
Also UWP uses it and the new ASP.NET core uses it as a dependency too.

---

.Net Standard exists mainly to improve code sharing and make the APIs available in each .Net implementation more consistent.

While creating Libraries we can have target as.Net Standard 2.0 so that the library created would be compaitible with different versions of .Net Framework including .Net Core,Mono..

---

Above answers may describe the best understanding about the difference between net core, net standard and net framwork so I just want to share my experience when choosing this over that.

In the project that you need to mix between .NET Framework, .NET Core and .NET Standard. For example, at the time we build the system with .NET Core 1.0, there is no support for Window Services hosting with .net core.

The next reason is we were using Active Report which doesn't support .NET Core. So we want to build an infrastructure library that can be used for both .NET Core (asp.net core) and Windows Service and Reporting (.NET Framework) -> That's why we chose .NET Standard for this kind of library. Choosing .NET standard means you need to carefully consider every class in the library should be simple and cross .NET (core, framework, standard).

Conclusion:

• .NET Standard for the infrastructure library and shared common. This lib can be referenced by .NET Framework and .NET Core.
• .NET Framework for unsupported technologies like Active Report, Window Services (now with .NET 3.0 it supports).
• .NET Core for ASP.NET Core of course.

Microsoft just announced .NET 5: https://devblogs.microsoft.com/dotnet/introducing-net-5/

---

.NET Framework Windows Form, ASP.NET and WPF application must be developed using .NET Framework library

.NET Standard Xamarin, IOs and MAC OSx application must be devoped using .NET Standard library

.NET Core
Universal Windows Platform (UWP) and Linux application must be developed using .NET Core library. The API is implemented in C++ and you can using C++, VB.NET, C#, F# and Javascript languages.NET

---

.NET Standard is common part of both .NET Framework and .NET Core

Quote:

Libraries are quickly embracing .NET Standard. .NET Standard enables sharing code across all .NET implementations including .NET Core. With .NET Standard 2.0, this is even easier:

• The API surface became much larger.

• Introduced a .NET Framework compatibility mode. This compatibility mode allows .NET Standard/.NET Core projects to reference .NET Framework libraries. To learn more about the compatibility mode, see Announcing .NET Standard 2.0.

So only in cases where the libraries or NuGet packages use technologies that aren't available in .NET Standard/.NET Core, you need to use the .NET Framework.

Source: https://docs.microsoft.com/en-us/dotnet/standard/choosing-core-framework-server#a-need-to-use-third-party-net-libraries-or-nuget-packages-not-available-for-net-core

For example, RabbitMQ use .NET Standard: https://www.rabbitmq.com/dotnet.html

Extended information with .NET 5:

Do we still need .NET Standard? We are working through these issues now and will soon be sharing design docs for you to read and give feedback on.

Source: https://devblogs.microsoft.com/dotnet/introducing-net-5/

참고 URL : https://stackoverflow.com/questions/42939454/what-is-the-difference-between-net-core-and-net-standard-class-library-project