다음으로ASP.NET Core Demystified시리즈에서IActionResult인터페이스를 구현하고 해당ActionResult클래스 에서 상속 하는 모든 클래스를 논의하고 시연합니다 . 이러한 클래스는 컨트롤러 작업의 응답으로 사용되며 다른 사이트로 리디렉션, 다른 컨트롤러 작업으로 리디렉션, JSON 객체 반환 및 파일을 브라우저로 반환하는 것을 포함합니다.
이 글에서는 먼저 IActionResult인터페이스와 인터페이스에 대해 논의한 다음 인터페이스의 사용 가능한 여러 구현 및 각 인터페이스를 사용할 수있는 시나리오에 대한 데모를 보게됩니다.
샘플 프로젝트
코드가 많은 게시물과 마찬가지로GitHub에는이 게시물에서 논의 할 작업 결과를 보여주는 실제 프로젝트가 있습니다.확인 해봐!
엄밀히 말하자면 Action Results는 IActionResultASP.NET Core MVC 의 인터페이스 를 구현하는 클래스입니다 . 그러나이 게시물에서 보게 될 모든 작업 결과는 ActionResult클래스 에서 상속됩니다 .
간단히 말해 Action Results는 컨트롤러 작업의 결과로 클라이언트가해야 할 일을 나타내는 클래스입니다. 파일을 가져 오거나 리디렉션하거나 무수히 많은 것들이 필요할 수 있습니다. 일부 조치 결과는 HTTP 상태 코드 만 리턴합니다. 요컨대, 컨트롤러 조치를 호출 한 후 클라이언트가 원할 수있는 가장 일반적인 작업은 조치 결과로 표시됩니다.
주간 뉴스 레터 "캐치 블록"을 받으십시오!
콘텐츠 협상
요청에Accept헤더가있는경우컨텐츠 협상(약칭 연결)이 발생합니다.서버가 응답을 보낼 형식을 결정하는 프로세스입니다.기본적으로 ASP.NET Core는 응답에 JSON을 사용하지만 요청Accept헤더는 다른 형식 (예 : XML)을 지정할 수 있으며 서버는 지정된 형식으로 응답을 반환하려고 시도합니다.
서버가 요청에서Accept헤더를감지하면 서버가 지원하는 헤더를 찾기 위해 해당 헤더의 미디어 유형을 열거합니다.서버가 지원할 수있는 미디어 유형이없는 경우 서버는 요청을 생성 할 수있는 지원되는 첫 번째 미디어 유형을 사용합니다 (따라서이 프로세스를컨텐츠 협상이라고하며이 형식을 지금 제게하지 마십시오).
액션 결과 세트
5 가지 주요 작업 결과 세트가 있습니다.
상태 코드 결과
객체 결과가있는 상태 코드
결과 리디렉션
파일 결과
컨텐츠 결과
이러한 각 세트를 개별적으로 논의하고 그 결과의 종류에 대한 예를 보여줍니다.이 게시물에서 볼 수있는 모든 데모는GitHub의샘플 프로젝트에도있으므로 확인하십시오!
상태 코드 결과
아마도 ASP.NET Core MVC에 의해 정의 된 가장 간단한 종류의 작업 결과는 상태 코드 결과 모음입니다. 이 결과는 단지 클라이언트에게 HTTP 상태 코드를 반환합니다.
OkResult
OkResult(짧은 방법 : Ok()) 반환 200 OK의 상태 코드를.
public IActionResult OkResult()
{
return Ok();
}
CreatedResult
CreatedResult(짧은 방법 : Created()) 반환 만든 201 생성 된 리소스에 URL과 함께합니다.
public IActionResult CreatedResult()
{
return Created("http://example.org/myitem", new { name = "testitem" });
}
NoContentResult
NoContentResult(짧은 방법 : NoContent())를 반환 (204) 내용 없음 서버가 요청을 성공적으로 처리되었음을 나타내는 상태 코드 만 반환에 아무것도 없다는 것을.
public IActionResult NoContentResult()
{
return NoContent();
}
BadRequestResult
BadRequestResult(짧은 방법 BadRequest()) 창 400 잘못된 요청 서버는 상기 요청에 의한 오류로 상기 요청을 처리 할 수 있음을 나타낸다. 요청의 유효성 검사가 실패하고 더 적합한 코드가없는 경우 API에서 종종 사용됩니다.
public IActionResult BadRequestResult()
{
return BadRequest();
}
무단 결과
UnauthorizedResult(짧은 방법 : Unauthorized()) 반환 무단 (401)를 요청하는 사용자가 (정말라고되어 있어야합니다이 상태 코드를 의미 그렇게 할 수있는 적절한 인증이 없기 때문에 요청을 처리 할 수 없음을 나타내는, 401 인증되지 않은를 ).
public IActionResult UnauthorizedResult()
{
return Unauthorized();
}
NotFoundResult
NotFoundResult(짧은 방법 : NotFound())을 반환 (404) 찾을 수 없음 요청 된 자원이, 어떤 이유로, 서버에서 찾을 수 없음을 나타내는 상태 코드.
public IActionResult NotFoundResult()
{
return NotFound();
}
지원되지 않는 MediaTypeResult
UnsupportedMediaTypeResult글을 쓰는 시점에서 짧은 방법이없는 이는, 반환 415 지원되지 않는 미디어 유형 미디어 유형 (요청에 예를 들어, Content-Type 헤더는)이 서버에서 지원하지 않는 것을 나타냅니다. 예를 들어, 사용자가 .bmp 형식으로 이미지를 업로드하려고 시도 할 때 서버는이 상태 코드를 리턴 할 수 있지만 서버는 .jpeg 만 허용 합니다.
public IActionResult UnsupportedMediaTypeResult()
{
return new UnsupportedMediaTypeResult();
}
기타 상태 코드
위의 상태 코드 결과는 가능한 모든 HTTP 상태 코드를 포함하지는 않습니다.전용 작업 결과가 제공되지 않은 상태 코드를 반환해야하는 상황에서는 일반 StatusCodeResult(짧은 방법 :)을 사용할 수 있습니다 StatusCode().
public IActionResult StatusCodeResult(int statusCode)
{
return StatusCode(statusCode);
}
객체 결과가있는 상태 코드
이러한 작업 결과는 대부분 이전 섹션에서 본 결과의 과부하입니다. 그러나 컨텐츠 협상으로 인해 브라우저 또는 다른 요청자가 다르게 처리합니다.
OkObjectResult
OkObjectResult수익률 200 OK 뿐만 아니라 객체입니다.
public IActionResult OkObjectResult()
{
var result = new OkObjectResult(new { message = "200 OK", currentDate = DateTime.Now });
return result;
}
CreateObjectResult
CreatedObjectResult반환 만든 (201) 및 사용자 정의 객체입니다.
public IActionResult CreatedObjectResult()
{
var result = new CreatedAtActionResult("createdobjectresult", "statuscodeobjects", "", new { message = "201 Created", currentDate = DateTime.Now });
return result;
}
BadRequestObjectResult
은 BadRequestObjectResult당신이하지 무슨 생각을 정확히 수행; 400 잘못된 요청 과 개체를 반환 합니다.
public IActionResult BadRequestObjectResult()
{
var result = new BadRequestObjectResult(new { message = "400 Bad Request", currentDate = DateTime.Now });
return result;
}
NotFoundObjectRequest
지금 당신이 패턴을보고 있다고 상상하십니까? NotFoundObjectRequest반환 (404) 찾을 수 없음 과 객체.
public IActionResult NotFoundObjectResult()
{
var result = new NotFoundObjectResult(new { message = "404 Not Found", currentDate = DateTime.Now });
return result;
}
ObjectResult
위 유형에서 다루지 않는 시나리오의 경우 ObjectResult클래스가 있습니다. 지정된 상태 코드와 객체를 반환합니다.
public IActionResult ObjectResult(int statusCode)
{
var result = new ObjectResult(new { statusCode = statusCode, currentDate = DateTime.Now });
result.StatusCode = statusCode;
return result;
}
결과 리디렉션
때로는 클라이언트 (예 : 브라우저)에게 다른 위치로 리디렉션하도록 지시해야합니다. 리디렉션 결과가 나오는 위치는 클라이언트에게 리디렉션 위치를 알려줍니다. 때로는 동일한 프로젝트에서 다른 작업으로 이동해야하는 경우도 있지만 외부 리소스로 리디렉션해야하는 경우도 있습니다.
RedirectResult
기본 RedirectResult클래스 (short method Redirect():)는 지정된 URL로 리디렉션됩니다.
public IActionResult RedirectResult()
{
return Redirect("https://www.exceptionnotfound.net");
}
public IActionResult LocalRedirectResult()
{
return LocalRedirect("/redirects/target");
}
RedirectToActionResult
매우 일반적인 RedirectToActionResult클래스 (short method RedirectToAction():)는 클라이언트를 동일한 응용 프로그램 내의 특정 작업 및 컨트롤러로 리디렉션합니다. LocalRedirectResult예제 에서와 동일한 리디렉션을 수행하려면 다음을 수행하십시오.
public IActionResult RedirectToActionResult()
{
return RedirectToAction("target");
}
RedirectToRouteResult
ASP.NET Core MVC에는 라우팅 개념이 있으며이를 통해 특정 컨트롤러 및 작업에 매핑되는 URL 템플릿을 만들 수 있습니다. 이에 따라 애플리케이션에 이미 정의 된 특정 경로로 리디렉션되는 결과 RedirectToRouteResult(짧은 방법 :)도 있습니다 RedirectToRoute().
주어진 파일의 내용 만 byte[]전체 파일이 아닌 바이트 배열 ( ) 로 반환하려는 경우가 있습니다. 이 시나리오에서는 FileContentResult클래스를 사용할 수 있습니다 . 여전히 MIME 유형을 지정해야합니다.
public IActionResult FileContentResult()
{
//Get the byte array for the document
var pdfBytes = System.IO.File.ReadAllBytes("wwwroot/downloads/pdf-sample.pdf");
//FileContentResult needs a byte array and returns a file with the specified content type.
return new FileContentResult(pdfBytes, "application/pdf");
}
VirtualFileResult
VirtualFileResult클래스를 사용하여 프로젝트의 / wwwroot 폴더에서 파일을 가져올 수도 있습니다 .
public IActionResult VirtualFileResult()
{
//Paths given to the VirtualFileResult are relative to the wwwroot folder.
return new VirtualFileResult("/downloads/pdf-sample.pdf", "application/pdf");
}
PhysicalFileResult
마지막으로 프로젝트의 일부가 아닌 서버의 실제 경로에서 파일을 가져와야 할 경우 PhysicalFileResult클래스를 사용할 수 있습니다 .
public IActionResult PhysicalFileResult()
{
return new PhysicalFileResult(_hostingEnvironment.ContentRootPath + "/wwwroot/downloads/pdf-sample.pdf", "application/pdf");
}
참고 _hostingEnvironment.ContentRootPath응용 프로그램 루트가 아닌 /의 wwwroot 폴더의 경로입니다.
컨텐츠 결과
최종 결과 클래스 세트는 다양한 종류의 컨텐츠를 컨트롤러에 리턴하도록 설계된 컨텐츠 결과 클래스입니다.
ViewResult
아마도 모든 ASP.NET Core MVC에서 가장 기본적인 Result 클래스는 ViewResult클래스 (short method :)이며 View()뷰를 반환합니다.
public IActionResult Index()
{
return View();
}
기본적 View()으로이 메소드는 컨트롤러와 이름이 같은 폴더에서 호출 된 조치와 이름이 같은보기를 리턴합니다. 이 경우 컨트롤러는 "Content"이고 작업은 "Index"이므로 ASP.NET Core MVC는 /Views/Content/Index.cshtml에서 파일을 찾습니다. View()short 메소드의 오버로드를 사용하여 다른 뷰가 리턴되도록 지정할 수 있습니다 .
PartialViewResult
다음 과 같이 클래스 (short method :)를 사용하여 액션에서부분 뷰를 반환 할 수도 있습니다 .PartialViewResultPartialView()
public IActionResult PartialViewResult()
{
return PartialView();
}
데모에서 위의 코드는 / Views / Content 디렉토리와 / Views / Shared 디렉토리 모두에서 "PartialViewResult"라는 이름의 뷰를 찾고 / Views / Shared에서 찾습니다.
public IActionResult JsonResult()
{
return Json(new { message = "This is a JSON result.", date = DateTime.Now });
}
ContentResult
위 카테고리 중 하나에 속하지 않는 컨텐츠를 리턴해야하는 경우 일반 ContentResult오브젝트 (짧은 메소드 Content():)를 사용하여 컨텐츠를 리턴 할 수 있습니다. 데모에서는 간단한 메시지를 리턴하지만이 클래스를 사용하여MediaTypeHeaderValue또는 컨텐츠 유형 을 지정하여보다 복잡한 컨텐츠를 리턴 할 수 있습니다 .
public IActionResult ContentResult()
{
return Content("Here's the ContentResult message.");
}
요약
ASP.NET Core MVC의 작업 결과 클래스는 컨트롤러에서 사용할 기능의 상당 부분을 제공합니다. 상태 코드, 객체, 파일, 기타 컨텐츠를 반환하고 클라이언트를 리디렉션합니다. ASP.NET Core MVC와 그 기능에 익숙해 짐에 따라 이러한 클래스는 두 번째 특성이됩니다. 그때까지이 게시물을 빠른 참조로 사용하여 코드를 작성하십시오.
내 자습서와 마찬가지로GitHub에는 ASP.NET Core MVC에서 사용할 수있는 모든 동작 결과를 익히는 데 사용할 수있는 작동 코드 샘플이 있습니다.
이번 글은 .NET 공식 블로그에 소개된Introducing .NET 5를 번역한 글입니다. .NET Core 3.0을 끝으로 이제는 .NET 코어가 아닌 .NET 5라는 새로운 이름으로 소개되는데요, .NET 4또는 .NET Core 4.0으로 결정되지 않고 .NET 5로 불리게 된 이유는 .NET Framework 4.0과 헷갈릴 수 있기 때문이라고 합니다.
기울임꼴로 표시된 부분은 번역을 그대로 옮기면 자연스럽지 않아 제 맘대로 번역해봤습니다. 이 부분은오역이구만? 이렇게 생각하시면 편할 것 같습니다.
Introducing .NET 5
오늘 우리는.NET Core 3.0의 차기 버전인 .NET 5를 소개하려고 합니다. 이는 .NET 제품군에서상당히 큰 변경을 포함할 것입니다. (next big release)
이제는 제품군이 나뉘지 않고 .NET 하나로 통합될 것이고이를 다양한플랫폼*에서 사용할 수 있게 됩니다. (There will be just one .NET going forward/ * 윈도우, 리눅스, 맥, iOS, Android, WebAssembly 등)
새로운 .NET API와 런타임 호환성/언어 기능들을 소개합니다.
새로운 .NET 소개
.NET Core 프로젝트를 시작할 때 개발팀은 약 5천개의 .NET 프레임워크 API를 추가했습니다.이로써 .NET Core 3.0은 .NET Framework 4.8과 비교했을 때 기능 측면(Windows Forms, WPF 및 Entity Framework 6)에 있어 상당히 근접하게 되었습니다. 또한, .NET 5의 빌드 작업이 여기에 포함되었고 .NET Core + Mono 조합으로 당신의 멋☆진 .NET 코드를 사용할 수 있습니다! (.NET Core 3.0 closes much of the remaining capability gap with .NET Framework 4.8, enabling Windows Forms, WPF and Entity Framework 6. .NET 5 builds on this work, taking .NET Core and the best of Mono to create a single platform that you can use for all your modern .NET code)
.NET 5를 2020년 11월에 출시할 예정이고 첫 번째 Preview(베타 참여와 비슷한 개념입니다)는 2020년 상반기쯤에 사용할 수 있을 것입니다. 이는 추후에 업데이트를 통해 Visual Studio 2019, Visual Studio for Mac 그리고 Visual Studio Code 제품에서 지원될 예정입니다.
.NET 5 = .NET Core vNext
.NET 5는 .NET Core와 함께 한 걸음 나아간 것입니다. (.NET 5) 프로젝트는 .NET 을 향상시키기 위해 몇 가지 중요한 방법을 중점으로 두고 있습니다.
어디서든 사용될 수 있으며동일한 런타임 환경, 개발자 경험을 제공하는 단일 .NET 런타임 / 프레임워크 생산 (uniform runtime behaviors, 프로그램을 실행했을 때 항상 동일한 동작을 하는 것을 말하는 것 같습니다. 이 부분은 저도 확실하지 않아 알려주시면 적극 반영하겠습니다.)
.NET의 기능을 확장하기 위해 .NET Core, .NET Framework, Xamarin 그리고 Mono의 장점을 채용
Build that product out of a single codebase that developers (ms) can work on and expand together and that improves all scenarios.
이 새로운 프로젝트와 방향성은 .NET 그리고 .NET 5에 어마어마한 변화를 가져올 줄 것입니다.
여러분의 코드와 프로젝트 파일은 여러분들이 어떤 종류의 앱을 개발하던지간에 동일하게 있을거예요!(your code and project files will look and feel the same no matter which type of app you're building. 여기서 말하는 앱이란 모바일 애플리케이션을 말하는 것이 아닌, WPF/Windows Forms/ASP 등 어떤 형태로 빌드를 해도 동일한 환경을제공한다는 의미로 쓰인 것 같습니다)
또한 각 앱마다 동일한 런타임, API 및 언어 기능에 접근할 수 있습니다.이는 거의 매일 CoreFX에 커밋되는 수정사항으로 인해 새로운 성능 향상을 포함할 것입니다. (This includes new performance improvements that get committed to corefx, practically daily.)
여러분들이 사랑했던 .NET Core의 기능이나 특징들은 계속 이어나갈 것입니다.
오픈 소스 및 커뮤니티 중심적 (GitHub)
크로스 플랫폼 구현
플랫폼 종속적인 기능(대표적인 예로 Windows Forms나 WPF, 자마린을 이용한 네이티브 플랫폼 바인딩) 활용
높은 성능
Side-by-side 설치
작은 프로젝트 파일 (SDK 스타일이라는데.. 뭐가 SDK 스타일이라는건지)
짱짱좋은 CLI
Visual Studio, Visual Studio for Mac 그리고 Visual Studio Code 제품간의 통합
그리고 새로 추가되는 것들입니다.
런타임 경험에 대해 다양한 선택을 할 수 있습니다. (밑에 더 나와있음)
자바 Interop 기능은 모든 플랫폼에서 사용할 수 있을 예정입니다. (Interop 이란 상호 운용성을 말하는데, 쉽게 말해서 .NET에서 자바 코드를 사용할 수 있게 된다는 얘기입니다)
Objective-C 그리고 Swift Interop 기능은 다양한 운영체제에서 지원될 예정입니다. (맥에 한정되지는 않을 것 같습니다. 원문에서도 on multiple operating systems 라고 나와있습니다)
CoreFX에서 .NET의 정적 컴파일(AOT)을 지원하도록 확장하고, 더 작은 파일 크기와 다양한 운영체제에서 지원되도록 할 예정입니다.
.NET Schedule
.NET 개발 및 배포 계획
(글 맨 앞에서 설명드린 내용입니다) 우리는 .NET 프레임워크(4.x 버전을 긴 시간 사용해왔기 때문)를 주로 사용하던 사용자들이 .NET Framework 4.x 버전과 헷갈릴 수 있고 또 .NET 5가 .NET 플랫폼의 새로운 미래라는 것을 확실하게 전하고 싶었기 때문에 버전 4를 건너뛰도록 결정했습니다.
또한 단순한 이름을 사용하기 위한 기회를 잡았습니다. 우리는 "만약, 하나의 .NET만 개발된다면 'Core'를 명확하게 붙일 필요가 없지 않을까?" 라고 생각했습니다. 짧은 이름은 단순화 뿐만 아니라 .NET 5가 동일한 기능과 행동을 가진다는 것을 전달하기 위함입니다. 만약, ".NET Core"라고 부르는 것을 선호하신다면 그렇게 부르시면 됩니다.
Runtime experiences
Mono는 크로스플랫폼으로 구현된 최초의 .NET입니다. 이 프로젝트는 오픈소스로 시작하였고, .NET Framework의 대체제로 사용되었습니다. 그리고 모바일 기기가 대중화됨에 따라 모바일 기기도 지원하도록 변화하였습니다. Mono는 Xamarin의 런타임으로 사용되고 있습니다.
CoreCLR은 .NET Core의 런타임으로 사용되고 있습니다. .NET Core의 주 대상은 클라우드 애플리케이션(Microsoft에서 운영 중인 거대한 스케일의 서비스도 포함)을 지원하는 것이였지만 이제는 Windows Desktop, IoT 그리고 Machine Learning 애플리케이션에서도 사용되고 있습니다.
종합해보면 .NET Core하고 Mono 런타임은 상당히 많은 공통점(둘 다 .NET 런타임이니까요)을 가지고 있지만, 또 가치있는 고유의 기능들이 있습니다. 이는 사용자가 원하는 런타임 경험을 고를 수 있도록 해줄거예요. CoreCLR과 Mono의 성능을 다른 것보다 향상시키는 작업을 하는 중입니다. 우리는 이것을 간단하게 만들 예정입니다. 예를 들자면 빌드 스위치를 만들어 사용자가 다른 런타임 옵션을 설정할 수 있도록 하는 것 처럼요.
이후에 소개되는 주제에서는 .NET 5 계획에 있어 중요하다고 생각되는 것들을 설명할 것이고, 이는 우리가 어떻게 두 런타임(Mono와 CoreCLR을 말하는 것 같습니다)을 개별적으로 그리고 또한 같이 발전시킬 것인지 확실하게 보여줄 것입니다.
High throughput and high productivity
처음부터 .NET은 중간 언어(IL)를 머신에 최적화된 코드로 해석하기 위해 Just-in-Time (JIT) 컴파일러를 의지해왔습니다.이후 우리는 아주 높은 처리량을 갖는 JIT 기반의 관리되는 런타임을 만들었습니다. 그리고 프로그래밍을 빠르고 쉽게 하기 위해 개발자 경험 또한 활성화했습니다. (Since that time, we've built an industry-leading JIT-based managed runtime that is capable of very high throughput and also enabled developer experiences that make programming fast and easy.)
JIT는 오래 지속되는 클라우드 및 클라이언트 시나리오에 적합합니다. JIT는 특정 머신 설정을 대상으로 한 코드를 생성(특정 CPU 명령 포함)할 수 있습니다. 또한, 런타임에 메서드를 재생성하는 것이 가능합니다.JIT를 빠르게 하기 위해 자주 사용되는 메서드일 경우 정밀하게 최적화된 코드를 생성하는 옵션을 추가했습니다. (a technique used to JIT quickly while still having the option to produce a highly-tuned version of the code if this becomes a frequently used method.)
ASP.NET Core를 TechEmpower의 프레임워크 벤치마킹에서 더 빠르게 동작하도록 하기 위한 노력은 JIT의 성능과 CoreCLR에 대한 투자를 보여주는 좋은 예입니다.컨테이너를 위한 .NET Core를 더 강력하게 하는 우리의 노력은 제약된 환경에서 런타임의 기능을 동적으로 적응하는 것으로 보여주고 있습니다. (Our efforts to harden .NET Core for containers also demonstrates that runtime's ability to dynamically adapt to constrained environments.)
* TechEmpower Framework benchmark: 웹 프레임워크의 성능을 벤치마킹하는 것으로,이 곳에서 웹 프레임워크의 성능 순위를 보실 수 있습니다.
개발자 도구는JIT 기능의 동작을 보기에 아주 좋은 예제입니다. (another good example where JIT shines) dotnet watch 또는 edit and continue (편집하며 계속하기,디버깅 중에 코드를 변경하고 변경된 코드를 프로그램의 재시작 없이 그대로 반영하는 것)기능을 예로 들 수 있습니다.도구는 단일 프로세스에서 재시작을 하지 않고 빠르게 수행해야할 때 컴파일과 코드를 여러 번 불러오는 것을 자주 요구합니다. (Tools often require compiling and loading code multiple times in a single process without restarting and need to be do it very quickly.)
JIT을 주로 사용해오던 .NET Core 또는 .NET Framework 개발자 분들께서는 이 경험이 친숙할 것으로 보입니다.
기본적으로 .NET 5 작업의 경우 JIT 기반의 CoreCLR 런타임을 사용하게 됩니다. 다만, 두 가지 예외가 있는데 하나는 iOS이고 다른 하나는 클라이언트측의 Blazor (WebAssembly) 입니다. 둘 다 ahead-of-time (AOT) 컴파일을 필요로 하기 때문입니다.
Fast startup, low footprint, and lower memory usage
Mono 프로젝트는 모바일 및 게임 콘솔(Xbox, PlayStation 등)을 중점으로 많은 // 중요한 기능과 결과는 그 프로젝트는 .NET 기반의 AOT 컴파일러와 최신 LLVM 프로젝트입니다. // Mono의 AOT 컴파일러는 C++처럼 .NET 코드가 머신에서 실행될 수 있는 단일 네이티브 코드를 // AOT / 작은 공간에서도 효율적으로 실행될 수 있으며, 시작할 때 필요하다면 처리량을 줄이거나 늘리기도 합니다.
Blazor 프로젝트는 이미 Mono의 AOT를 사용하고 있습니다. 이 프로젝트는 .NET 5으로 변환한 첫 번째 프로젝트입니다.우리는 우리의 계획을 증명하기 위한 방법으로 Blazor를 사용하고 있습니다. (We are using it as one of the scenarios to prove out this plan.)
두 가지 형태의 AOT가 있습니다. (There are two types of AOT solutions. / solutions를 따로 해석하지 않았습니다)
100% AOT 컴파일을 필요로 하는 것
대부분의 코드가 AOT로 컴파일 되었으나, JIT 또는 인터프리터가 사용 가능하고 또, 코드 패턴이 AOT와는 어울리지 않는 경우 (제네릭같은 것)
Mono AOT는 두 가지 형태 모두 지원합니다. 첫 번째 형태의 AOT인 경우는 보안상의 문제로 인해 애플의 iOS와 몇 가지 게임 콘솔에서 필요로 합니다. 두 번째는 AOT의 장점을 제공하면서도, 단점은 하나도 없이 사용할 수 있으므로 선호되는 방법입니다.
.NET Native는 우리가 Windows UWP 대상 애플리케이션을 만들 때 사용하는 AOT 컴파일러입니다. 그리고 위에서 나열한 AOT 첫 번째 형태의 예입니다. 특정 구현으로, 우리는 사용할 수 있는 .NET API와 기능을 제한했습니다. 우리는 이 경험을 통해 AOT는 모든 .NET API와 패턴을 커버해야 한다는 것을 배웠습니다. (.NET Native is the AOT compiler we use for Windows UWP applications and is an example of the first type of AOT listed above. With that particular implementation, we limited the .NET APIs and capabilities that you can use. We learned from that experience that AOT solutions need to cover the full spectrum of .NET APIs and patterns.)
AOT 컴파일은 iOS나 WebAssembly 및 몇몇 게임 콘솔의 요구로 없어지진 않을거예요.AOT 컴파일은 빠른 시작과 낮은 크기를 요구하는 애플리케이션을 위한 옵션으로 만들어질 예정입니다. (We will make AOT compilation an option for applications that are more appliance-like, that require fast startup and/or low footprint. appliance-like는 제외했습니다. 네이버 백과사전에서 찾은의미인데, 도통 이해가 안가네요..)
Fundamentals and overlapping experiences
시작 시간, 처리량, 메모리 사용량, 안정성과 진단 기능을 갖춘 전체 플랫폼으로 나아가는 것이 중요합니다. 이와 동시에 우리의 노력을 여기에 집중하는 것도 말이 되구요. 우리는 CoreCLR의 처리량과 안정성에 더 많은 투자를 하는 한편, Mono AOT 컴파일러에도 시작 속도와 크기 감소에 더 많은 투자를 할 것입니다. 이러한 것들은 좋은 결합이라고 생각합니다. 그리고, 시작 속도와 크기 감소는 처리량과 안정성과 비례합니다. (It is critical that we continue to move forward as an overall platform with startup, throughput, memory use, reliability, and diagnostics. At the same time, it also makes sense to focus our efforts. We’ll invest more in throughput and reliability in CoreCLR while we invest more in startup and size reduction with the Mono AOT compiler. We think that these are good pairings. Throughput and reliability go together as do startup and size reduction.)
다른 투자를 하는 것이더 나은 경우도 있지만, 그렇지 않은 경우도 있습니다. (there are some characteristics where it makes sense to make different investments)
진단 기능은 기능과 성능 진단을 위해 .NET 5에서 동일할 필요가 있습니다. 또한, 이는 같은 칩과 운영체제를 지원하기 위해서도 매우 중요합니다. (단, iOS와 Web Assembly는 예외입니다) (Diagnostics capabilities need to be the same across .NET 5, for both functional and performance diagnostics.)
우리는 각 작업과 시나리오에 대한 .NET 5 최적화를 계속 수행할 것입니다. 특히, 여러 작업이 중복되는 경우에는 최적화에 더 중점을 둘 것입니다.
모든 .NET 5 애플리케이션에서는 CoreFX를 사용하게 됩니다. 우리는 CoreFX가 자주 사용되지 않는 곳(주로, Xamarin이나 클라이언트측 Blazor 작업에서)에서도 제대로 동작하도록 보장할 것입니다.
모든 .NET 5 애플리케이션은공용 명령줄 도구가 있는 경우, .NET CLI를 사용하여 빌드할 수 있을 것입니다. (ensuring that you have common command-line tooling across projects. )
C#은 이제 .NET 5와 함께 발전할 것입니다. .NET 5 앱을 작성하는 개발자는 항상 최신 버전의 C# 그리고 그 기능에 접근할 수 있을 것입니다. (이렇게 되면 C# 언어의 버전을 선택하는 과정이 없어질 것 같네요)
The birth of the project
2018년 12월에 보스턴에서 기술 팀을 만나 이 프로젝트를 시작했습니다. .NET 팀(Mono/Xamarin/.NET Core)과 유니티의 디자인 리더는다양한 기술적 기능과 구조적 방향을 제시해줬습니다. (presented on various technical capabilities and architectural direction. / presented 를 발표하다로 해석했습니다.)
이제 우리는이 프로젝트를 마치 제품의 묶음처럼 단일 팀으로 진행하고 있습니다. 12월 이후 우리는 몇몇 프로젝트에 많은 진전을 이뤄냈습니다. (moving forward on this project as a single team with one set of deliverables.)
런타임 <-> 관리되는 코드 레이어 / 99% 의 CoreFX 코드??? 뭐라는건지..
MonoVM에서 CoreFX와 그 클래스 라이브러리들을 사용할 수 있음
MonoVM에서 CoreFX의 구현을 이용하여 CoreFX의 모든 테스트를 실행할 수 있음
MonoVM을 이용하여 ASP.NET Core 3.0 애플리케이션을 실행할 수 있음
MonoDevelop/Visual Studio for Mac을 CoreCLR으로 실행할 수 있음
단일 .NET으로 구현하는 것은 중요한 의문을 가지게 합니다. 과연 대상 프레임워크는 어떤 것이 되는지? NuGet 패키지의 호환성 규칙은 이전과 동일할 것인지?어떤 작업들이 설치 없이 .NET 5 SDK로 지원될 것인지? 특정 아키텍쳐를 대상으로 한 코드는 어떻게 작성할 것인지? .NET Standard가 여전히 필요할 것인지? 우리는 이러한 이슈들을 인지하고 작업하고 있으며, 조만간 디자인 문서를 공유하고 여러분께서 읽으신 후 피드백을 저희에게 주실 수 있도록 할 것입니다. (Which workloads should be supported out-of-the-box by the .NET 5 SDK?)
Closing
.NET 5 프로젝트는 중요하고 기대되는 .NET의 새 방향입니다. .NET이 더 간단해지지만 넓고 더 확장성있는 기능과 유용성을 갖는 것을 보실 수 있을겁니다. 새로운 C# 버전을 포함하여 새로운 개발 및 기능은 .NET 5의 일부가 될 것입니다. (The .NET 5 project is an important and exciting new direction for .NET. You will see .NET become simpler but also have broader and more expansive capability and utility. All new development and feature capabilities will be part of .NET 5, including new C# versions.)
우리는 대상 애플리케이션 형식이나 운영체제, 칩 아키텍쳐에 상관 없이 동일한 .NET API와 언어를 사용할 수 있는 밝은 미래를 보았습니다. 이는 Visual Studio나 Visual Studio for Mac, Visual Studio Code, Azure DevOps 또는 명령줄 인수를 이용하여 빌드 구성을 바꾸고 다른 애플리케이션을 빌드하는 것을 더 쉽게 만들어 줄 것입니다. (We see bright future ahead in which you can use the same .NET APIs and languages to target a broad range of application types, operating systems, and chip architectures. It will be easy to make changes to your build configuration to build your applications differently, in Visual Studio, Visual Studio for Mac, Visual Studio Code, Azure DevOps or at the command line. / 어떤 IDE나 편집 도구를 사용해도 설정이 쉬워지겠다는 얘기 같습니다.)
상당히 오랜 시간에 걸쳐 번역 작업을 마무리 했습니다. 모자란 영어 실력을 가지고 번역을 해서 죄송할 따름이지만, 번역하면서 느낀 가장 큰 키워드는 ".NET 플랫폼의 통합" 같습니다. 닷넷 코어나 프레임워크, 자마린 등 나뉘어 있던 플랫폼이 .NET 5 하나로 통합되면서 편리함을 챙기면서도 성능 면에서도 많은 발전이 있다고 하니, 정말로 기대가 되네요.
보시다시피 .NET 5.0은 3.1.x 이후의 .NET Core의 다음 주요 버전입니다.설치 및 사용 방법을 살펴 보겠습니다.
1 단계-Visual Studio 2019 V16.6 Preview 1 다운로드
.NET 5.0을 설치하기 전에 Visual Studio 2019 V16.6 이상이 설치되어 있는지 확인하십시오.현재이 기사를 작성할 당시 Visual Studio 2019의 최신 공식 버전은 V16.5입니다.지금은이 버전에서 .NET 5.0을 사용할 수 없지만 아래링크에서 다운로드 할 수있는 Visual Studio의 미리보기 버전을 사용할 수 있습니다.
우리는 어떤 판을 선택할 수 있습니다.현재 내 컴퓨터에 Community Edition이 이미 설치되어 있기 때문에 Community Edition 데모를 보여주고 있습니다.
2 단계-.NET 5 Preview SDK 설치
Visual Studio 2019 V16.6의 Preview 버전을 설치 한 후 .NET 5.0 Preview 1 SDK를 다운로드하여 설치해야하며 다음링크에서 다운로드 할 수 있습니다.
운영 체제에 따라 적절한 SDK를 선택할 수 있습니다.지금은 Windows 10 64 비트에서 사용하고 있습니다.아래 스크린 샷과 같이“Windows x64”링크에서 다운로드했습니다.다운로드 링크가 여러 개 있으며 요구 사항에 따라 선택할 수 있습니다.
다운로드가 완료되면 설치 가능한 파일을 실행하고 화면의 지시에 따라 설치하십시오.
3 단계-Visual Studio 2019를 사용하여 .NET 5.0 응용 프로그램 만들기
Visual Studio 2019 미리보기 열기
“새 프로젝트 만들기”를 클릭하십시오.
“ASP.NET Core Web Application”을 선택하십시오
새 프로젝트 구성
프로젝트 이름 :“FirstDotNet5App”
“만들기”버튼을 클릭하십시오.
드롭 다운 목록에서 .NET Core 버전을 선택하십시오.
.NET 5 웹 응용 프로그램 설정
프레임 워크 :“.NET Core”
프레임 워크 버전“ASP.NET Core 5.0”
응용 프로그램 유형 :“웹 응용 프로그램”.
“HTTPS 구성”: 지금 선택 해제하십시오
Razor 런타임 컴파일 사용 : 선택하지 않은 상태로 두십시오
그런 다음 "Create (만들기)"버튼을 클릭하여 프로젝트를 만듭니다.
다음은 새로 만든 응용 프로그램에 대한 Visual Studio의 스크린 샷입니다.
4 단계-응용 프로그램 실행
지금까지 .NET Core 5.0을 대상으로 프로젝트가 성공적으로 생성 된 것을 확인했습니다.출력을보기 위해 응용 프로그램을 실행 해 봅시다.
결론
마지막으로 첫 번째 .NET 5.0 응용 프로그램을 만들었습니다..NET 5.0 Preview 1에서는 큰 변화가 없으며 모든 것이 .NET Core 3.1.x와 거의 유사합니다.그러나 향후 .NET 5 릴리스에서는 중요한 변경 사항이 예상됩니다.
