나무모에 미러 (일반/밝은 화면)
최근 수정 시각 : 2024-11-16 19:38:52

Microsoft .NET

닷넷에서 넘어옴
파일:Microsoft 로고.svg파일:Microsoft 로고 화이트.svg
{{{#!wiki style="margin:0 -10px -5px; min-height:calc(1.5em + 5px); word-break:keep-all"
{{{#!folding [ 펼치기 · 접기 ]
{{{#!wiki style="margin:-6px -1px -11px"
<colbgcolor=#393939,#737373><colcolor=#fff>제품군
하드​웨어Surface · Xbox · HoloLens · PixelSense · Zune · Pluton · IVAS
소프트​웨어Windows · Office · Edge · Media Player · Hyper-V · Defender · Visual Studio Code · Visual Studio · Windows Terminal · Microsoft Store · Xbox App · PowerToys · Internet Explorer · MS-DOS · Windows Movie Maker · Autoruns · Clipchamp
서비스Microsoft Azure · OneDrive · Microsoft Copilot · Bing · LinkedIn · Microsoft Docs · Skype · MSN · 정품인증 · Xbox Game Pass · Xbox Cloud Gaming · Xbox network
관련 기술ASF · ASP · Blazor · COM · DCOM · DirectX · 파일 시스템(FAT · NTFS · ReFS) · MFC · .NET(.NET Core · .NET Standard · C# · F# · Visual Basic .NET · Windows Forms · WPF · UWP · .NET MAUI · ASP.NET · ML.NET) · OLE · Q# · Silverlight · Visual Basic · VBA · WASAPI · Windows 커널 · Windows 디자인 · Windows API · Windows Runtime(UWP · WinUI 3) · WMA · WMV · Xamarin · XNA · 하복 엔진 · SAMI · PowerShell · Windows Modern Standby
산하 계열사 및 사업부GitHub · .NET Foundation · Microsoft Gaming · LinkedIn
관련 인물빌 게이츠(은퇴) · 폴 앨런(은퇴) · 스티브 발머(퇴사) · 게이브 뉴웰(퇴사) · 마이크 이바라(퇴사)
사티아 나델라 · 필 스펜서 · 브래드 스미스
기타제니맥스 미디어 인수 · 액티비전 블리자드 인수 · 시작 메뉴 · 빌 게이츠의 굴욕
관련 틀365 제품군 · 하드웨어 제품군 · Surface 제품군 · Windows 제품군}}}}}}}}}
Microsoft .NET
파일:Microsoft .NET 아이콘.svg
<colbgcolor=#fff,#1f2023><colcolor=#512BD4> 종류 프레임워크
라이선스 MIT 라이선스
지원 언어 C#. Visual Basic .NET, C++, DLR, F#,
Q#, Delphi.NET
파일:홈페이지 아이콘.svg | 파일:GitHub 아이콘.svg파일:GitHub 아이콘 화이트.svg | 파일:유튜브 아이콘.svg | | 파일:디스코드 아이콘.svg
1. 개요2. 지원 플랫폼3. 버전
3.1. 53.2. 63.3. 73.4. 83.5. 9
4. .NET Framework
4.1. CIL4.2. 주요 지원 언어4.3. 버전별 변경사항
5. .NET Core6. .NET Standard
6.1. .NET Standard로 개발된 라이브러리
7. .NET Native AOT8. Xamarin
8.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 설치가 가능한 플랫폼이다.

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일

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을 지원한다.

핫 리로딩 기능이 유지된다. 상세한 설명은 사건/사고 문단 참조.

이 메이저 업데이트는 특히 M1ARM 프로세서 네이티브 지원에 중점이 맞춰져 있어 자바 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. 주요 지원 언어

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로 개발된 라이브러리만 기재할 것.

7. .NET Native AOT

파일:NET-Native-AOT.png

.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로 빌드할 수 있다.

8. Xamarin

C#.NET Framework리눅스에서도 쓸 수 있게 해주는 Mono 프로젝트에서 시작된 프레임워크이다.

기본적인 구상은 .NET FrameworkC#으로 안드로이드아이폰을 개발하고자 하는 시도이며 이에 따라 .Net을 오픈소스화 한 Mono의 제작자들이 Monodroid와 Monotouch 라는 라이브러리가 만들어졌으며 이후 이 프로젝트가 제작자가 속한 Xamarin이란 회사의 관리 하에 Xamarin으로 이름이 변경된 후 MS가 인수하면서 지금의 자마린이 되었다[27]

안드로이드iOSAPI가 준비되어 있기 때문에 크로스 플랫폼 축에 약간 넣을수 있는 정도다. 한번 작성한 폼과 로직이 안드로이드와 아이폰에서 유사하게 작동하고 동시에 유지보수가 가능하다.

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 NativeFlutter등에 밀려 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 는 출시당시에는 개발자들의 호응을 얻었으며 Cross-Platform 개발이 이루어졌다. MS의 WPF와 C#과 XAML를 사용한다는 공통점은 있으나 WPF와 Xamain/MAUI의 widget및 라이브러리 사용에 있어 세부적인 차이점이 있어 거의 다른 프래임워크라 할수 있어 학습량이 증가한다는 단점이있다.

new Label() 하면 Android iOS WindowsPhone WPF UWP macOS Tizen 으로 모두 번역해준다. 숨차다 다양한 nuget 패키지들과 함께 이용하면 90% 이상의 코드를 공유할 수 있으며 10%이하의 OS 별 코드를 작성하여 여러 OS 용 네이티브 앱 개발이 가능하다. WPF 와 마찬가지로 Code 스타일과 Xaml (재믈) 스타일이 있다. 장단점이 있으며 개발환경/취향에 따라 선택하면 된다.
그러나, 위의 이야기는 양쪽 플랫폼을 자유롭게 다룰 인력이 없는 개발사에 해당하고, iOS/Android 개발 인력과 기획자가 갖춰져있는 팀의 경우 아직까지는 기존의 네이티브로 하는 것이 빠를 수 있다. 게임의 경우 기존 네이티브에서 제공되는 UI를 사용하는 경우가 거의 없고, 아예 해당 게임에 맞는 UI 를 바닥부터 개발하는것이 대부분이기에 유니티 같은 Cross-Platform 개발이 유리하지만, 게임 외의 앱들은 네이티브에서 제공하는 UI를 사용해야 하기에 오히려 작업이 늘어나는 경우도 있다.
예를들어, 버튼 하나에 이미지를 입히는 작업만 보더라도, 이벤트 처리 코드는 공유하지만 이벤트 처리는 대부분 서버연동이나 페이지 전환이기 때문에 애초에 몇 줄 절약되지도 않으며, 반면에 안드로이드의 해당 버튼을 포함하고 있는 페이지의 layout 파일 작업, 해당 버튼의 상태별 이미지를 보여줄 selector 파일 작업, iOS 의 해당 버튼의 상태별 이미지 제어 코드작업을 해야하는데, 이렇게 작업하고도 기존의 네이티브 UI의 세부적인 설정을 100% 구현하지 못하는 부분들이 있으며, 버튼 하나 하나 마다 이렇게 C# style, Android style, iOS style 을 왔다갔다 하면서 작업해야한다.

그리고 네이티브 SDK의 기본이라 할 수 있는 WYSIWYG 방식의 개발도 사실상 불가능하다. 뿐만 아니라, 앱의 크기에 있어서도 기존의 네이티브로 만들면 몇 KB로 끝나는 HelloWorld 정도만 구현해도 소중한 iPhone 용량을 60MB나 차지해버리며, 프로젝트를 완성하면 수백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~20MB이며 곧 나올 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. 기타

12. 외부 링크



파일:CC-white.svg 이 문서의 내용 중 전체 또는 일부는
문서의 r190
, 번 문단
에서 가져왔습니다. 이전 역사 보러 가기
파일:CC-white.svg 이 문서의 내용 중 전체 또는 일부는 다른 문서에서 가져왔습니다.
[ 펼치기 · 접기 ]
문서의 r190 (이전 역사)
문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)


파일:CC-white.svg 이 문서의 내용 중 전체 또는 일부는
문서의 r10
, 번 문단
에서 가져왔습니다. 이전 역사 보러 가기
파일:CC-white.svg 이 문서의 내용 중 전체 또는 일부는 다른 문서에서 가져왔습니다.
[ 펼치기 · 접기 ]
문서의 r10 (이전 역사)
문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)


파일:CC-white.svg 이 문서의 내용 중 전체 또는 일부는
문서의 r173
, 번 문단
에서 가져왔습니다. 이전 역사 보러 가기
파일:CC-white.svg 이 문서의 내용 중 전체 또는 일부는 다른 문서에서 가져왔습니다.
[ 펼치기 · 접기 ]
문서의 r173 (이전 역사)
문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)


파일:CC-white.svg 이 문서의 내용 중 전체 또는 일부는
문서의 r4
, 번 문단
에서 가져왔습니다. 이전 역사 보러 가기
파일:CC-white.svg 이 문서의 내용 중 전체 또는 일부는 다른 문서에서 가져왔습니다.
[ 펼치기 · 접기 ]
문서의 r4 (이전 역사)
문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)


[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 단위로 나온다.