오늘 우리는 .NET Core 3.0 이후의 다음 릴리스가 .NET 5가 될 것임을 발표합니다. 이 작품은 .NET 시리즈의 다음 큰 릴리스가 될 것입니다.
앞으로는 .NET 하나만 사용할 예정이며, Windows, Linux, macOS, iOS, Android, tvOS, watchOS, WebAssembly 등 다양한 프로그램을 개발할 수 있습니다.
우리는 .NET 5에서 새로운 .NET API, 런타임 기능, 언어 기능을 도입하고 있습니다.
.NET Core 프로젝트부터 시작해 약 5만 개의 .NET Framework API를 플랫폼에 추가했습니다. .NET Core 3.0은 .NET Framework 4.8의 남은 기능 공백 대부분을 메우며, Windows Forms, WPF, Entity Framework 6를 지원합니다. .NET 5는 이 작업을 기반으로 .NET Core와 Mono의 장점을 활용해 플랫폼을 만듭니다. 모든 최신 .NET 코드에 사용할 수 있습니다.
우리는 2020년 11월에 .NET 5를 출시하고, 2020년 상반기에 첫 프리뷰를 출시할 계획입니다. 향후 Visual Studio 2019, Visual Studio for Mac, Visual Studio Code 업데이트에서 지원될 예정입니다.
.NET 5 = .NET Core vNext
.NET 5는 .NET Core의 다음 단계입니다. 이 프로젝트는 . NET:
- 어디서나 사용할 수 있는 .NET 런타임과 프레임워크를 구축하며, 통합 런타임 동작과 개발자 경험을 갖추세요.
- .NET Core를 최대한 활용하면, . .NET의 기능을 확장하기 위해 NET 프레임워크, Xamarin, Mono를 활용했습니다.
- 단일 코드베이스에서 제품을 구축함으로써 개발자들(마이크로소프트와 커뮤니티)이 함께 협력하고 확장하여 모든 상황을 개선할 수 있습니다.
이 새로운 프로젝트와 방향은 .NET에 있어 중요한 전환점입니다. .NET 5에서는 어떤 종류의 애플리케이션을 만들든 코드와 프로젝트 파일이 동일하게 유지됩니다. 각 앱은 동일한 런타임, API, 언어 기능을 사용할 수 있습니다. 또한 거의 매일 이루어지고 있는 CoreFX의 성능 향상도 포함되어 있습니다.
.NET 코어에서 사랑하는 모든 것은 계속 존재할 것입니다:
- GitHub에서 오픈 소스이자 커뮤니티 지향적입니다.
- 크로스 플랫폼 구현.
- Windows의 Windows 폼과 WPF 같은 플랫폼별 기능을 활용하고, Xamarin의 각 네이티브 플랫폼별 네이티브 바인딩을 지원합니다.
- 고성능
- 나란히 설치하세요.
- 작은 프로젝트 파일들(SDK 스타일).
- 명령줄 인터페이스(CLI)와 호환됩니다.
- Visual Studio, Mac 버전의 Visual Studio, 그리고 Visual Studio Code 연동.
또한 새로운 요소들도 있습니다:
- 런타임 경험에 대한 선택지가 더 많아질 거예요(아래에서 더 자세히 다룰 예정입니다).
- Java 상호운용성은 모든 플랫폼에서 제공될 예정입니다.
- 여러 운영체제가 Objective-C와 Swift 상호운용성을 지원합니다.
- CoreFX는 .NET의 사전 제공(ahead-of-time, AOT) 지원, 더 작은 용량, 그리고 더 많은 운영체제 지원으로 확장될 예정입니다.
올해 9월에 .NET Core 3.0을, 2020년 11월에 .NET 5를 출시할 예정이며, 이후 .NET Core 의 주요 버전도 출시할 계획입니다. NET:
4 버전은 .NET 프레임워크에 익숙한 사용자들이 혼란스러워할 수 있어 건너뛰었습니다. .NET 프레임워크는 4.x 시리즈로 오랫동안 사용되어 왔습니다. 또한, .NET 5가 .NET 플랫폼의 미래임을 명확히 전달하고자 합니다. .NET 5라고 부르면 지금까지 출시한 버전이 가장 높습니다.
또한 이 기회를 빌려 명명을 단순화합니다. 우리는 .NET 하나만이 최고라면 "코어" 같은 명확한 용어가 필요 없다고 생각합니다. 더 짧은 이름은 단순화된 것이며, .NET 5가 동일한 기능과 동작을 가진다는 메시지를 전달합니다. 물론, 원한다면 ".NET Core"라는 이름을 계속 사용할 수도 있습니다.
런타임 경험
모노는 .NET의 원조 크로스 플랫폼 구현체입니다. 처음에는 .NET 프레임워크의 오픈 소스 대안으로 시작했으며, iPhone/iOS와 Android 기기의 인기를 끌면서 모바일 전용 제품으로 전환되었습니다. 모노는 Xamarin의 일부로 사용되는 런타임입니다.
CoreCLR은 .NET Core의 일부로 사용되는 런타임입니다. 주로 마이크로소프트의 최대 서비스를 포함한 클라우드 애플리케이션 지원에 사용되며, 현재는 윈도우 데스크톱, IoT, 머신러닝 애플리케이션에서도 사용되고 있습니다.
요약하자면, .NET Core와 Mono 런타임은 많은 유사점을 가지고 있지만(결국 둘 다 .NE 런타임이니까요), 또한 고유한 가치 있는 기능들도 가지고 있습니다. 원하는 런타임 경험을 선택할 수 있게 하는 것이 매우 합리적입니다. 우리는 CoreCLR과 Mono를 서로 교환 가능하게 만들고 있습니다. 우리는 다양한 런타임 옵션 중에서 선택할 수 있는 스위치를 만드는 것만큼 간단하게 만들 것입니다.
다음 섹션들은 .NET 5에서 사용할 주요 초점을 설명합니다. 이 두 러닝타임을 개별적으로, 그리고 함께 어떻게 발전시킬 계획인지에 대한 명확한 관점을 제공합니다.
높은 처리량과 높은 생산성
처음부터 .NET은 중간 언어(IL) 코드를 최적화된 기계어로 변환하기 위해 적시 컴파일러(JIT)에 의존했습니다. 그 이후로 우리는 업계 선도의 JIT 기반 관리형 런타임을 구축했으며, 이는 매우 높은 처리량을 자랑하고 개발자 경험을 개선하여 프로그래밍을 빠르고 쉽게 만듭니다.
JIT는 장기간 실행되는 클라우드 및 클라이언트 시나리오에 이상적입니다. 특정 머신, 특히 특정 CPU 명령어에 맞게 구성된 코드를 생성할 수 있습니다. JIT는 런타임에 메서드를 재생성할 수 있어, JIT이 더 빠르게 작동하면서도 자주 사용될 경우 고도로 최적화된 코드를 생성할 수 있는 옵션을 제공합니다.
ASP.NET Core가 Techpower 벤치마크에서 더 빠르게 실행되도록 하려는 우리의 노력은 JIT의 힘과 CoreCLR에 대한 투자의 훌륭한 예입니다. 컨테이너용 .NET 코어의 강화 노력은 런타임이 제한된 환경에 동적으로 적응할 수 있음을 증명하는 증거이기도 합니다.
개발자 도구들도 dotnet watch tools나 edit and continue 같은 JIT의 훌륭한 예입니다. 도구는 종종 재시작 없이 한 프로세스에서 여러 번 코드를 컴파일하고 로드해야 하며, 이를 매우 빠르게 해야 합니다.
.NET 코어 또는 .NET 프레임워크를 사용하는 개발자들은 주로 JIT에 의존합니다. 따라서 경험은 익숙해야 합니다.
대부분의 .NET 5 작업 시나리오에서 기본 경험은 JIT 기반 CoreCLR 런타임을 사용합니다. 두 가지 주목할 만한 예외는 iOS와 클라이언트 Blazor(웹 어셈블리)로, 둘 다 사전 작성(AOT) 네이티브 컴파일이 필요합니다.
빠른 시작 동작, 작은 공간, 낮은 메모리 사용량
모노 프로젝트의 대부분은 모바일과 콘솔에 집중되어 왔습니다. 이 프로젝트의 핵심 기능과 결과 중 하나는 업계 선도적인 LLVM 컴파일러 프로젝트를 기반으로 한 .NET AOT 컴파일러입니다. Mono AOT 컴파일러는 .NET 코드를 컴퓨터에서 실행할 수 있는 네이티브 코드 실행 파일에 내장할 수 있게 해주며, 이는 C++ 코드와 같습니다. AOT 컴파일 애플리케이션은 더 작은 위치에서도 효율적으로 실행될 수 있으며, 필요할 때 시작 시 처리량을 교환할 수 있습니다.
Blazor 프로젝트는 이미 Mono AOT를 사용하고 있습니다. 이 프로젝트는 .NET 5로 전환하는 첫 번째 프로젝트 중 하나가 될 것입니다. 우리는 이 계획을 증명하는 옵션 중 하나로 사용합니다.
AOT 솔루션에는 두 가지 유형이 있습니다:
- 100% AOT 컴파일된 해결책이 필요합니다.
- 대부분의 코드는 AOT 컴파일된 솔루션이지만, JIT나 인터프리터는 AOT에 적합하지 않은 코드 패턴(예: 제네릭)에 사용할 수 있습니다. 모노 AOT는 두 가지 상황 모두를 지원합니다. 애플은 보안상의 이유로 iOS와 일부 콘솔에서 첫 번째 AOT를 요구하고 있습니다. 두 번째 방법은 AOT의 장점을 제공하면서 단점을 피할 수 있어 더 나은 선택입니다.
.NET Native는 Windows UWP 애플리케이션용 AOT 컴파일러이며, 위에 언급된 첫 번째 AOT 유형의 예시이기도 합니다. 이 구현에서는 .NET API와 사용할 수 있는 기능을 제한합니다. 이 경험을 통해 AOT 솔루션은 .NET API와 패턴의 모든 측면을 포괄해야 한다는 것을 배웠습니다.
AOT 컴파일은 여전히 iOS, 웹 어셈블리, 일부 콘솔에서 필요합니다. 빠른 시작이나 저용량이 필요한 애플리케이션에는 AOT 컴파일 옵션을 제공할 예정입니다.
프로젝트의 탄생
이 프로젝트는 2018년 12월 보스턴의 기술팀과 함께 시작했습니다. .NET 팀(Mono/Xamarin과 .NET Core)과 Unity의 디자인 리더들이 다양한 기술적 역량과 아키텍처 방향을 제시했습니다.
이제 우리는 팀으로서 일련의 산출물을 가지고 프로젝트를 진행하고 있습니다. 12월 이후 여러 프로젝트에서 많은 진전을 이루었습니다:
- 최소 계층은 CoreFX 공공 코드의 > 99%를 달성하기 위해 런타임 <-> 관리 코드 계층을 정의합니다.
- MonoVM은 이제 CoreFX와 그 클래스 라이브러리를 사용할 수 있습니다.
- CoreFX 구현이 적용된 MonoVM에서 모든 CoreFX 테스트를 실행하세요.
- MonoVM ASP.NET Core 3.0 애플리케이션을 실행하세요.
- CoreCLR에서 MonoDevelop을 실행한 다음, Mac 버전의 Visual Studio를 실행하세요.
단일 . .NET 구현은 몇 가지 중요한 질문을 제기합니다: 목표 프레임워크는 무엇일까요? NuGet 패키지 호환성 규칙이 동일한가요? .NET 5 SDK가 지원해야 할 워크로드는 무엇인가요? 특정 아키텍처를 위해 어떻게 코딩하나요? 여전히 .NET Standard가 필요한가요?
현재 이 문제들을 해결 중이며, 곧 디자인 문서를 공유하여 여러분이 읽고 피드백을 받을 수 있도록 할 예정입니다.
에필로그
.NET 5 프로젝트는 .NET에 있어 중요하고 흥미로운 새로운 방향입니다. .NET은 더 단순해지면서도 기능과 유용성도 더 넓어질 것입니다. 모든 새로운 개발과 기능은 .NET 5에 포함되며, 새로운 C# 버전도 포함됩니다.
우리는 동일한 .NET API와 언어를 사용하여 다양한 애플리케이션 유형, 운영체제, 실리콘 아키텍처를 겨냥할 수 있는 밝은 미래를 보고 있습니다. Visual Studio, Visual Studio for Mac, Visual Studio Code, Azure DevOps, 명령줄 등에서 빌드 구성을 변경해 다양한 애플리케이션을 만들 수 있습니다.
원본 링크:하이퍼링크 로그인이 보입니다.
|
게시됨 2019. 5. 7. 오전 9:41:27
|
|
|
|
