.NET Standard 2.0 관전 포인트

올 가을 .NET Standard 2.0이 출시된다.
이번 업데이트에서는 .NET Framework에서 꿀빨던 많은 API들을 최대한 수용하여 .NET Core로 이식 가능성을 중점으로 삼았다.
또한, Mono와 Unity 접근성을 최대한 확보하여 Mono에서 .NET Core 로 이동하여 통합 개발이 가능하도록 유도하였다.
그렇다면 대체 .NET Standard 2.0 에서 주의깊게 봐야 할 요소는 무엇이 있을 지, 알아보도록 하겠다.

1. .NET Framework와 .NET Core 간 상호작용

NETStandard20Libraries.png
출처: .NET Standard 2.0 – Making Sense of .NET Again

닷넷코어는 최신 표준인 1.6조차 .NET Framework 에서 .NET Core로 옮기는 데 부족한 API로 많은 어려움이 있었고,
게다가 Reflection API의 상당한 변경, AppDomain API 부재로 이를 사용한 라이브러리 이식에 많은 어려움이 있었다.
이번에 2.0의 메인 변경점이 바로 .NET Framework와 호환 가능한 API가 대거 추가된다는 점이다.
하지만 AppDomain 은 잘 쓰지 않는다. 이 글을 보고 있는 당신도 왜 AppDomain을 쓰는지 잘 모를 수 있을 것이다.
주로 플러그인 동적 로드 용도(라이브러리 동적 로드)로 쓰는데, .NET Core에서는 굳이 없어도 동적 라이브러리 로드 및 관리에 지장이 없다.
물론 .NET Core 에 API는 있지만 뭔 짓을 해도 PlatformNotSupportedException 예외가 나올 것이다.
어찌저찌 얘기해도 결론적으론 필요성이 전무하다는 거다. 이는 공식 FAQ에 나와 있다.
뱀발로, 기본적으로 닷넷 앱을 실행하면 자동적으로 1개의 AppDoamin 안에서 실행된다. 그리고 닷넷코어는 1개만 쓰도록 강제한다고 생각하면 된다.
어쨌든, 이런 아주 특이한 케이스를 제외하고는 최대한의 호환성 확보로 .NET Framework 와 .NET Core 간 호환에 지장이 없도록 했다는 것이 포인트.
그럼 이식 가능한 라이브러리(Portable Class Library)는 어떻게 되냐고? 일단은 살아있다. 일종의 플랫폼 간 다리로. 아직 이렇다 할 사안은 공식적으로 없다. 쓰고 싶은 사람은 쓰도록.
아무래도 한국 닷넷 개발자가 .NET Core로 이식한다면, 가장 맨붕 올 주는 부분이 바로 System.Data의 부족함일 것이다.
일단 추상 클래스는 원래대로 제공하되, ODBC 같은 특정 플랫폼용 API는 제공할 계획이 없다고 하니 이 점을 유의하면 되고,
특히 MSSQL 연동 시 .NET Framework에서는 아예 기본 제공이었던 점과는 달리 따로 분리되어 따로 불러와야 한다는 점만 주의하면 되겠다.
WCF나 WPF같은 경우 애초부터 윈도우 종속이기 때문에 절대 기대는 하지 말자. 다시말해, 닷넷 자체 플랫폼 종속 기능과, Remoting 기능을 기대하지 말라는 거다.
(단, XAML 자체는 독립 플랫폼 표준이 생겼기 때문에 플랫폼별로 Xamarin 등으로 새로 만들어야 하는 거 빼면 스펙 문제는 없다.)
이런 몇가지 예외 사항을 제외하면 대부분이 이식 가능하도록 배려했다고 한다.

2. .csproj 부활

앞서 닷넷코어 팀이 1.0 Preview에 예고한 것처럼, project.json 방식에서 다시 .csproj 방식으로 돌아온다.
.csproj 방식은 XML 으로 관리하는 방식인데, 닷넷 팀도 기존에 강력한 프로젝트 관리 형식을 버린다는 건 낭비라고 판단한 듯 하다.
분명 JSON 방식은 사람이 읽기가 쉽고 간결하며, 프로젝트 관리에 지장은 크게 없었지만, 닷넷의 모든 것을 수용하기엔 해결해야 할 과제가 많았기에 돌아온 것으로 보면 된다.
그래서 .NET Framework 에서 .NET Core로 이식하거나 그 반대로 마이그레이션 하는 접근성을 한층 더 높여줬다고 보면 된다.

3. 뭐야? 이게 다야?

그렇다. 이게 다다. 공식적으로 닷넷 2.0 최종 버전의 소개는 이게 다다.
뭘 더 바랬는지 모르겠지만, .NET Standard 는 스펙이다. 구현체는 .NET Framework 와 .NET Core다.
스펙에서는 플랫폼 간 이식에 중점삼아 스펙을 구성하여 이걸 .NET Framework 와 .NET Core 으로 구현한 것이다. 이게 다다.
C# 표준도 향상된다. 하지만 이는 .NET Standard와는 상관이 없다. C#은 언어 스펙이기 때문이다. 당연히 최신 언어 스펙을 .NET Standard 1.x 사용하는데 크게 지장이 없다.
.NET Framework 4.5 부터는 언어 스펙이 올라가도 사용하는 데 지장이 없다는 걸 C# 6.0에서 보여주었다. 그렇기에 따로 봐야 할 문제다.
물론 가능하면 새로운 앱을 만들거나 마이그레이션을 해야할 경우가 생기면 .NET Standard 최신 버전을 따르는 게 유리할 수밖에 없다. 1.x 는 API 텀이 너무 많기 때문이다.

글 쓴 나도 허무하다. 하지만 이번 업데이트 만큼은 기대해도 좋다. 왜냐면 닷넷 그대로 덜 만져서 탈윈도우 플랫폼을 꾀할 수 있는 기회가 되기 때문이다.
지금 당장 테스트하고 싶으면 .NET Core 2.0 Preview를 설치하면 된다. 거기서 크게 달라질 거 없다고 한다.
이 글을 쓰고 4일 뒤 정식 버전으로 나왔다. .NET Core 2.0 링크 가서 다운받고 설치하면 된다. 아, 위 프리뷰 깔았던 사람은 구조는 비슷하기 때문에 걍 재설치하면 된다.
미안. 1주일 뒤에 지인을 통해 알아차렸다… 페북에서도 소식이 없다니 ㄷㄷ

여담으로, Standalone 프로젝트(사내용 앱 등)은 특정 플랫폼, 특정 API를 쓰는 경우가 많기 때문에 그 프로젝트 자체를 마이그레이션하려는 멍청한 짓은 하지 말자. 어자피 갈아 엎어야 한다.

composite / 2017년 8월 11일 / Piss Development

Comments

  1. 몬난아 - 2017년 8월 14일 @ 8:56 오전

    안녕하세요 ^^

    잘읽었습니다

    ” 닷넷 그대로 덜 만져서 탈윈도우 플랫폼을 꾀할 수 있는 기회가 되기 때문이다.”

    이문구는 “닷넷 그대로를 사용해서, 탈 윈도우 플랫폼을 꾀할 기회가 되기때문이다”

    로 이해하는게 맞나용? 저문장이 이상하게 이해가 안되서요 ㅎㅎ;

    그리고 기회라고 적으신건 탈윈도우가 답인건가요? ㅠㅠ 서버자체가 윈도우보단 리눅스가 많긴하지만 ㅠㅠ

    Reply
    • composite - 2017년 8월 14일 @ 1:26 오후

      어쩌면 오해를 불러 일으킬 수도 있는 구문일 수 있군요. 이 점에 대해 심심짭쪼름한 양해말씀 드리면서,

      탈윈도우라고 해서 기존 플랫폼을 벗어나라는 취지로 얘기한 건 아닙니다.

      이번 닷넷 표준 2.0은 기존 닷넷 플랫폼 간 호환성을 극대화한 게 주 이슈라

      기존 플랫폼에 벗어나지 못했던 설움을 더 쉽게 극복하여 윈도우 외에서도 최대한 비슷한 서비스를 꾀할 수 있기 때문에 그런 문구를 작성했습니다.

      탈윈도우가 답은 절대 아닙니다. 윈도우는 업계 입장에서는 여전히 유지보수비가 타

      플랫폼에 비해 덜 드는 운영체제입니다. 단지 초기비용이 비싸 맨날 SI랍시고 도입하는 업계 입장에서 비싸게 보일 뿐이죠.

      닷넷 그대로 탈 윈도우 플랫폼을 꾀할 기회라 이해하신 건 잘 이해하신 겁니다. 하지만 완전한 탈윈도우를 의미하는 건 아니기 때문에 오해 없으시길 바라겠습니다.

      Reply

답글 남기기

Your email address will not be published / Required fields are marked *