.net native compiler

나 같이 C# 으로 먹고사는 사람은 네이티브컴파일러 소식이 반갑다

https://msdn.microsoft.com/ko-kr/library/dn584397%28v=vs.110%29.aspx

https://msdn.microsoft.com/ko-kr/vstudio/dotnetnative

http://jacking.tistory.com/1295

아래는 네이티브 컴파일에 대한 FAQ

https://msdn.microsoft.com/ko-kr/vstudio/dn642499.aspx

Microsoft .NET 네이티브 FAQ

F# 또는 VB, 또는 자주 사용하는 언어가 지원됩니까?

이 체험판 릴리스는 C# 언어만을 지원합니다. 이는 C#이 스토어 앱에서 가장 많이 사용되는 언어이기 때문입니다. 하지만, 추후에는 모든 .NET 언어를 지원할 예정입니다

이것은 단지 성능에 관한 것입니까? 또는 Win32/64로 네이티브 컴파일된 C# 코드(예)를 구축할 수 있으며 대상 시스템에 .NET Framework를 설치할 필요가 없습니까?

정답입니다. .NET 네이티브는 단지 성능뿐만 아니라 생산성 및 일관된 장치 환경에 영향을 줍니다. .NET 네이티브는 관리되는 언어를 사용하여 코드를 작성하고 이전처럼 MSIL 패키지를 업로드할 수 있도록 지원합니다. 그렇지만, 앱은 (.NET 네이티브가 프로덕션 환경에 적용될 때) 자체포함된(Self-contained) 네이티브 컴파일 코드로 최종 사용자 장치에 배포되며, 대상 장치/시스템에서 .NET Framework에 대한 종속성을 갖지 않습니다. 아시다시피 .NET 응용 프로그램의 스펙트럼은 광범위합니다. 따라서 전체 .NET Framework에도 많은 투자를 하고 있습니다(예: RyuJIT의 CTP를 릴리스했습니다).

설계 시 어떤 시나리오를 고려했습니까?

염두에 둔 시나리오는 개발자가 .NET 및 MSIL 생산성 이점을 유지하고 MSIL 패키지를 스토어에 업로드하며 최종 사용자에게 최종 사용자 네이티브 코드(C++)와 같은 성능(Windows Phone 8과 유사하게, 클라우드에서 일어나는 컴파일을 통해)을 제공할 수 있는 장치용 스토어 앱이었습니다.

.NET 네이티브가 .NET Micro Framework를 교체하며 C#/.NET를 소형 장치에도 완전히 사용할 수 있게 됩니까?

.NET 네이티브는 현재 Windows 스토어 앱에 중점을 두고 있습니다. Micro Framework는 Windows Embedded 팀에서 제공하며 .NET 팀은 이들과 함께 고객에게 최상의 서비스를 제공하는 방법에 대해 협력하고 있습니다.

개발자 체험판을 Windows Phone 앱 및 라이브러리 제작에 사용할 수 있습니까?

.NET 네이티브를 활용하는 유니버셜 클래스 라이브러리를 제작할 수 있습니다. 이 체험판에서는 Windows 스토어 앱만 .NET 네이티브를 사용하여 제작할 수 있습니다. .NET 네이티브로 Windows Phone 앱을 개발하도록 하는 것은 현재 준비중에 있습니다.

C# 개발자에게 그래픽이 많은 앱 및/또는 게임 개발 시 더 나은 환경을 제공할 수 있습니까?

예. .NET 네이티브 컴파일러는 Microsoft C++ 최적화 프로그램과 코드 베이스의 일부를 공유합니다.

서버/데스크톱 앱은 .NET 네이티브 및/또는 클라우드의 컴파일러로부터 이점을 얻을 수 있습니까?

데스크톱 앱은 우리 전략에서 아주 중요한 부분입니다. 처음에는 .NET 네이티브를 통한 Windows 스토어 앱에 중점을 두었습니다. 장기적으로 모든 .NET 응용 프로그램의 네이티브 컴파일을 지속해서 개선해 나갈 것입니다.

링크는 어떻게 동작합니까? 프레임워크 코드는 응용 프로그램에서 컴파일됩니까? 패키지/바이너리 크기에도 영향을 미칩니까?

예, 프레임워크 코드는 응용 프로그램에서 컴파일됩니다. 대부분의 스토어 앱에서 수많은 멀티미디어가 있으므로, 패키지 크기에 있어 차이는 크지 않습니다.  결과적으로 코드 사이즈는 변경되지만, 해당 응용 프로그램에서 사용하는 프레임워크의 일부만 링크됩니다. 따라서 .NET 네이티브로 컴파일된 바이너리는 NGEN 바이너리와 동일한 범주에 속하게 됩니다.  크기 차이를 더 줄일 수 있는 전략에 여전히 투자하고 있습니다.

.NET 네이티브 컴파일은 MSIL을 통한 컴파일보다 더 느립니다. 이유는 무엇일까요?

일반적인 응용 프로그램 개발은 Visual Studio에서 표준 MSIL/JIT 개발 환경을 사용합니다. .NET 네이티브 컴파일러는 응용 프로그램이 장치에 배포될 때까지 호출되지 않으며, 대부분의 개발 프로세스를 마친 후 초점은 응용 프로그램 최적화로 전환됩니다. 이 점에서 컴파일 타임은 링크 타임 코드 생성으로 최적화된 C++과 유사합니다.

P/Invokes는 어떻게 됩니까? 표준 DLL 호출에 맞게 최적화되었습니까?

바이너리가 네이티브 컴파일되어 있다고 해도 관리되는 코드 유형 안전성(및 따라서 가비지 수집)과 전체 C# 예외 모델의 이점을 유지하고 있습니다. .NET 네이티브를 통해 interop 경로를 집중해서 최적화했으므로, P/Invokes가 표준 DLL 호출을 최적화하지 않으면서 GC 동기화 및 필요한 마샬링을 수행하기 위해 최소의 오버헤드가 발생합니다.

제한 사항은 무엇입니까? 오픈 제네릭 및 리플렉션을 지원합니까?

.NET 네이티브는 프로덕션 시작 시 대상 플랫폼에서 지원하는 모든 기능을 지원합니다. 많은 기능이 개발 진행 중인 체험판 릴리스이므로, 지금은 일부 제한 사항이 있습니다. 그렇긴 해도 오픈 제너릭 및 리플렉션이 모두 이 체험판 릴리스에서 지원됩니다(그것도 정적 컴파일을 통해서요!). 이 체험판 릴리스에서 컴파일러에는 런타임 시 제너릭 인스턴스화 및 메타데이터가 필요한 것을 파악하려고 하는 추론이 내장되어 있습니다. 따라서, 많은 수의 앱이 컴파일러의 이점을 위해 소스를 간소화하지 않고도 작동할 것으로 예상합니다.

이러한 앱을 어떻게 패치 또는 공급할 수 있습니까?

앱용 서비스 모드는 계속 동일하게 유지됩니다. 프레임워크의 경우 .NET의 현재 모델은 라이브러리 업데이트가 자동으로 제공되는 것입니다. 계속해서 다른 방안도 검토하고 있으며, 여러분의 제안과 의견도 귀 기울여 듣겠습니다.

사용하지 않은 메소드를 제거할 경우 직접 결코 호출되지 않는 경우에도 메소드(또는 전체 클래스)가 사용된다고 말할 수 있는 방법이 있습니까?

예, 이 체험판에서는 직접 호출되지 않는 경우에도 메소드(또는 형식)가 사용된다고 개발자가 말할 수 있도록 지원하고 있습니다(런타임 지시문 설명서 참조).