| Microsoft .NET | |
| | |
| <colbgcolor=#fff,#1f2023><colcolor=#512BD4> 종류 | 프레임워크 |
| 라이선스 | MIT 라이선스 |
| 지원 언어 | C#. Visual Basic .NET, C++, DLR, F#, Q#, Delphi.NET |
| | |
1. 개요2. 지원 플랫폼3. 버전4. .NET Framework5. .NET Core6. .NET Standard
6.1. .NET Standard로 개발된 라이브러리
7. .NET Native AOT8. Xamarin8.1. Xamarin.Android8.2. Xamarin.iOS8.3. Xamarin.Mac8.4. Xamarin.Forms8.5. Xamarin Test Cloud8.6. Xamarin Insights8.7. Xamarin.Essentials
9. MonoDevelop10. 사건/사고10.1. .NET 6.0 핫 리로드 기능 (dotnet watch) 삭제 사건
11. 기타12. 외부 링크[clearfix]
1. 개요
공식 홈페이지마이크로소프트에서 개발한 Windows 프로그램 개발 및 실행 환경(프레임워크). 원래는 클로즈드 소스로 개발되던 프레임워크였으나 현재는 닷넷 재단이 관리하는 오픈 소스 프로젝트이며 이와는 별도로 오픈 소스화 이전부터 오픈 소스 프로젝트 MONO 또한 있다.
버전 간 상하위 호환성이 없는 것은 아니나 상하위 호환성을 보장할지, 그 범위는 어떻게 할지는 개발자의 선택에 맡긴다. 상하위 호환성의 범위가 클수록 개발 범위가 커지기 때문에 단일 버전만 필요로 하는 경우도 많다. 때문에 상하위 호환성을 지니지 못해 버전별로 전부 설치해야 하는[1] 불상사가 생기기도 한다.
2. 지원 플랫폼
.NET이 오픈 소스가 된 이후로 거의 대부분의 데스크톱 플랫폼에서 .NET을 지원한다. 아래는 .NET 8 기준으로 SDK 설치가 가능한 플랫폼이다.- Windows: Windows 10 22H2 이상.
- macOS: 12 몬터레이 이후 모든 버전.[2]
- 리눅스: 배포판마다 지원 버전이 다르다. 아래 리스트는 .NET 8을 지원하는 최신 버전을 기준으로 한다. 지원 버전을 기준으로 x64 플랫폼에서는 AP 등의 패키지 매니저에서 바로 설치할 수 있다.
3. 버전
| Microsoft .NET | ||||||||||||||||||
| {{{#!folding .NET Framework [ 펼치기 · 접기 ] | 버전 | CLR 버전 | 출시 날짜 | 이 버전과 같이 나온 Visual Studio 버전 | 설치된 Windows 버전 | 지원하는 Windows | ||||||||||||
| 클라이언트 | 서버 | |||||||||||||||||
| 프리 베타 | - | 2000년 7월 11일 | - | - | - | - | ||||||||||||
| 1.0 베타 1 | - | 2000년 11월 | - | - | - | - | ||||||||||||
| 1.0 베타 2 | - | 2001년 6월 20일 | - | - | - | - | ||||||||||||
| 1.0 | 1.0 | 2002년 2월 13일 | .NET 2002 | XP SP1 (MCE, TPCE 한정)[4] | - | 98 ~ Me NT 4.0 SP6a ~ XP 2000 Server | ||||||||||||
| 1.1 | 1.1 | 2003년 4월 24일 | .NET 2003 | -[5] | 2003 | 98 ~ Me NT 4.0 SP6a ~ Vista 2000 Server ~ 2008[6] | ||||||||||||
| 2.0 | 2.0 | 2005년 11월 7일 | 2005 | - | 2003 R2 | 98 ~ Me[7] 2000 SP3[8], XP SP2 2000 Server SP3 ~ 2003 R2 | ||||||||||||
| 3.0 | 2.0 | 2006년 11월 6일 | - | Vista | 2008 | XP SP2, Vista 2003 SP1 ~ 2008 | ||||||||||||
| 3.5 | 2.0 | 2007년 11월 19일 | 2008 | 7 | 2008 R2 | XP SP2 이상의 모든 윈도우[9] | ||||||||||||
| 4.0 | 4.0[10] | 2010년 4월 12일 | 2010 | - | - | XP SP3 ~ 7 2003 SP2 ~ 2008 R2 | ||||||||||||
| 4.5 | 4.0 | 2012년 8월 15일 | 2012 | 8 | 2012 | Vista SP2 ~ 8 2008 SP2 ~ 2012 | ||||||||||||
| 4.5.1 | 4.0 | 2013년 10월 17일 | 2013 | 8.1 | 2012 R2 | Vista SP2 ~ 8.1 2008 SP2 ~ 2012 R2 | ||||||||||||
| 4.5.2 | 4.0 | 2014년 5월 5일 | - | - | - | Vista SP2 ~ 8.1 2008 SP2 ~ 2012 R2 | ||||||||||||
| 4.6 | 4.0 | 2015년 7월 20일 | 2015 | 10 v1507 | - | Vista SP2 ~ 10 v1507 2008 SP2 ~ 2012 R2 | ||||||||||||
| 4.6.1 | 4.0 | 2015년 11월 12일 | 2015 업데이트 1 | 10 v1511 | - | 7 SP1 ~ 10 v1511 2008 R2 SP1 ~ 2012 R2 | ||||||||||||
| 4.6.2 | 4.0 | 2016년 8월 2일 | 2017 v15.0 | 10 v1607 | 2016 TP5 (빌드 넘버 14300) | 7 SP1 ~ 10 v1607 2008 R2 ~ 2012 R2 | ||||||||||||
| 4.7 | 4.0 | 2017년 4월 5일 | 2017 v15.1 | 10 v1703 | - | 7 SP1 ~ 10 v1703 2008 R2 SP1 ~ 2016 | ||||||||||||
| 4.7.1 | 4.0 | 2017년 10월 17일 | 2017 v15.5 | 10 v1709 | 2016 v1709 | 7 SP1 ~ 10 v1709 2008 R2 SP1 ~ 2016 v1709 | ||||||||||||
| 4.7.2 | 4.0 | 2018년 4월 30일 | 2017 v15.8 | 10 v1803 | 2019 (빌드 넘버 17666) | 7 SP1 ~ 10 v1803 2008 R2 SP1 ~ 2019 | ||||||||||||
| 4.8 | 4.0 | 2019년 4월 18일 | 2019 v16.0 | 10 v1903 | 2022 | 7 SP1 ~ 11 v21H2 2008 R2 SP1 ~ 2022 | ||||||||||||
| 4.8.1 | 4.0 | 2022년 8월 9일 | 2022 v17.3 | 11 v22H2 | - | 10 v20H2 ~ 11 v22H2 2022 | ||||||||||||
| {{{#!folding .NET Core [ 펼치기 · 접기 ] | 버전 | 출시일 | 지원 종료일 | |||||||||||
| 1.0 | 2016년 06월 27일 | 2019년 06월 27일 | ||||||||||||
| 1.1 | 2016년 11월 16일 | |||||||||||||
| 2.0 | 2017년 08월 14일 | 2018년 10월 01일 | ||||||||||||
| 2.1 | 2018년 05월 30일 | 2021년 08월 21일 | ||||||||||||
| 2.2 | 2018년 12월 04일 | 2019년 12월 23일 | ||||||||||||
| 3.0 | 2019년 09월 23일 | 2020년 03월 03일 | ||||||||||||
| 3.1 | 2019년 12월 03일 | 2022년 12월 03일 | ||||||||||||
| 버전 | 출시일 |
| 5.0 | 2020년 11월 10일 |
| 6.0 | 2021년 11월 8일 |
| 7.0 | 2022년 11월 8일 |
| 8.0 | 2023년 11월 15일 |
| 9.0 | 2024년 11월 12일 |
.NET 5부터 매년 11월마다 출시하는 릴리스 주기가 정해져 있다. 또한, 홀수 버전은 표준 기간 지원(STS), 짝수 버전은 LTS가 적용된다.
3.1. 5
.NET 5.0은 마이크로소프트가 빌드 2019 컨퍼런스에서 처음 발표하고 2020년 11월에 출시한 버전이다.새로운 .NET 5는 .NET Core, Xamarin 등이 하나로 합쳐진 버전으로 여러 운영 체제 프로그램 개발이 가능하다. 하지만 .NET Framework는 더 이상 출시되지 않으며 .NET Core는 .NET Framework의 새로운 크로스플랫폼 버전이므로 .NET 5와 .NET Framework는 출발 지점이 다르다고 볼 수 있다.
이 버전부터 C# 9.0를 사용한다.
다운로드
2022년 5월 10일에 지원이 종료되었다. #
3.2. 6
.NET 5를 공개한 지 몇 달 만에 MS에서 새로운 메이저 업데이트를 또 공개하였다. # # #한국시각 2021년 11월 9일 출시하여 지금 확인 가능하다.
C# 10.0 및 F# 5.0을 지원한다.
핫 리로딩 기능이 유지된다. 상세한 설명은 사건/사고 문단 참조.
이 메이저 업데이트는 특히 M1 등 ARM 프로세서 네이티브 지원에 중점이 맞춰져 있어 자바 17처럼 최신 메이저 운영 체제를 지원하는 프레임워크가 되었다.
새로운 크로스 플랫폼 UI 라이브러리인 .NET MAUI를 지원한다. 윈도우뿐 아니라 여러 플랫폼[11]에서 사용할 수 있다. 다만 완성도는 아직 떨어지는 편이다.
.NET 5 대비 비약적인 성능 향상이 이루어졌다.#
다운로드
3.3. 7
한국 시간으로 2022년 11월 9일 출시됐다.# 이 버전에서 C# 11 및 F# 7을 지원한다..NET Native AOT 기능이 도입되면서 성능이 향샹되었다. 다만 윈도우, 리눅스의 x64, ARM64 프로젝트만 지원한다.
다운로드
2024년 5월 14일에 지원이 종료되었다.
3.4. 8
한국 시간으로 2023년 2월 21일에 프리뷰로 출시되었다. 2023년 11월 15일 정식 버전이 출시되었다. 언어 버전은 C# 12 및 F# 8을 지원한다. MS 공식 블로그에서 2023년 11월 14일 출시를 예고하였다..NET Native AOT의 지원이 확장되어 기존의 윈도우, 리눅스의 x64, ARM64 프로젝트에서 안드로이드, macOS, iOS, iOSSimulator, tvOS(ARM64만 지원), tvOSSimulator, MacCatalyst용 x64, ARM64 프로젝트도 지원한다. 하드웨어가 AVX 및 AVX512를 지원하는 경우 JIT가 적극적으로 이를 활용하도록 튜닝되었다.
다운로드
3.5. 9
한국 시간으로 2024년 2월 14일에 프리뷰로 출시되었으며 2024년 11월 12일 정식 버전이 출시되었다. 언어 버전은 C# 13 및 F# 8을 지원한다.다운로드
4. .NET Framework
FCL(Framework Class Library, 프레임워크 클래스 라이브러리) 클래스는 .NET Framework를 대상으로 하는 모든 언어가 사용할 수 있는 클래스들의 라이브러리이며, CLR(Common Language Runtime, 공용 언어 런타임) 클래스는 공통 언어 런타임 클래스로 알려져 있는데 이 클래스는 언어 외에도 보안, 메모리 관리, 기타 핸들링 역할을 제공하는 가상 머신이기도 하다. 이 FCL과 CLR이 합쳐진 것이 .NET Framework이다.4.1. CIL
.NET 프레임워크를 사용하는 언어들로 작성된 소스 코드는 각 언어에 맞는 컴파일러[12]를 거쳐 .NET CLR용 중간 코드인 CIL(Common Intermediate Language)로 컴파일된 후 .exe 파일로 래핑(wrapping)된다.[13] 그리고 .NET CLR은 이 파일을 JIT 컴파일 방식으로 읽어들여 기계어 번역을 수행한다. CIL은 .NET CLR이 설치된 곳이라면 어디서든 컴파일이 가능하다.예로 들어서 Hello World를 출력하는 C# 코드가
#!syntax csharp
using System;
namespace HelloWorld
{
public class Program
{
private static void Main(string[] args)
{
Console.WriteLine("Hello, World!\n");
Console.ReadLine();
}
}
}
이라면 컴파일 시 바뀌는 CIL 코드는
| .class public auto ansi beforefieldinit HelloWorld.Program extends [mscorlib]System.Object { .method private hidebysig static void Main ( string[] args ) cil managed { .maxstack 8 .entrypoint IL_0000: ldstr "Hello, World!\\n" IL_0005: call void [mscorlib]System.Console::WriteLine(string) IL_000A: call string [mscorlib]System.Console::ReadLine() IL_000F: pop IL_0010: ret } .method public hidebysig specialname rtspecialname instance void .ctor () cil managed { .maxstack 8 IL_0000: ldarg.0 IL_0001: call instance void [mscorlib]System.Object::.ctor() IL_0006: ret } } |
4.2. 주요 지원 언어
- C# - 닷넷의, 닷넷에 의한, 닷넷을 위한 언어.
- Visual Basic .NET - C#보다 단순하지만, 기능은 똑같아 .NET 입문에 적절하다.
- C++
- DLR - 동적 언어 런타임(Dynamic Language Runtime)으로 CLR에서 Python, Ruby 등의 동적 언어들을 돌리기 위한 프레임워크이다. IronPython과 IronRuby 등 타 언어를 C#과 같이 쓸 수 있다.
- F# - GPU 연산 등을 자체 지원 하는 연산에 특화된 언어이다.
- Q# - 양자 알고리즘을 개발하고 실행하기 위한 언어이다.
- Delphi.NET
4.3. 버전별 변경 사항[14]
* 표시가 된 항목은 출시 예정이다.| 버전 | 변경 사항 |
| 1.0 | 닷넷 프레임워크 첫 버전으로서, 핵심 구성 요소 및 기본 프로그래밍 언어를 처음으로 완성한 버전 |
| 1.1 | ASP.NET 기능 강화 및 오라클 데이터베이스, ODBC, OLE DB 지원 |
| 2.0 | 제네릭 프로그래밍을 위한 제네릭 도입, ADO/ASP.net 에 새로운 프로그래밍 기술 추가, AMD64 프로세서용 버전 출시 |
| 3.0[15] | 4개의 주요 기능: 윈도우 프레젠테이션 파운데이션[16], 윈도우 커뮤니케이션 파운데이션[17], 윈도우 워크플로 파운데이션[18], 윈도우 카드스페이스[19] 추가. |
| 3.5 | 기존 언어들[20]에 대한 지원과 새로운 기능이 대거 추가. 서비스 팩 1에서는 여러 가지 기능들이 더 추가 및 확장 |
| 4.0 | 병렬 처리를 위한 Parallel Extension, Parallel Linq 기능 추가, C# 4.0에 다이나믹 타입, 임의 정밀도 정수[21] 타입, 복소수[22] 타입 추가. |
| 4.5 | 메트로 앱 개발 공식 지원, 비동기 처리 기능이 추가된 C# 5.0 및 Visual Basic .NET 을 지원 |
| 4.6 | 64비트를 지원하는 RyuJIT, SSE2와 AVX2 지원, HiDPI 대응, TCF 1.1과 TLS 1.2 대응 |
| 4.7 | ECC를 이용한 암호화 강화, TLS 1.2 개선, WPF에서 터치 및 스타일러스에 대한 추가 지원, WPF를 위한 프린트 API 지원 |
| 4.8 | UWP의 플루언트 디자인을 윈폼, WPF에서 구현하는 것이 가능, 윈폼이나 WPF에서 UWP의 모든 컨트롤을 호스팅하는 것이 가능. |
5. .NET Core
.NET Core는 윈도우 외의 운영 체제가 닷넷을 사용할 수 있도록 하는 프로젝트. 라이선스는 MIT 라이선스 및 아파치 라이선스[23]이다.프로페셔널하고 편리한 C#, 배우기 쉽고 간단하지만 강력한 Visual Basic.NET, 연산에 특화된 F#, 웹 애플리케이션 개발용으로 ASP.NET Core를 사용할 수 있다. 또한 .NET Standard를 통해 .NET Framework, Xamarin, Mono에 호환된다.
윈도우 외의 운영 체제에서도 실행하도록 하는 프로젝트이지만, 컴파일 시 결과물은 PE DLL 파일로 나온다. 윈도우 비주얼 스튜디오에서 컴파일 시 EXE 파일도 나오지만, 실제 컴파일 결과물인 DLL 파일을 로드하여 실행하는 것에 불과하다. DLL 파일이 없으면 당연히 실행되지 않는다.
다른 운영 체제들은 터미널로 .NET Core 런타임을 설치한 후 dotnet(실행할 닷넷 DLL 파일)을 입력하고 실행하면 된다.
.NET Core를 기반으로 한 ML.NET이라는 기계 학습 플랫폼(라이브러리)도 있다.
버전 3.0부터 드디어 GUI를 정식으로 지원한다. 하지만 Windows만 지원한다.
기존에는 CLI 개발만 가능했었지만, 3.x 버전부터는 Windows Form, WPF를 지원한다.
.NET Core는 3.1까지 나왔으며, 이후에는 .NET 5.0에 흡수되어 개발된다. #
2022년 12월을 끝으로 지원이 완전히 종료되었다.
6. .NET Standard
Microsoft에서 개발한 .NET Framework와 .NET Core의 표준이다. .NET Standard 기반 라이브러리의 경우 모든 .NET 기반 프로젝트에서 사용할 수 있다는 장점이 있다.[24]닷넷 프레임워크와 닷넷 코어가 .NET 5를 기점으로 닷넷 코어를 중심으로 통합되면서, 2020년 9월 15일 마이크로소프트에서 개발 중단을 발표했다. # 다만 개발만 중단될 뿐 이후 출시되는 닷넷 버전은 .NET Standard 2.1 이하 버전을 계속 지원할 예정이다.
6.1. .NET Standard로 개발된 라이브러리
Nuget에서 배포 중이며, 인지도가 높은 라이브러리 중에서 .NET Standard로 개발된 라이브러리만 기재할 것.- Json.NET[25] - JSON을 쉽게 파싱/생성할 수 있게 도와주는 라이브러리로, 윈폼이나 WPF는 물론 .NET Core나 UWP(라즈베리 파이, 윈도우 폰 포함)에서도 사용이 가능하다. 이전에는 .NET의 Json 파서 중 독보적인 위치에 있었으나 최근에는 .NET Core 3.0에서 BCL(Base Class Library)에 추가된 Json 파서(System.Text.Json 네임스페이스)에 입지를 내준 편이다. ASP.NET에서도 기존에는 Json Serializer 기본값으로 Newtonsoft.Json을 사용했지만 .NET Core 3.0이 출시된 이후 BCL을 기본값으로 사용하고 있다.
7. .NET Native AOT
.NET 코드를 네이티브 코드(native code)로 컴파일하는 기능.
CIL 문단에서 말한듯이 .NET는 컴파일하면 Java의 JVM와 마찬가지로 네이티브가 아닌 중간 언어인 CIL(Common Intermediate Language)로 컴파일한다. 이렇게 만들어진 프로그램은 .NET 런타임이 CIL를 해석하여 타켓 OS와 CPU의 기계어 코드로 번역하여 수행한다
.NET 런타임만 설치되어 있다면 어떠한 OS나 CPU에서도 .NET 프로그램이 그대로 동작한다는 장점[26]이 있으나 바로 코드를 실행하지 않고 런타임을 거쳐서 실행되기에 실행 속도는 C/C++로 개발한 프로그램보다 느리다. 요즘은 JIT와 하드웨어 성능 향상으로 실행 속도가 특수한 상황이 아니면 별문제가 없지만 C/C++ 프로그램보다 메모리를 많이 자치한다.
Ngen(Native Image Generator)를 사용하여 미리 네이티브 이미지를 생성할 수 있다. 네이티브 이미지를 만들어 놓으면 .NET 런타임은 해석하여 네이티브 코드를 생성하는 대신 이를 불러들여서 실행하도록 한다. 그러다보니 .NET가 업데이트되면 Ngen.exe를 사용하여 주요 라이브러리들의 네이티브 이미지를 미리 만들어 놓는다. 다만 .NET 런타임이 바로 실행할 수 있도록 네이티브 이미지를 만들지 사용하기 위해서는 결국 원래의 .NET 이미지도 있어야 한다.
그래서 나온 게 .NET 7부터 도입되는 것이 바로 .NET Native AOT이다. 닷넷 코드를 CIL가 아닌 네이티브 코드로 직접 컴파일한다. 이로써 C/C++ 프로그램과 동등한 실행 속도와 메모리 최적화를 보장하고 별도의 런타임 설치도 필요 없어졌지만 타켓 OS와 CPU에서만 실행할 수 있다. 따라서 여러 플랫폼을 지원하겠다면 각 플랫폼용으로 컴파일해 줘야 한다. 또한 당연하지만 리플렉션(Reflection)은 AOT에서 지원되지 않는다. .NET 7 이전에도 .NET Native가 존재하였으나 Universal Windows Platform 프로젝트 전용이라 일반적인 .NET 프로젝트에는 사용할 수 없었다.
.NET AOT에서 지원하는 아키텍처가 제한되어 있다. .NET 7의 AOT는 윈도우 및 리눅스용 x64, ARM64 프로젝트만 지원한다. .NET 8부터는 안드로이드, macOS, iOS, iOSSimulator, tvOS(ARM64만 지원), tvOSSimulator, MacCatalyst용 x64, ARM64 프로젝트도 지원한다.
리플렉션 기능 사용의 어려움을 비롯한 .NET AOT에서 발생하는 여러 제한 사항이 있다. 다만 리플렉션이 아예 사용되지 않는 것은 아닌데, 실험적으로 제공되는 Reflection Free 모드를 사용하면 리플렉션이 거의 되지 않게 만들 수 있고, 이 모드를 사용 시 생성되는 바이너리는 C++로 만든 프로그램 수준의 보안성을 지니게 된다고 한다.
때문에 아직은 Windows Forms와 WPF(Windows Presentation Foundation)를 지원하지 않는다. 이 경우 Windows API로 직접 구현하거나, Avalonia UI, Uno Platform 등과 같이 지원되는 프레임워크를 사용해야 한다. Windows Forms의 경우 WinFormsComInterop 라이브러리로 GUI를 사용할 수 있다.
.csproj 파일에 다음 내용을 추가해 주면 NativeAOT 기능을 사용할 수 있다.
<PropertyGroup>
<PublishAot>true</PublishAot>
</PropertyGroup>
Native AOT deployment - 이 글을 따라 하면 C# 프로그램을 NativeAOT로 빌드할 수 있다.<PropertyGroup>
<PublishAot>true</PublishAot>
</PropertyGroup>
8. Xamarin
C#과 .NET Framework를 리눅스에서도 쓸 수 있게 해주는 Mono 프로젝트에서 시작된 프레임워크이다.기본적인 구상은 .NET Framework와 C#으로 안드로이드와 아이폰을 개발하고자 하는 시도이며 이에 따라 .Net을 오픈 소스화 한 Mono의 제작자들이 Monodroid와 Monotouch 라는 라이브러리가 만들어졌으며 이후 이 프로젝트가 제작자가 속한 Xamarin이란 회사의 관리하에 Xamarin으로 이름이 변경된 후 MS가 인수하면서 지금의 자마린이 되었다[27]
안드로이드와 iOS의 API가 준비되어 있기 때문에 크로스플랫폼 축에 약간 넣을 수 있는 정도다. 한번 작성한 폼과 로직이 안드로이드와 아이폰에서 유사하게 작동하고 동시에 유지 보수가 가능하다.
Mono를 주도해 온 멕시코계 냇 프리드먼과 미겔 데이카사(CTO)가 설립하였으며 2016년 2월 24일 마이크로소프트가 인수, 2016년 3월 31일 소스를 공개하였다. 다만 이 이후에도 자마린은 모노에 베이스하고 있던 관계로 계속해서 업데이트 중이던 .NET Framework에 못 따라가는 모습을 보여줬고 따라서 다른 후발 주자에 밀리는 이유가 되었다.
2020년 하반기에 따로 분리되어 있던 .NET 플랫폼들이 하나로 합쳐지는 과정의 초석인 .NET 5가 2020년 하반기에 출시한 후 얼마 지나지 않아 이후 버전인 .NET 6 출시에 맞춰 Xamarin 프레임워크에 변화가 있을 것이라고 예고되었다. # 현재 이 프로젝트는 .NET MAUI(_M_ulti platform _A_pp _UI_)라고 발표되었으며 이 프로젝트가 출시될 경우 자마린은 도태될 예정이다.
결국 React Native와 Flutter등에 밀려 2024년 5월 1일부로 지원 종료가 예정되었다.
MAUI와 자마린이 같다고 오해하는 사람들도 있는데 MAUI가 자마린에 기반하고 있는 것 자체는 사실이지만 내부적인 구조가 거의 바뀌었기 때문에[28] 기존과는 취급법이 달라졌으며 프로젝트 하나로 모든 플랫폼을 관리할 수 있는 기능과[29] 핫 리로드가 지원되는 등 편의성 또한 증대되었다.
8.1. Xamarin.Android
Mono for Android에서 개명되었다. 안드로이드의 API를 C# 스타일의 API로 바꾸어 구현하였다.이후 2021년 11월에 공식 릴리스 예정인 .NET 6에 .NET for Android란 명칭으로 바뀌어 포함될 예정이다.
8.2. Xamarin.iOS
MonoTouch에서 개명되었다. iOS의 API를 C# 스타일의 API로 바꾸어 구현하였다.이후 2021년 11월에 공식 릴리스 예정인 .NET 6에 .NET for iOS란 명칭으로 바뀌어 포함될 예정이다.
8.3. Xamarin.Mac
MacOS 서포트 버전. 해외에선 이를 이용한 유료 앱도 출시되어 있다.8.4. Xamarin.Forms
2014년 뒤늦게 출시된 Xamarin.Forms는 출시 당시에는 개발자들의 호응을 얻었으며 크로스플랫폼 개발이 이루어졌다. MS의 WPF와 C#과 XAML를 사용한다는 공통점은 있으나 WPF와 Xamain/MAUI의 widget 및 라이브러리 사용에 있어 세부적인 차이점이 있어 거의 다른 프레임워크라 할 수 있어 학습량이 증가한다는 단점이 있다.new Label() 하면 Android iOS
그러나, 위의 이야기는 양쪽 플랫폼을 자유롭게 다룰 인력이 없는 개발사에 해당하고, iOS/Android 개발 인력과 기획자가 갖춰져 있는 팀의 경우 아직까지는 기존의 네이티브로 하는 것이 빠를 수 있다. 게임의 경우 기존 네이티브에서 제공되는 UI를 사용하는 경우가 거의 없고, 아예 해당 게임에 맞는 UI 를 바닥부터 개발하는 것이 대부분이기에 유니티 같은 크로스플랫폼 개발이 유리하지만, 게임 외의 앱들은 네이티브에서 제공하는 UI를 사용해야 하기에 오히려 작업이 늘어나는 경우도 있다.
예를 들어, 버튼 하나에 이미지를 입히는 작업만 보더라도, 이벤트 처리 코드는 공유하지만 이벤트 처리는 대부분 서버 연동이나 페이지 전환이기 때문에 애초에 몇 줄 절약되지도 않으며, 반면에 안드로이드의 해당 버튼을 포함하고 있는 페이지의 layout 파일 작업, 해당 버튼의 상태별 이미지를 보여줄 selector 파일 작업, iOS 의 해당 버튼의 상태별 이미지 제어 코드 작업을 해야 하는데, 이렇게 작업하고도 기존의 네이티브 UI의 세부적인 설정을 100% 구현하지 못하는 부분들이 있으며, 버튼 하나하나마다 이렇게 C# style, Android style, iOS style을 왔다 갔다 하면서 작업해야 한다.
예를 들어, 버튼 하나에 이미지를 입히는 작업만 보더라도, 이벤트 처리 코드는 공유하지만 이벤트 처리는 대부분 서버 연동이나 페이지 전환이기 때문에 애초에 몇 줄 절약되지도 않으며, 반면에 안드로이드의 해당 버튼을 포함하고 있는 페이지의 layout 파일 작업, 해당 버튼의 상태별 이미지를 보여줄 selector 파일 작업, iOS 의 해당 버튼의 상태별 이미지 제어 코드 작업을 해야 하는데, 이렇게 작업하고도 기존의 네이티브 UI의 세부적인 설정을 100% 구현하지 못하는 부분들이 있으며, 버튼 하나하나마다 이렇게 C# style, Android style, iOS style을 왔다 갔다 하면서 작업해야 한다.
그리고 네이티브 SDK의 기본이라 할 수 있는 WYSIWYG 방식의 개발도 사실상 불가능하다. 뿐만 아니라, 앱의 크기에 있어서도 기존의 네이티브로 만들면 몇 KB로 끝나는 HelloWorld 정도만 구현해도 소중한 iPhone 용량을 60 MB나 차지해 버리며, 프로젝트를 완성하면 수백 MB를 차지하는데... 기존 방식으로는 몇십 MB로 끝날 내용이다. 결국 게임도 아닌 앱이 게임처럼 메모리 문제로 다운되는 답 없는 상황으로 이어지기 쉽다.[30]
결정적으로 레퍼런스가 너무나도 부족하다. 당장 '버튼 이미지 세팅하고 크기 바꾸는 법'을 찾아보면 깨닫게 된다. 국내 도서는 전무하며, 공식 홈페이지 자료는 애플이나 구글의 공식 자료에 비해 너무나도 부실하기에 구글 같은 수준의 레퍼런스를 기대하고 개발하다간.... Stack Overflow에조차도 제대로 된 설명이 없어서, 오류가 하나 생길 때마다 Xamarin 개발진과 영어로 소통을 해가며 개발하는 개척자의 기분을 느낄 수 있으므로 회사의 프로젝트에 도입을 하기 전에 충분한 연구가 필요하다. 책이 한두 개 나오고 최적화가 어느 정도 될 때까지 기다리자. [31]
위 반론은 리모릭스 개발 이야기와 상통하는 이야기로 Xamarin.Android와 Xamarin.iOS를 사용하여 5만 건 이상의(2017.2 기준) 다운로드를 기록한 성공적인 앱을 만든 노하우와 시행착오가 들어있는 글이다. 하지만 Xamarin.Forms를 적극 도입하지 않았기에 자마린의 장점을 극대화했다고 할 수 없다(개발 시작 시점에 XF가 없었던 것으로 보임). 또한 기존 axml과 storyboard 같은 UI 구성 지식이 없어야 오히려 XF를 적극 도입하게 되며 약간의 custom renderer 코드만 추가하면 못 만들 UI 가 없다. new StackLayout().to라고 치면 각종 애니메이션 관련 메소드들이 나온다.
apk와 ipa의 기본 용량은 10~20 MB이며 곧 나올 XF 2.4와 2.5[32]에서 안드로이드 관련 최적화가 더욱 이루어질 예정이다. 구글에서 영문 검색으로 자료를 찾으면 대부분의 문제들이 이미 논의되어 있다.
Xamarin Forms는 개발진 측에서도 플랫폼 의존도가 적고 커스텀 UI의 중요도가 적은 곳에 적합하며(이름부터가 폼 형식에 적합하다는 의미를 갖고 있다.) 반대로 플랫폼 고유 API 지향적이며 디자인된 UI를 중시하는 경우(사이트에 그림으로 예시하는 것들은 것은 미디어 플레이어, 게임, 지도 앱)에는 Xamarin Native(Android, iOS)를 권장하고 있다. Xamarin Forms는 UI 레이아웃과 페이지 로직의 코드까지 하나로 공유하기 때문에 다중 플랫폼 개발에 있어서 각각 모두 따로 코딩해야 하는 네이티브에 비해 확실하고 분명한 강점이 있으나 그만큼의 제약과 오버헤드되는 단점들과의 타협이 필요하다. 특히 안드로이드 쪽은 앞에서도 언급된 메모리 이슈 및 기본으로 생성되는 'Welcome to Xamarin Forms!'마저도 실행하는 데 네이티브에 비해 기기에 따라 2~3초 정도씩 더 소요되며 아직은 구현이 덜 되거나 버그성 API들도 있다. 제약이 되는 부분들은 인터페이스 작성한 뒤 DependencyService를 통해 플랫폼별로 구현하고 커스텀 UI도 Custom Renderer 써서 플랫폼별로 구현하면 네이티브와 다를 게 없다지만 그럴거면 그냥 네이티브로 작성하는 것에 비해 메리트가 크게 상쇄되니....... 다만 적은 인력으로 빠른 시간 안에 멀티플랫폼 개발을 해야 하는 경우 충분히 고려해 볼 만한 가치가 있으며 개발진 측에서도 포럼을 통해 최적화에 힘쓰고 있다고 하니 앞으로를 기대해 보도록 하자.
Xamarin.Forms 3.0이 출시되었다(2018.5).
FlexLayout[33] 이 추가되었고 CSS까지 지원한다. WPF도 공식 지원 한다.
.NET 5가 2020년 하반기에 출시된 후 앞으로의 로드맵이 공개되었는데 Xamarin.Forms를 기반으로 하는 .NET MAUI로 점차 이전된다고 한다.
다만, 이전 작업이 이루어지고 .NET MAUI 공식 릴리스 이후에도 계속 지원을 하며 2022년 하반기까지 업데이트가 예정되어 있다고 한다.
.NET 공식 블로그 - .NET MAUI
Xamarin.Forms Roadmap
8.5. Xamarin Test Cloud
앱 동작 순서를 입력해 놓으면 2000여개의 실기기에서 자동으로 테스트해 주고 로깅해 준다(유료).8.6. Xamarin Insights
앱 내부에서 일어나는 크래시나 기타 정보를 서버로 전달하여 로깅해 준다. HockeyApp과 통합되었다.8.7. Xamarin.Essentials
모든 기종에서 공유하는 하드웨어적 접근 사항에 대한 API, 폰의 센서나 기본 기능을 활용하는 분야에 대해서 통합된 경험을 제공한다.9. MonoDevelop
MonoDevelop(이하 Mono)는 C#, .NET 등을 개발하는 툴로서 Windows에서는 Visual Studio에게 밀린다. 프로젝트를 만들어서 코드 작성, 컴파일을 할 수 있다. MONO에 기반하기 때문에 Windows Forms나 WFP 같은 MS에 종속된 프레임워크가 아닌 GTK# 등의 오픈 소스 프레임워크를 쓴다는 것도 특징.다만 자마린 프로젝트를 주도하던 자마린의 자마린 스튜디오(현재 VS For Mac)나 상용 툴인 Rider 등에 밀리는 편이다.
10. 사건/사고
10.1. .NET 6.0 핫 리로드 기능 (dotnet watch) 삭제 사건
닷넷 6.0이 11월 9일(한국 시각) 출시하려던 19일 전인 10월 22일(한국 시각), 닷넷 Github 에서 갑작스레 하나의 소스 병합 요청이 조용히 통과되었다. 이를 눈치챈 개발진 커뮤니티는 분노했고, 전황을 확인하다 이 사이트를 통해 두 MS 개발자의 트윗이 화제에 올랐다. 게다가 사내 지침도 유출하여 닷넷 개발자들의 분노는 극도로 치달았고, 결국 사흘 뒤, 한 사용자의 복구 병합이 승인되어 닷넷 6.0 의 핫 리로딩 기능을 유지할 수 있었다.MS 개발자 발언과 사내 메시지의 요지는, 핫 리로드 기능을 닷넷 자체가 아닌 Visual Studio 기능에 이식하려 시도를 하였고(심지어 Visual Studio Code도 아니었다), 이를 통해 오픈 소스에 있던 기능을 Visual Studio 로 닷넷 개발의 편의성을 이용하기 위해 있던 기능을 없애려고 상술을 꾀하려다 걸린 것이다. 당연히 있던 기능이 없어지고 같은 기능을 상용 기능으로 넣으려 했으니 개발 커뮤니티가 불타오르기 충분했던 사건이었다.
한국 외에서는 큰 사건이었으나, 국내에서는 닷넷 개발 환경이 상당히 저조하여 이슈에 오르지 못했고, 몇몇 MS 에반젤리스트 등 전문 개발진 외에는 모르는 사건이었다. 게다가 오히려 닷넷 6.0에서
dotnet watch 등의 핫 리로딩이 부활했다는 언급만 있어 없었던 것이 다시 생겨났다는 오해를 사기 충분했으나, 호응 또한 없어서 조용히 지금 닷넷 6.0 출시를 축하해 주는 분위기만 간간이 나오는 상태다. 이렇게 출시 전 짧은 우여곡절 끝에, 닷넷 6.0이 출시되었다.관심 있는 개발자는 영문이지만 두 언론의 기사를 통해 당시 사건을 확인할 수 있다.
11. 기타
- 라이브러리의 소스 코드가 공개되어 있으며, 여기에서 확인할 수 있다. GitHub에도 있다.#
- .NET 기반 프로그램은 바이럿과 같은 파일 감염형 바이러스에 감염되면 아예 실행이 되지 않는다. 백신으로 치료해도 실행 불능은 그대로라서 다시 설치해야 한다.[34]
- .NET 프로그램은 기본적으로 32비트로 컴파일되고 설정을 만져서 64비트로 컴파일할 수도 있다.
- .NET 라이브러리(DLL)는 32비트나 64비트 .NET 프로그램에서 그대로 사용할 수 있다.
- .NET Framework는 하위 호환이 되지 않기 때문에 여러 버전을 같이 설치해야 한다. 3.5 버전을 설치하면 2.0이나 3.0도 호환이 가능한데, 3.5를 설치할 때 2.0과 3.0도 같이 설치돼서 그런 것뿐이다. 그래도 Windows 7부터는 3.5 SP1 버전이 기본 설치 되며, Windows 업데이트를 통한 자동 설치를 지원하기 때문에 부담이 덜하다.
- 설치를 계속 실패하는 경우, 알려진 해결책을 써도 해결이 안 되는 경우가 있다. Windows를 새로 업데이트하고 난 후에 이 현상이 발생했다면 그래픽 드라이버를 깔아서 업데이트를 해보자. 소프트웨어를 처음 업그레이드 할 경우 그래픽 드라이버가 전부 삭제되거나 비활성화되어 있는 경우가 자주 있어서 이런 듯.
- 프레임워크 설치나 사용 과정에서 낮은 버전과 상위 버전이 꼬이는 오류 등으로도 설치 실패나 에러가 계속 날 수 있는데 마이크로소프트 링크를 참조하면 개별 버전을 직접 설치하는 것도 가능하다. 그래도 안 되는 경우라면 마이크로소프트에서 제공하는 .NET Framework 클린 제거 도구를 사용하고 다시 설치하는 방법도 있다,
- 비주얼 스튜디오를 사용하지 않는다고 프로그램을 만들 수 없는 것은 아니다. .NET Framework는 설치 시 컴파일러도 같이 설치되므로 컴파일러만으로 프로그램을 만들 수 있다.
- Mono 프로젝트가 가장 유명하다. 프로젝트가 시작된 초기에는 리처드 스톨먼 등이 Mono는 잠재적으로 MS의 고소 위협에 시달릴 수 있으니 쓰지 말아야 한다고 주장하기도 했었다. 하지만 사티아 나델라가 MS의 CEO가 된 이후 오픈 소스 커뮤니티 끌어안기에 적극적으로 나서면서 MS가 세운 .NET Foundation과 MS가 인수한 Xamarin이 아예 Mono의 공식 개발 팀이 된 상태이다. 이로써 Mono 프로젝트는 법적 분쟁 가능성이 일소되었으면서 .NET과의 호환성도 확실히 보장되는 확실한 오픈 소스판이 되었다고 봐도 무방하다.
- .NET Core라는 리눅스와 macOS에서 컴파일과 실행이 가능한 Mono와 별도의 오픈 소스 플랫폼이 존재한다. 하지만, 컴파일을 할 경우 결과물이 PE로 나온다. 이것도 .NET Foundation이 개발을 맡고 있고 Mono 최신판에 .NET Core가 이식되었다.
- DotGNU라는, 한때 GNU 프로젝트의 일부였으나 현재는 여기서 제외된 오픈 소스 프로젝트도 있다.
- .NET으로 운영 체제를 만들 수도 있다! 현재 Cosmos라는 C#이나 VB.NET 등으로 운영 체제를 만들 수 있는 오픈 소스 킷이 GitHub에 올라와 있다.[35]
- 마이크로소프트가 빌드 2019 컨퍼런스에서 2020년 11월 경에 출시될 예정인 5.0 버전에서 현재까지 출시된 .NET Framework와 .NET Core, Xamarin 등이 하나의 플랫폼으로 합쳐질 것이라고 예고했다.# 정확히는 .NET Framework는 더 이상 업그레이드되지 않고 .NET Core만 업그레이드된다는 뜻이다. 또한 .NET Core는 넘버링을 맞추기 위해 3.0 버전 이후 4번대를 뛰어넘었고, 4.8 버전이 기존 닷넷 프레임워크의 마지막 메이저 버전이 되었다.
- 2019년 9월 1일에 .NET Core가 3.0으로 업데이트되면서 .NET Core를 사용한 Windows Forms와 WPF의 개발이 가능하게 되었다.
- 와인(소프트웨어)에서 닷넷 기반 프로그램 실행이 가능하다. 다만 TmaxOS의 경우 호환 레이어 자체가 닷넷을 지원하지 않아서 실행이 불가능하다.
- 마이크로소프트 빌드 2020 컨퍼런스에서 Win32와 UWP로 파편화된 윈도우 앱 개발 플랫폼을 통합하는 프로젝트 리유니온이 공개되었다.
- 갈아엎기 전의 윈도우 롱혼의 여러 내장 프로그램들이 .NET로 만들어졌다. 다만 안정성 문제로 갈아엎은 이후 미디어 센터를 제외하고 .NET 기반 내장 프로그램은 금지되었다.
- 꽤 유명한 것과는 별개로 의외로 한국에서 닷넷을 접하기나 배우기는 굉장히 어렵다. 컴퓨터를 전공으로 한들 대부분의 대학 커리큘럼은 대부분 C와 자바, 파이썬으로 이루어져 있으며 심지어 이는 명문대와 사이버대를 막론하고 다 같다. 이는 한국의 전자정부표준프레임워크가 Java 기반인 것과 파이썬이 워낙 사용하는 분야가 많기 때문으로 한국에서 닷넷 관련 인력을 구하는것은 매우 힘들며 그나마도 전부 게임 개발 관련 인력이다.
12. 외부 링크
[1] 특히 닷넷 또한 개발이 20년이 넘어가면서 윈도우 구버전에 설치된 3.5 이하 초기 버전과 기존 .NET Framework와 호환성이 불완전한 .NET Core까지 버전이 엄청나게 차이 나는 상황이 생기면서 자주 보인다.[2] 또한 .NET 6 이후부터 M 시리즈 애플 실리콘 맥을 네이티브로 지원한다.[3] CentOS 8이 레드햇 쪽의 정책 변경으로 LTS 없이 7보다 빨리 지원이 끝나서 8 버전에 대한 정식 버전 .NET 6은 없을 예정이다.[4] Windows Media Center 또는 Tablet PC 관련 기능을 실행하기 위해 기본 탑재 된다. Professional이나 Home Edition SP1에는 .NET Framework 1.0이 기본 설치 되지 않지만, 설치 CD에 선택적 구성 요소로 설치할 수 있게 내장되어 있다.[5] Windows XP SP2/SP3에는 .NET Framework 1.1 SP1이 기본 설치 되지 않지만, 설치 CD에 선택적 구성 요소로 설치할 수 있게 내장되어 있다.[6] 비공식적으로는 1.0과는 달리 7(2008 R2)부터 10(2022)까지의 윈도우에서도 설치할 수는 있다.[7] 2.0 SP1부터는 9x 지원이 중단되었다.[8] 2.0 SP1부터는 2000 SP4가 설치되어 있어야 한다.[9] Windows 8부터는 선택적 구성 요소로 변경되었으며 .NET Framework 2.0-3.5 기반 응용 프로그램을 실행할 때 설치할 거냐고 물어본다.[10] 3 버전은 건너뛰었다.[11] macOS, 리눅스, 안드로이드, iOS 등[12] C#의 경우 csc라는 이름의 컴파일러가 있다. 따라서 굳이 비주얼 스튜디오를 거치지 않아도 컴파일이 가능하긴 하다.[13] .NET Core 애플리케이션은 .dll 파일을 출력한다.[14] 출처는 MSDN 및 위키피디아[15] 이 버전에서 .NET Framework의 핵심 기능은 변경되지 않았다.[16] Windows Presentation Foundation[17] Windows Communication Foundation[18] Windows Workflow Foundation[19] Using Cardspace in Windows Communication Foundation[20] C# 3.0 및 Visual Basic .NET 등[21] System.Numerics.BigInteger[22] System.Numerics.Complex[23] 출처[24] 단 .NET Standard에서 제공하는 기능만을 사용해서 만든 라이브러리의 경우에만 해당되며, 이 라이브러리에 특정 플랫폼에 종속된 기능을 추가할 경우에는 사용할 수가 없다. Xamarin에서는 일부 지원하는 듯하다.[25] NuGet 패키지명인 Newtonsoft.Json으로도 널리 알려져 있다.[26] CPU 아키텍처마다 기계어가 다르기 때운에 C/C++ 프로그램은 한 OS만 타켓으로 잡더라도 여러 아키텍처용으로 각각 컴파일해 줘야 한다. 현재 많이 쓰이고 있는 아키텍처인 x86-64, ARM64용으로 제작한다. 과거에는 x86-64용으로만 제작했으나 Windows on ARM와 이를 탑재한 기기들이 출시되면서 ARM64용도 제작하는 경우가 늘고 있다. 물론 x86-64 에뮬레이터가 있기에 아예 x86-64 프로그램을 사용할 수 없다는 것은 아니다.[27] 여담으로 Mono와 자마린을 만든 미겔 데이카사는 자마린이 인수되면서 MS의 직원이 되었고 .NET 재단에서 있으면서 .NET의 오픈 소스화에 가장 많은 영향을 준 인물로 평가받는다.[28] 가장 큰 변화는 렌더링 구조의 변화로 기존에 각 플랫폼별 다른 라이브러리를 사용하는 구조였지만 MAUI부터는 공통 라이브러리를 사용한다.[29] 자마린은 iOS, 안드로이드별로 따로따로 프로젝트를 만들어서 관리해야 되지만 MAUI는 프로젝트 하나에서 모든 플랫폼을 대상으로 개발할 수 있다.[30] 물론 이 문제는 자마린뿐만 아니라 플러터 등의 다른 크로스플랫폼 개발 프레임워크에 다 해당되는 문제다. 같은 크로스플랫폼 개발 프레임워크끼리 비교하면 바이트코드가 조금이라도 더 작은 자마린이 좀 더 작게 나오는 경우가 많다. 물론 큰 차이는 아니다.[31] 물론 이건 국내 한정이고 실제로는 자마린이 크로스플랫폼 프레임워크 중 일찍 나온 편에 속하기 때문에 다른 개발 플랫폼에 비해 많다고 평가된다.[32] 출시되었다.[33] css의 flexbox와 유사하다.[34] Nt 헤더 > 옵셔널 헤더 > 데이터 디렉토리스 멤버 중에 맨 마지막 부분에 닷넷 메타데이터 위치랑 크기가 있다. 이때 PE(Portable Executable)가 변조가 되면 그 위치가 바뀌거나 원래의 프로그램 EP(Entry Point)가 바뀌게 되어 실행이 불가능하다.[35] 컴파일로 나온 IL 코드를 어셈블리어로 번역시키는데, 그렇게 번역 과정을 마쳐서 나온 ASM 파일의 크기가 MB 단위로 나온다.