[C# 12와 .NET 8] 1. .NET 개요

1. 개발 환경 구축

 

C# programming을 시작하기 전에 C# code를 다룰 수 있는 editor가 필요합니다. Microsoft는 이에 대해 다음과 같은 code editor와 IDE(Integrated Development Environment)를 제공하고 있습니다.

• Visual Studio 2022 for Windows
• Visual Studio 2022 for Mac (2024년 8월 지원종료)
• Visual Studio Code for Windows, Mac, Linux
• Visual Studio Code for Web
• GitHub Codespaces

또한 JetBrains사의 Rider와 같은 C# code 편집기도 존재합니다.

 

(1) 학습을 위한 적절한 도구의 선택

 

● Polyglot Notebooks extension 사용하기

 

Visual Studio Code를 사용하기로 했다면 이를 통해 얻을 수 있는 장점 중의 하나로 Polyglot Notebooks extenstion이 있습니다. 이 확장 기능은 간단한 code를 실행해 볼 수 있는 기능을 제공하는데 간편한 학습용으로 적절하게 사용될 수 있습니다.

 

다만 Polyglot Notebooks는 아래와 같은 제한사항을 가지고 있으므로 실제 build용으로는 적합하지 않습니다.

• website, sevice, app 등을 생성할 수 없습니다.
• 입력과 관련한 동작을 수행할 수 없습니다. 예를 들어 ReadLine이나 ReadKey 등을 사용할 수 없습니다.
• 인수를 전달할 수 없습니다.
• 자신만의 namespace를 정의할 수 없습니다.
• 자체적인 어떠한 debugging 도구도 존재하지 않습니다.

Polyglot Notebooks의 원래 이름은 .NET Interactive Notebooks였으나 단지 해당 extension이 C#과 같은 .NET언어전용이 아니기 때문에 이름이 변경되었습니다. 다만 본래 식별자 ID인 'ms-dotnettools.dotnetinteractive-vscode'는 그대로 유지하고 있습니다.

 

● cross-platform개발을 위한 Visual Studio Code 사용하기

 

cross-platform개발이 가능한 가장 modern하면서도 가벼운 code editor로는 단연코 Visual Studio Code를 들 수 있습니다. 이 editor는 Windows나 Mac, Linux에 까지 대부분의 OS상에서 동작할 수 있고 때문에 cross-platform app개발 역시 가능합니다. C#을 넘어 많은 언어의 지원을 위해 광범위하면서도 점점 방대해지고 있는 확장기능을 제공하고 있으므로 최신 cross-platform개발을 위해서는 가장 좋은 선택이 될 수 있습니다. 무엇보다 2023년 preview로 출시된 C# Dev kit확장도구는 Visual Studio Code를 다목적 code editor에서 C#과 .NET을 위한 최적화된 바꿔줍니다. C# Dev kit에 관해서는 아래 link에서 좀더 자세한 정보를 확인할 수 있습니다.

Announcing C# Dev Kit for Visual Studio Code - Visual Studio Blog (microsoft.com)

Announcing C# Dev Kit for Visual Studio Code - Visual Studio Blog

 

물론 아직까지는 mobile을 위한 지원과 desktop 개발에 있어서 취약하지만 web개발을 위한 강력함을 가지고 있으며 ARM Processor역시 지원함으로써 Apple Silicon이나 Raspberry Pi와 같은 환경에서도 사용할 수 있습니다. Visual Studio Code는 가장 인기 있는 통합 개발 환경으로서 2023년 Stack Overflow설문조사 결과 개발자 73% 이상이 Visual Studio Code를 사용하는 것으로 나타났습니다.

 

● Cloud형 개발을 위한 GitHub Codespaces 사용하기

 

GitHub Codespaces는 cloud에서 host되는 환경으로 spun up 될 수 있는 Visual Sutdio Code를 기반으로 한 완전한 개발도구이며 web browser를 통해 접근할 수 있습니다. Git repository, 학장기능 및 내장 명령줄 interface를 지원함으로써 모든 device로부터 test 및 동작시킬 수 있고 수정역시 가능합니다.

 

● Visual Studio for Mac 사용하기

 

Microsoft Visual Studio 2022 for Mac은 console app, website, web service, desktop및 mobile app 등 대부분 형태의 application을 생성할 수 있습니다. 다만 iPhone이나 iPad와 같은 장치에서 동작하는 iOS와 같은 OS를 위한 app을 compile 하기 위해서는 macOS전용인 Xcode를 사용해야 합니다.

 

● Visual Studio for Windows 사용하기

 

Microsoft Visual Studio 2022 for Windows는 console app, website, web service, desktop및 mobile app 등 대부분 형태의 application을 생성할 수 있습니다. Visual Studio 2022 for Windows를 cross-platform mobile app작성을 위해 Xamarin확장 기능을 사용할 수 있지만 macOS의 compile에서는 여전히 Xcode가 필요합니다.

Visual Studio 2022 for Mac은 .NET 8을 지원하지 않으며 2024년 8월에 종료될 예정입니다. 따라서 Microsoft Visual Studio 2022 for Windows이나 Visual Studio Code for Mac, JetBrains Rider for Mac으로 개발도구를 전환해야 합니다. 자세한 사항은 아래 link를 참고해 주시기 바랍니다.

Visual Studio for Mac Retirement Announcement - Visual Studio Blog (microsoft.com)

 

Microsoft Visual Studio 2022 for Windows를 실행하려면 최소 Windows 7 SP1이후의 version을 사용해야 하며 Microsoft Store에서 설치되고 sendbox(computer를 보호하기 위한)에서 실행되는 UWP(Universal Windows Platform) app을 생성하려면 Windows 10/11이 필요합니다. 단 Windows S mode는 지원하지 않습니다.

 

(2) Cross-platform 배포

 

개발을 위한 code editor와 OS의 선택에 있어서 배포에 대한 제한은 없습니다. 현재 .NET 8은 개발을 위한 아래 Platform을 지원하고 있습니다.

• Windows : Windows 10은 versio 1607 또는 그 이상, Windows 11은 version 22000 또는 그 이상, Windows Server는 2012 R2 SP1 또는 그 이상, Nano Server는 version 1809 또는 그 이상
• Mac : macOS Catalina version 10.15 및 Rosetta 2 x64 emulator 또는 그 이상

Linux : Alpine Linux는 3.17 또는 그 이상, Oracle Linux는 8 또는 그 이상, Debian은 11 또는 그 이상, Fedora는 37 또는 그 이상, Open SUSE는 15 또는 그 이상, RHEL은 7 또는 그 이상, SUSE Enterprise는 12 SP2 또는 그 이상, Ubuntu는 20.04 또는 그 이상

• Android : API 21 또는 그 이상
• iOS와 tvOS : 11.0 또는 그 이상
• Mac Catalyst : 10.15 또는 그 이상, ARM64에서는 11 또는 그 이상

Windows 7과 8.1에 대한 .NET의 지원은 2023년 1에 지원이 종료되었습니다.

 

.NET 5 이상에서 Windows ARM64를 지원하므로 Microsoft Surface Pro X와 같은 장치를 위한 개발 및 배포가 가능합니다. Parallels와 Windows 11 Arm virtual machine을 사용한 Apple M1 Mac에서 개발 역시 원활한 속도를 제공함으로써 개발이 가능합니다.

아래 주소에서는 지원되는 최신의 OS와 version을 확인해 볼 수 있습니다.
-https://github.com/dotnet/core/tree/main/release-notes/8.0

 

(3) Visual Studio 2022 for Windows 설치

 

대다수의 많은 .NET개발자들이 가장 많이 사용하는 개발 IDE로 Visual Studio를 꼽을 수 있습니다. 현재 Visual Studio의 최신버전은 2022로 주요 편집기로 다른 Tool을 사용한다고 하더라도 Windows에서의 .NET개발의 경우라면 Visual Studio가 필요한 경우는 얼마든지 생길 수 있기 때문에 Visual Studio를 반드시 사용해 볼 것을 권합니다.

 

2014년 10월부터 Microsoft는 학생, open-source 기여자, 개인이 무료로 사용할 수 있는 Windows용 Visual Studio를 제공하고 있으며 Community Edition이라는 이름으로 배포되고 있습니다. 이 edition은 위 조건에 맞는 상황이라면 아래 주소에서 내려받아 설치하고 사용할 수 있습니다.

 

Download Visual Studio Tools - Install Free for Windows, Mac, Linux (microsoft.com)

Download Visual Studio Tools - Install Free for Windows, Mac, Linux

● Microsoft Visual Studio의 Keyboard 단축키 설정

 

Visual Studio의 단축키설정은 일반적인 공통의 경우가 아니면 대부분 취향대로 변경할 수 있습니다. 자세한 사항은 아래 주소를 참고하시기 바랍니다.

 

Identify and customize keyboard shortcuts - Visual Studio (Windows) | Microsoft Learn

Identify and customize keyboard shortcuts - Visual Studio (Windows)

 

(4) Visual Studio Code 설치

 

Visual Studio Code는 최근 몇년 사이에 급속히 향상된 code편집기입니다. 안정적이지는 않더라도 가장 빠르게 최신의 기능을 경험해 보고 싶다면 다음 version으로의 build가 매일 이루어지는 Insiders edition을 사용해 볼 수도 있습니다. Visual Studio 2022와 같은 IDE를 사용하기로 결정했다고 하더라도 간단한 작업에서나마 Visual Studio Code를 사용해 볼 것을 권장합니다.

 

Visual Studio Code를 통해 .NET개발에 참여하려면 Visual Studio Code와 .NET SDK, 그리고 C# Dev Kit확장도구를 설치해서 사용할 수 있습니다.

 

Visual Studio Code는 아래 주소에서 내려 받을 수 있습니다.

Visual Studio Code - Code Editing. Redefined

Visual Studio Code - Code Editing. Redefined

Visual Studio Code의 설치는 비교적 간단하지만 필요하다면 설치 및 설정에 대한 Microsoft가 제공하는 공식적인 Guide문서를 읽어볼 수 있습니다.

Setting up Visual Studio Code

Setting up Visual Studio Code

.NET SDK는 아래 주소에서 내려받을 수 있습니다.

Download .NET (Linux, macOS, and Windows) (microsoft.com)

Download .NET (Linux, macOS, and Windows)

경우에 따라 .NET SDK는 여러 version의 설치가 필요할 수 있습니다. 현재 .NET 8.0및 6.0과 .NET 7.0이 지원되는 version으로 각각의 개별적인 설치가 가능합니다.

 

● 확장도구 설치

 

Visual Studio Code는 필요한 기능을 선택적으로 확장해 사용할 수 있는 풍부한 확장기능들이 존재합니다.(Visual Studio도 그렇지만...) 아래 표는 C#과 .NET개발에서 편리하게 사용할 수 있는 몇 가지 확장도구를 안내하고 있습니다.

명칭	식별자	용도
C# Dev Kit	ms-dotnettools.csdevkit	Microsoft의 공식 C#언어 확장 도구입니다. solution단위의 code를 관리하고 test할 수 있습니다. 또한 C#과 C# Dev Kit 확장도구를 위한 IntelliCode를 포함합니다.
C#	ms-dotnettools.csharp	C# code 작성을 지원하기 위한 것으로 구문강조, intelliSense, 정의로 이동, .NET Debugging, csproj (project file)지원등을 포함합니다.
IntelliCode for C# Dev Kit	ms-dotnettools.vscodeintellicode csharp	C# 뿐만 아니라 Python, TypeScript/JavaScript, Java를 위한 AI coding지원을 제공합니다.
Polyglot Notebooks	s-dotnettools.dotnet-interactive vscode	.NET및 기타 다른 언어를 위한 code조각 입력및 실행을 지원합니다. 자체 의존성을 가진 Jupyter (ms-toolsai.jupyter) 확장도구에 대한 의존성을 가지고 있습니다.
REST Clien	humao.rest-client	Visual Studio Code안에서 직접 HTTP요청을 보내고 응답을 받아 볼 수있습니다.
ilspy-vscode	icsharpcode.ilspy-vscode	.NET, .NET Framework, .NET Core, and .NET Standard등에서의 MSIL assembly에 대한 Decompile을 지원합니다.

C# Dev Kit은 C# extension에 대한 의존성을 가지고 있으므로 별도로 설치할 필요는 없습니다. .NET Install Tool for Extension Authors와 IntelliCode for C# Dev Kit extensions역시 의존성을 가지므로 이들도 역시 설치될 것입니다. 또한 C# extension은 새로운 Language Service Protocol (LSP) host를 가지고 있으므로 OmniSharp을 더이상 사용하지 않습니다. 

 

식별자는 아래 주소에서 itemName의 인수로 전달해 상세한 정보를 확인해 볼 수 있습니다.

https://marketplace.visualstudio.com/items?itemName= 

 

● 명령어를 통한 Visual Studio Code 확장도구 관리

 

Visual Studio Code는 자체 기능을 통해 필요한 확장도구를 검색하고 설치할 수 있습니다. 그러나 필요하다면 terminal을 통한 명령어를 사용하여 확장도구를 설치하거나 삭제하고 설치된 목록을 확인해 볼 수 있습니다.

code --list-extensions	현재 설치된 확장도구를 나열합니다.
code --install-extension [식별자]	지정한 확장도구를 설치합니다.
code --uninstall-extension [식별자]	지정한 확장도구를 삭제합니다.

 

여기서 식별자는 위에서 이미 언급한 확장도구의 식별자를 의미하며 다음과 같이 명령어를 내려줄 수 있습니다.

 

● Visual Studio Code version

 

Microsoft는 Visual Studio Code에 대한 새로운 기능을 거의 매달 release하고 있으며 bug수정의 주기는 더 자주 이루어지고 있습니다. 이때 Visual Studio는 다음과 같은 형식의 version을 안내하고 있습니다. (실제 존재하는 version이 아닌 예시입니다.)

• Version 1.77.0, APRIL 2023 feature release
• Version 1.77.1, APRIL 2023 bug fix release

2024년 1월현재 최신버전은 1.85.1이지만 Visual Studio Code의 자체 version보다는 C# Dev Kit이나 C# extention의 version이 좀더 중요하다고 볼 수 있습니다.   C# for Visual Studio Code 확장도구를 설치했다면 이에 대한 version 역시 중요하므로 주기적으로 update를 해줄 것을 권장합니다.

 

C# extention이이 꼭 필요한 것은 아니지만 IntelliSense와 code 탐색, debugging기능을 지원하며 최신의 C#언어를 지원하기 위한 update 역시 이루어지고 있는 등 유용한 점이 많으므로 C#언어를 사용한다면 꼭 설치해서 사용해 볼 것을 권합니다.

 

● Microsoft Visual Studio Code의 keyboard 단축키

 

Microsoft Visual Studio Code의 keyboard 단축키는 사용하는 운영체제에 따라 조금씩 달라지 수 있지만 debugging에서 사용되는 key와 같이 자주사용되는 key의 경우에는 운영체제마다 최대한 동일하게 유지되도록 지원하고 있습니다.

 

필요하다면 단축키는 임의로 조정이 가능하며 자세한 사항은 아래 link를 참고하시기 바랍니다.

Visual Studio Code Key Bindings

Visual Studio Code Key Bindings

아래 주소를 통해서는 운영체제에 따른 배정된 Visual Studio Code의 단축키를 PDF로 제공하고 있으니 해당 문서를 확인해 보는 것도 좋습니다.

• Windows : keyboard-shortcuts-windows.pdf (visualstudio.com)
• MAC OS : keyboard-shortcuts-macos.pdf (visualstudio.com)
• Linux : keyboard-shortcuts-linux.pdf (visualstudio.com)

2. .NET의 개요

 

.NET, .NET Core, .NET Framework, Xamarin 등의 여러 platform은 application개발을 위한 것으로 서로 연관된 동시에 겹치는 면도 존재합니다. 따라서 전체적인 .NET의 이해를 위해 각각의 platform의 개념을 간략하게나마 파악해보고자 합니다.

 

(1) .NET Framework

 

.NET Framework는 code의 실행을 관리하는 CLR(Common Language Runtime)과 application을 build 하는데 필요한 풍부한 Library를 제공하는 BCL(Base Class Library)를 포함하는 개발 platform입니다.

 

사실 Microsoft는 .NET Framework를 cross-platform을 염두에 두고 설계하기는 했지만 시간이 지나면서 결국에는 Windows전용의 platform으로 자리 잡게 되었고 따라서 .NET Framework는 공식적으로 Windows운영체제 전용의 component가 된 것입니다.

 

현재 .NET Framework는 자신이 설치된 운영체제의 생명주기정책을 따르고 있으며 현재 10억대 이상의 computer에 설치되었다고 추정되고 있습니다. 현재는 가능한 한 최소한의 update만 이루어지고 있고 심지어는 bug의 수정조차 문제를 일으킬 수 있어서 update주기 자체가 늘어지고 있는 상황에 있습니다.

 

.NET Framework 4.0과 이후 version을 통해 작성된 모든 application은 같은 version의 CLR과 GAC(Global Assembly Cache)에 저장된 library를 공유하고 있는데 몇몇이 호환성을 위해 특정한 version을 필요로 하게 된다면 문제를 일으킬 수 있습니다.

 

굳이 세대적으로 나누어 본다면 .NET Framework는 WIndows전용의 platform이자 1세대이며 더 이상의 개선이 이루어지지 않을 것이므로 새로운 project에 .NET Framework를 적용하는 것은 좋은 생각이 아닙니다.

 

(2) Mono와 Xamarin

 

Mono는 본래 Novell이라는 회사가 .NET Framework를 구현한 것으로 Windows는 물론 대부분의 Linux platform에서 실행이 가능해 사실상 .NET Framework보다도 더 cross-platform에 가까운 project라고 할 수 있습니다.

 

시간이 지나 Mono는 Microsoft가 2016년에 인수한 Xamarin에서 개발이 추진되었는데 현재 Xamarin을 mobile platform으로 본래 유료인 Xamarin확장기능을 Visual Studio에서 무료로 제공하고 있습니다. 이후 Microsoft는 Xamarin Studio development tool을 Visual Studio for Mac으로 변경하고 여기에 본래 mobile app개발기능과 더불어 console app과 web service와 같은 다른 유형의 project를 추가적으로 개발할 수 있도록 함으로써 현재의 Visual Studio for Mac를 완성시키게 됩니다.

 

Visual Studio 2022 for Mac에서 Microsoft는 개선된 경험성과 성능을 제공하기 위해 Xamarin Studio editor의 일부를 Windows용 Visual Studio 2022의 일부로 교체하기도 했으며 또한 작업과 신뢰도를 향상시킬 수 있도록 native macOS UI로 새롭게 재작성되기도 했습니다.

 

(3) .NET Core

 

근래에 들어 WIndows라는 운영체제는 mobile과 cloud개발에 있어 중요도가 점차 떨어지고 있습니다. 그도 그럴 것이 Microsoft는 2015년 부터 .NET을 Windows와 강력하게 결합되지 않도록 계속해서 노력해 왔기 때문입니다. .NET Framework를 진정한 cross-platform으로 다시 재작성하는 동안 Microsoft는 더 이상 핵심으로 여겨지지 않은 많은 주요 부분을 제거하고 재개발할 수 있게 되었습니다.

 

이렇게 완성된 초기 version을 .NET Core라고 불렀으며 CLR을 cross-platform으로 구현한 CoreCLR과 BCL을 비교적 간소화한 CoreFX를 포함하였습니다.

 

.NET Core는 각 app별로 나란히 배포됨으로써 어떠한 변경사항이 같은 machine상의 다른 .NET Core app에는 영향을 주지 않도록 할 수 있었으며 많은 개선이 이루어졌지만 Microsoft가 .NET Core와 .NET을 만든 이러한 개선점이 .NET Framework에는 적용될 수 없었습니다.

 

(4) .NET의 통합

 

2020년 5월 Microsoft Build 개발자 conference에서 .NET team은 .NET의 통합이 지연된 것에 대해서 발표하면서 mobile을 제외한 모든 .NET platform이 통합된  .NET 5가 2020년 11월 10일에 release 될 것이라고 언급하였고 그런 후 2021년 11월이 되어서야 비로소 mobile이 .NET Platform에서 지원되기 시작했습니다. 2021년 9월에는 mobile과 desktop app개발에 대한 Microsoft의 새로운 cross-platform인 .NET MAUI가 6개월 정도 지연된다고 발표하였고 2022년 5월이 되어서야 비로소 .NET MAUI가 GA(General Availability)에 release 되었습니다. 이에 대한 내용은 아래 link에서 더 살펴볼 수 있습니다.

 

Introducing .NET MAUI - One Codebase, Many Platforms - .NET Blog (microsoft.com)

Introducing .NET MAUI - One Codebase, Many Platforms - .NET Blog

.NET Core는 주요 버전이 3에서 4로 올라갈 때 4를 생략하고 5로 곧장 version을 올리면서 공식적으로 .NET이라는 이름으로 변경되었습니다. version 4를 생략한건 .NET Framework 4.x대의 버전과의 혼동을 피하기 위해서였습니다. Microsoft는 매해 11월 주요 version의 release를 계획했으며 이는 Apple이 iOS에 대한 주요 version의 release를 매해 9월에 하는 것과 비슷한 방식입니다.

 

아래 표에서는 .NET의 version이 release 될 때와 향후 계획된 release시기를 나타내고 있습니다.

Version	Release	출시일
.NET Core RC1	2015년 11월	2016년 3월
.NET Core 1.0	2016년 6월
.NET Core 1.1	2016년 11월
.NET Core 1.0.4 / .NET Core 1.1.1	2017년 3월	2017년 3월
.NET Core 2.0	2017년 8월
.NET Core for UWP in Windows 10 Fall Creators Update	2017년 10월	2017년 11월
.NET Core 2.1 (LTS)	2018년 5월
.NET Core 2.2 (Current)	2018년 12월
.NET Core 3.0 (Current)	2019년 9월	2019년 10월
.NET Core 3.1 (LTS)	2019년 12월
Blazor WebAssembly 3.2 (Current)	2020년 5월
.NET 5.0 (Current)	2020년 11월	2020년 11월
.NET 6.0 (LTS)	2021년 11월	2021년 11월
.NET 7.0 (Standard)	2022년 11월	2022년 11월
.NET 8.0 (LTS)	2023년 11월	2023년 11월
.NET 9.0 (Standard)	2024년 11월	2024년 11월
.NET 10.0 (LTS)	2025년 11월	2025년 11월

 

● Blazor WebAssembly의 version안내

 

.NET Core 3.1에서는 web component개발을 위한 Blazor Server가 포함되었습니다. 본래 Microsoft는 해당 release에 Blazor WebAssembly를 포함하고 싶었으나 이게 지연되면서 이후에 .NET Core 3.1에 선택적 add-on으로서 release 되었습니다. 이를 표에서는 Blazor WebAssembly 3.2로 표시하였습니다.

 

(5) .NET의 지원체계

 

.NET은 LTS(Long Term Support)와 이전에 Current로 알려진 Standard Term Support(STS) 또는 Preview로 release 됩니다.

• LTS : LTS는 안정화 version이며 일정 지원기간 동안 몇몇 update가 이루어질 수 있습니다. 잦은 update를 필요로 하지 않는 application의 경우에 적합한데 GA이후 3년간 또는 다음 LTS가 나온 후 1년 중 더 긴 기간으로 Microsoft에 의해 지원됩니다.
• STS 또는 Current : feedback으로 인해 변경될 수 있는 기능이 포함된 version입니다. 최신 개선사항에 대한 access를 제공하므로 비교적 개발작업이 활발하게 이루어지는 application에 적합합니다. STS는 GA이후 18개월간 또는 다음 STS / LTS가 나온 후 6개월 중 더 긴 기간으로 Microsoft에 의해 지원됩니다.
• Preview : 공개 test용으로서 최신의 언어기능과 Library, app platform으로의 사전접근이 가능하므로 실험적인 개발과정에서 도입하기에 알맞은 version입니다. Preview나 RC(Release Candidate는 GA(일반 공급) release 직전의 release 후보 build이며 지원되는 별도의 기간은 없습니다.

Standard나 LTS는 수명주기동안 보안과 안정성에 관련된 중대한 수정이 이루어지는데 지속적인 지원을 받기 위해서는 항상 최신의 update상태를 유지하는 것이 좋습니다. 예를 들어 system이 1.0.0에서 동작중이고 1.0.1이 release 되었다면  지속적인 지원을 위해 1.0.1의 설치가 필요한 것입니다. 참고로 .NET 8부터는 Patch Tuesday라고 하여 매월 두 번째 화요일에 update가 release됩니다.

End of support와 end of life는 bug수정과 보안 update 된 날짜를 의미하며 Microsoft로부터의 기술지원은 더 이상 가능하지 않습니다.

 

Microsoft로부터 장기간지원(LTS)을 받아야 한다면 Microsoft가 .NET 9.0을 2024년 release하더라도 .NET 8.0을 사용해야 합니다. .NET 9은 STS이므로 .NET 8이 2026년 11월 지원이 종료되기 전인 2026년 5월에 지원이 종료되기 때문입니다. .NET 10이 출시되면 그때 update를 진행해야 합니다.

version과는 상관없이 모든 release에서 .NET runtime 8.0.1이나 .NET SDK 8.0.101과 같은 bug-fix는 update해야 하며 이들은 매달 이루어질 것입니다.

 

2023년 11월 배포당시 .NET Core와 .NET의 모든 version은 아래 version을 제외하고 수명종료에 도달하게 되었습니다.

• .NET 7.0은 2024년 5월에 지원이 종료됩니다.
• .NET 6.0은 2024년 11월에 지원이 종료됩니다.
• .NET 8.0은 2026년 11월에 지원이 종료됩니다.

각 version에 대한 지원 및 종료에 대한 주기는 아래 link에서 자세히 확인할 수 있습니다.

core/releases.md at main · dotnet/core · GitHub

GitHub - dotnet/core: Home repository for .NET Core

 

● .NET 지원에 관한 단계이해

Preview	별도의 지원이 없습니다. .NET 8 Preview 1에서 Preview 7까지도 2023년 2월부터 8월까지 이 단계에 있었습니다.
Go Live	GA까지 지원되며 그 이후에는 지원되지 않으므로 가능한 경우 즉각 update해야 합니다. .NET 8 Release Candidate 1과 Release Candidate 2도 2023년 9월 부터 10월까지 이 단계에 있었습니다.
Active	.NET 8이 2023년 11월부터 2026년 10월까지 이 단계에 머무르게 됩니다.
Maintenance	생명주기상 마지막 6개월간을 이 기간으로 봅니다. 해당 기간동안에는 보안관련 update만이 지원됩니다. .NET 8이 2026년 5월부터 11월까지 이 상태에서 머무르게 됩니다.
End-of-life	별도의 지원이 없습니다. .NET 8은 2026년 11월에 이 상태에 들어가게 됩니다.

 

● .NET Runtime과 .NET SDK version의 이해

 

.NET Runtime version의 부여는 semantic방식을 따르고 있으므로 주요 version의 증가는 큰 변경사항을, 부 version의 증가는 새로운 기능의 추가를, patch version은 bug가 수정된 것임을 나타냅니다.

 

.NET SDK는 semantic을 따르지 않으며 주와 부 version모두 runtime version과 일치되고 patch에서 SDK에 대한 주와 부 version을 표시하는 방식을 따르고 있습니다.

 

아래 표에서는 Runtime과 SDK 간 version에 대한 변화를 확인할 수 있습니다.

Rumtime	SDK	Description
8.0.0	8.0.100	초기 version
8.0.0	8.0.101	SDK의 bug fix
8.0.1	8.0.102	Runtime과 SDK의 bug fix
8.0.1	8.0.200	SDK에 새로운 기능이 추가됨

 

● 설치된 .NET 확인

 

.NET Runtime update는 8.x와 같이 주요 version안에서 이루어 지며 .NET SDK의 update 된 release는 runtime의 이전 version을 대상으로 하는 application을 build 할 수 있도록 유지함으로써 이전 version을 안전하게 삭제할 수 있습니다.

 

우선 아래 명령을 통해 현재 설치된 runtime과 SDK의 version을 확인합니다.

dotnet --list-sdks dotnet --list-runtimes dotnet --info

 

Windows에서는 제어판의 Program추가/제거에서 .NET SDK를 삭제할 수 있으며 macOS(Windows도 마찬가지)에서는 dotnet-core-uninstall도구를 사용할 수 있습니다. 다만 해당 도구는 기본적으로 설치되지 않기 때문에 따로 내려받아야 합니다.

 

자세한 사항은 아래 link를 참고하시기 바랍니다.

Uninstall Tool - .NET | Microsoft Learn

Uninstall Tool - .NET

 

(6) .NET Framework와 .NET의 차이

 

.NET은 획일적인 .NET Framework에 비해 기능적으로 module화 되었으며 Microsoft는 .NET을 open-source화 함은 물론 성능적인 향상을 위해서도 많은 노력을 기울여오고 있습니다.

 

특히 .NET은 .NET Framework에서 GUI(Graphical User Interface) application개발에 필요한 Windows Forms나 WPF(Windows Presentation Foundation)와 같은 비-corss-platform기술을 제거함으로써 훨씬 더 가벼운 상태를 유지할 수 있게 되었습니다. 이러한 기술은 사실상 Windows생태계에 강력하게 연결됨으로 인해 .NET의 주요 목적인 cross-platform에는 전혀 맞지 않는 부분이었습니다.

 

● Windows GUI Application 개발

 

.NET자체에서는 Windows Forms나 WPF가 제거되었지만 필요하다면 Windows Desktop Pack을 사용해 해당 application을 개발할 수 있습니다. 물론 이렇게 하면 macOS나 Linux의 SDK보다는 훨씬 무거워지겠지만 .NET Framework에서 개발된 legacy Windows desktop application을 .NET으로 rebuild함으로서 .NET의 새로운 기능과 성능적인 향상에 대한 이점을 가져올 수 있습니다.

 

● Web 개발

 

.NET Framework에서 사용되던 ASP.NET Web Forms와 WCF(Windows Communication Foundation)은 .NET에 와서 폐기되었으며 새로운 project에 위 기술을 사용하는 것은 권장하지 않습니다. 대신 ASP.NET MVC, ASP.NET Web API, SignalR, gRPC와 같은 최신의 기술이 ASP.NET Core라는 이름으로 .NET에서 동작하는 platform으로 결합되었고 이를 통해 사용하던 개발방식을 대체하여 사용할 수 있습니다.

 

소수의 .NET Framework개발자는 ASP.NET Web Forms, WCF, WF(Windows Workflow)등의 기술을 .NET에 와서도 계속 사용하고자 했습니다. 덕분에 .NET으로 WCF와 WF의 개발이 가능하도록 하는 open-source project가 존재하며 아래 link를 통해 자세한 내용을 확인해 볼 수 있습니다.

 

Supporting the community with WF and WCF OSS projects - .NET Blog (microsoft.com)

Supporting the community with WF and WCF OSS projects - .NET Blog

Core WCF 1.0은 2022년 4월에 release 되었으며

 

CoreWCF 1.0 has been Released, WCF for .NET Core and .NET 5+ - .NET Blog (microsoft.com)

CoreWCF 1.0 has been Released, WCF for .NET Core and .NET 5+ - .NET Blog

Blazor Web Forms component에 대한 open-source project도 같이 확인해 볼 수 있습니다.

 

GitHub - FritzAndFriends/BlazorWebFormsComponents: A collection of Blazor components that emulate the ASP.NET Web Forms controls of the same name

GitHub - FritzAndFriends/BlazorWebFormsComponents: A collection of Blazor components that emulate the ASP.NET Web Forms controls

● Database 개발

 

EF(Entity Framework)는 Oracle과 SQL Server 등 관계형 database를 통해 data에 대한 작업이 가능하도록 설계된 개체-관계 mapping기술입니다. 지난 몇 년간 많은 발전을 이루게 되었으며 cross-platform API도 간소화되어 이제는 Azure Cosmos DB와 같은 비관계형 database에 대한 지원도 가능해졌습니다. 현재는 Entity Framework Core로 명칭이 바뀌었으며 성능적인 향상이 지속적으로 이루어지고 있습니다.

 

(7) .NET Standard

 

2019년 당시 .NET은 Microsoft의 주도하에 3가지 platform으로 분기되어 있었습니다.

• .NET Core : corss-platform application 개발
• .NET Framework : legacy application을 위한 framework
• Xamarin : mobile app 개발

각각의 platform은 저마다 다른 scenario에서 설계되었기 때문에 그에 맞는 강력함과 취약한 면을 동시에 가지고 있습니다.  문제는 개발자가 해당 platform에 맞는 app의 개발을 위해 3가지의 platform을 모두 배워야 한다는 것입니다.

 

이러한 문제로 인해 Microsoft는 모든 .NET platform이 구현해야 하는 일련의 API명세인 .NET Standard를 정의함으로서 호환성 수준을 나타내게 되었습니다. .NET Standard 1.4에 이어 .NET Standard 2.0에 와서 Microsoft는 3개의 platform을 모두 포괄하는 최소표준으로 만들게 되었으며 이로 인해 개발자들은 모든 .NET간 code를 쉽게 공유할 수 있게 되었습니다.

 

.NET Core 2.0이상의 경우에는 개발자들이 .NET Framework에서 작성된 code를 cross-platform인 .NET Core의 code로 이식하는데 필요한 API 들어 대거 추가되었습니다. 그러나 일부 API가 구현됨에도 불구하고 개발자들에게는 실제 사용해서는 안된다는 예외를 표시하기도 하였는데 이는 .NET이 동작하는 OS에서의 차이 때문입니다.

 

.NET Standard는 그저 표준일 뿐이라는 점을 이해하는 것은 중요한데 우리가 HTML5를 설치할 수 없는 것처럼 .NET Standard는 별개로 설치될 수 있는것이 아닙니다. HTML5를 사용하기 위해서는 HTML5의 표준을 구현하는 web browser를 설치해야 하는 것처럼 .NET Standard를 사용하기 위해서는 .NET Standard 표준명세를 구현하는 .NET Platform을 설치해야 합니다. 가장 최신의 .NET Standard는 2.1이며 .NET Core 3.0, Mono, Xamarin에 의해 구현됩니다. C# 8.0의 몇몇 기능은 .NET Standard 2.1을 필요로 하며 .NET Framework 4.8에서는 .NET Standard 2.1이 구현되지 않습니다.

 

.NET 5와 그 이후부터는 mobile을 포함한 모든 platform에 대한 단일 .NET으로 전환되어 .NET Standard의 필요성이 현저하게 줄어들게 되었습니다. .NET부터는 단일 BCL과 website 및 Windows desktop application과 같이 server나 desktop에 최적화된 CoreCLR과 제한된 resource를 가진 mobile과 web browser app에 최적화된 Mono runtime이라는 2개의 CLR을 가집니다.

 

2021년 8월 .NET의 Partner Software Engineer인 Stephen Toub은 자신의 blog에 작성한 'Performance Improvements
in .NET 6.'라는 글에서 'about Blazor and Mono'부분에 다음과 같이 언급한 바 있습니다.

runtime자체는 browser로 download 되고 WASM으로 compile 되어 app에 의존하는 application 및 library code를 실행하는 데 사용된다. 나는 여기서 'runtime'이라고 했지만 사실은 .NET runtime에 대한 다중 구현체가 존재한다. .NET6에서 모든 .NET app model에 대한 모든 .NET Core library는 console app이든 ASP.NET Core든 또는 Blazor WASM이든 mobile app이든 dotnet runtime에서 동일한 source를 통해 제공되지만 실제로는 'coreclr'과 'mono'라는 2개의 runtime 구현이 있는 것이다.

2개의 runtime에 대한 좀 더 자세한 내용은 아래 link를 참고하시기 바랍니다.
https://devblogs.microsoft.com/dotnet/performance-improvements-in-net-6/#blazor-and-mono

 

Performance Improvements in .NET 6 - .NET Blog

그래도 여전히 .NET Framework에서 생성된 app과 website의 지원이 필요하다면 legacy .NET platform과의 역호환성을 가진 .NET Standard 2.0 class library를 생성할 수 있습니다.

.NET Standard 역시 지금은 legacy로 분류됩니다. .NET Standard에 대한 새로운 version은 없을 것이며 현재 GitHub repository에서 확인할 수 있습니다. 이에 대한 자세한 사항은 아래 link를 참고하시기 바랍니다.
https://twitter.com/dotnet/status/1569725004690128898

 

(8) IL(intermediate language)

 

dotnet CLI tool에서 사용되는 Roslyn이라는 이름의 C# compiler는 C# source를 IL code로 변환하고 이를 DLL이나 EXE형태의 assembly로 IL을 저장합니다. IL구문자체는 assembly언어의 명령어와 비슷한데 CoreCLR이라고 알려진 .NET의 가상 machine에서 실행됩니다.

 

runtime에서 CoreCLR은 assembly에서 IL을 load 하고 이를 JIT(just-in-time) compiler가 실제 CPU의 명령어로 compile 함으로써 CPU가 명령을 실행하는 방식으로 진행됩니다.

 

이러한 2단계에 걸친 compile처리방식으로 인해 Microsoft는 Windows는 물론이고 Linux나 macOS에 맞는 CLR을 만들어두게 됨으로써 CLR(.NET runtime)만 설치되어 있으면 동일한 IL code를 어디서든 실행할 수 있게 되었습니다.  2번째 compile과정을 통해 해당 OS와 CPU명령에 맞는 native code를 생성할 수 있기 때문입니다.

 

C#, Visual Basic, F#등 source code가 작성된 언어와는 상관없이 모든 .NET application은 assembly안에 자신들의 명령어에 대응하는 IL을 사용하는데 이러한 특징으로 인해 Microsoft와 기타 다른 제삼자가 만든 disassembler도구(ILSpy .NET Decompiler 확장도구와 같은)를 제공할 수 있게 되었고 이 도구로 assembly을 열어 IL code를 들여야 볼 수도 있습니다.

 

(9) .NET 기술의 비교

 

지금까지 설명드린 .NET기술은 아래 표와 같이 요약해 볼 수 있습니다.

기술	설명	OS
.NET	최신의 .NET기술이며 C# 8 ~ 12까지의 version을 완벽하게 지원하고 이전 version으로 만들어진 app을 이식하거나 새로운 desktop, mobile, web application및 service를 생성할 수 있습니다.	Windows, macOS, Linux, Android, iOS, Tizen
.NET Framework	고전의 .NET기술이며 C# 8까지의 지원으로 제한되어 9 version이상은 지원하지 않습니다. 기존의 application을 유지관리하는데만 사용되어야 합니다.	Windows 전용
Xamarin	Mobile과 desktop application전용	Android, iOS, macOS

 

3. Visual Studio 2022를 사용한 Console app 생성

 

(1) Visual Studio 2022를 통한 다중 project관리

 

Visual Studio 2022는 여러 project를 동시에 열고 관리할 수 있도록 solution이라는 이름의 개념을 도입하고 있습니다. 이에 따라 2개의 project를 생성하고 이를 관리하기 위해 solution을 사용해 볼 것입니다.

 

(2) Visual Studio 2022를 사용한 code작성

 

Visual Studio 2022를 실행하고 'Start window'에서 'Create a new project'를 click 합니다. 'Create a new project'에서 'Search for templates'에 'console'을 입력하거나 list에서 'Console App'을 찾습니다. 이때 해당 project가 C#이고 Windows전용의 .NET임을 확인합니다.

'Next'를 click 하고 'Configure your new project'에서 project의 이름으로 'HelloCS'를 입력한 뒤 그 상태에서 'Next'를 click 합니다.

 

'Additional information'의 'Framework'를 여러 version의 .NET을 선택할 수 있음을 알 수 있는데 여기서는 .NET 7.8을 선택하도록 하겠습니다. 만약 원하는 .NET SDK의 version이 나오지 않는다면 아래 주소에서 필요한 .NET SDK를 내려받아 설치할 수 있습니다.

 

.NET Downloads (Linux, macOS, and Windows) (microsoft.com)

.NET Downloads (Linux, macOS, and Windows)

참고로 하단에 있는 'Do net use top-level statements'는 check 하지 않습니다. .NET 8.0을 선택하면 'Enable native AOT publish'도 볼 수 있는데 이것도 check하지 않도록 합니다. 이에 관한 자세한 내용은 추후에 알아볼 것입니다. 이제 끝으로 'Create'를 click 해 project를 생성하면 다음과 같은 화면이 보일 것입니다.

code를 보면 주석과 단일 문장하나만 존재하는 간소한 code가 생성되어 있음을 알 수 있는데 이는 C# 9에서 도입된 top-level program기능이 사용되었기 때문입니다. 예제에서의 'Hello, World!'를 가단 하게 'Hello, World! C#'로 변경해 봅니다.

 

(3) code의 Compile과 동작

 

Visual Studio에서 'Debug' menu에 'Start Without Debugging'를 선택합니다.

Visual Studio 2022에서 project를 시작할 때 debugger의 실행여부를 선택할 수 있습니다. 만약 debug가 필요하지 않다면 debugger는 실행하지 않는 것이 좋습니다. 왜냐하면 debugger의 실행은 더 많은 resource를 필요로 하며 모든 면에서 더 느리게 작동할 수 있기 때문입니다. debugger의 실행은 또한 하나의 project에서만 가능하도록 제한됩니다. 따라서 하나 이상의 project를 각각의 debugger와 함께 실행해야 한다면 필요한 수만큼 Visual Studio을 따로 실행해서 project를 동작시켜야 합니다. 하지만 debug가 필요하지 않다면 전체가 녹색인 삼각형 button대신 toolbar에서 녹색선의 삼각형 모양 button을 click 하여 빠르게 여러 project의 application을 실행시켜 볼 수 있습니다.

 

위와 같이 실행하면 해당 project의 application이 실행되어 다음과 같이 console window의 화면을 보게 될 것입니다.

 

이 상태에서 아무 key나 누르게 되면 console app window가 닫히고 Visual Studio로 돌아가게 됩니다. 참고로 Visual Studio의 Solution Explorer에서 project를 double-click 하게 되면 project의 csproj file을 볼 수 있는데 여기에서는 해당 project의 .NET target이 .net7.0 혹은 .net8.0과 같은 값을 통해 무엇인지를 정확하게 확인할 수 있습니다. 또한 'Show All Files' button을 눌러보면 compiler에서 생성된 bin과 obj folder를 추가적으로 표시하게 됩니다.

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net8.0</TargetFramework>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>
  </PropertyGroup>

</Project>

 

● compiler로 생성된 folder와 file

 

compiler는 project folder에 obj와 bin이라는 2개의 folder를 생성하는데 사실 아직까지는 이 folder와 내부의 file이 어떤 것인지에 대해서는 알 필요가 없지만 최소한 compiler가 작동하기 위해서는 이 2개의 folder와 내부에 생성된 file이 필요하다는 것을 알고 있어야 합니다. 만약 해당 folder나 file을 임의로 삭제한다고 하더라도 project를 실행하거나 build 하게 되면 자동적으로 해당 folder와 file이 다시 생성됩니다.(Visual Studio의 Solution Explorer에서 project에 mouse오른쪽 button을 누르면 Clean이라는 menu항목이 보이는데 이 menu를 통해서도 비슷한 동작을 수행할 수 있습니다. project가 아닌 Solution단위에서는 Clean Soluton이라는 이름의 menu입니다.) 아래 표에서는 obj와 bin이 어떤 file을 포함하고 있는지에 대한 간단한 안내를 표시하고 있습니다.

obj	각 source code file에 대한 compile된 개체를 포함하지만 해당 개체는 최종 실행가능한 형태로 연결되지 않았습니다.
bin	application이나 class library로 실행가능한 binary를 포함합니다.

 

(4) Top-level Program

 

.NET을 예전부터 다뤄봤다면 간단한 message하나를 표시하는데도 꽤 많은 code가 사용되었었다는 것을 알고 있을 것입니다. 그러나 예제를 보면 주석을 빼고 단 한줄로만 이루어진 code를 볼 수 있습니다. 이는 .NET 6이후에서 compiler가 일부code를 대신 작성해 주는 기능이 있기 때문입니다.

 

.NET SDK 5.0이나 그 이전 version을 통해 project를 생성하거나 이전에 project를 생성하는 과정에서 'Do net use top-level statements'부분에 check를 하고 진행했다면 Program.cs는 아마도 아래와 같이 더 많은 code를 담게 되었을 것입니다.

using System;

namespace HelloCS
{
	class Program
	{
		static void Main(string[] args)
		{
			Console.WriteLine("Hello, World!");
		}
	}
}

 

.NET SDK 6 이후에서 compile 하는 동안에는 namespace와 Program class 그리고 Main method를 정의하는 모든 상용구 code가 생성되며 위 예제와 같이 작성된 code주위를 감싸게 됩니다. 이것은 Microsoft가 .NET 5에서 top-level program이라는 이름으로 소개한 것으로 .NET 6에 와서야 비로소 console app project template에서 기본적으로 사용되도록 update 되었습니다.

 

top-level program은 필요한 code를 감춰주는 것일 뿐, 필요 없어서 생략된 것이 아니기 때문에 기억해야 할 몇 가지 사항이 존재합니다.

• 위 예제에서와 같이 project에서 단 하나의 file에서만 적용될 수 있습니다.
• 모든 using 구문은 file의 상단에 위치해야 합니다.
• class나 type에 대한 선언은 file의 하단에 위치해야 합니다.
• Main method를 지정해야 하는 경우 method의 이름을 Main으로 해야 하지만 compiler 될 때의 method이름은 '<Main>$'가 됩니다.

● 암시적인 namespace import

 

file상단에서 'using System;' 구문이 있어야지만 System namespace가 import 되고 이로 인해 Console.WriteLine구문이 실행될 수 있습니다. 그런데 예제에서는 해당 구문이 없이도 Console.WriteLine가 동작할 수 있습니다. 이렇게 되는 이유는 C#10과 .NET 6에서 소개된 기능이 복합적으로 사용되었기 때문입니다.

 

Visual Studio의 Solution Explorer에서 obj folder와 Debug folder, net7.0 foler를 차례로 확장하면 HelloCS.GlobalUsings.g.cs file이 보이는데 이 file을 열어보면 아래와 같은 code가 들어가 있음을 알 수 있습니다.

// <auto-generated/>
global using global::System;
global using global::System.Collections.Generic;
global using global::System.IO;
global using global::System.Linq;
global using global::System.Net.Http;
global using global::System.Threading;
global using global::System.Threading.Tasks;

 

해당 file은 .NET 6 이후로 target이 맞춰진 project의 compiler에 의해서 자동으로 생성된 것이며 C#10에서 소개된 'global namespace imports'기능을 사용하고 있는 것입니다. 해당 기능은 위에서 보이는 바와 같이 모든 code file에서 사용되는 System과 같은 공통적인 namespace를 import 합니다.

 

좀 더 상세한 부분은 나중에 다시 살펴보겠지만 .NET5와 .NET6간 중요한 변화는 console app과 같은 대부분의 project template이 새로운 SDK와 언어기능을 사용함으로써 실제 일어나는 일을 감출 수 있다는 것입니다.

 

● 예외를 통한 숨겨진 code 보기

 

Program.cs file에서 아래와 같이 예외를 throw 하는 구문을 추가합니다.

// See https://aka.ms/new-console-template for more information
Console.WriteLine("Hello, World! C#");
throw new Exception();

 

그리고 Visual Studio에서 'Debug/Start Without Debugging' menu를 통해 project를 실행합니다. (debugging을 동반해서는 안됩니다.) 그러면 다음과 같이 console화면이 열려 compiler에 의해 정의되어 Program class에서 숨겨진 <Main>$이름의 method와 인수를 전달하기 위한 args이름의 매개변수를 포함해 application실행에 대한 결과를 표시하게 됩니다.

 

● Program class의 namespace확인하기

 

Program.cs에서 다음과 같이 기존의 문에서 Program clsss의 Namespace이름을 확인하는 문으로 변경합니다.

string name = typeof(Program).Namespace ?? "None!";
Console.WriteLine($"Namespace: {name}");

예제에서 ??은 null병합연산자로서 Namespace가 null이면 'None!'반환하라는 의미를 가집니다.

 

예제를 실행하면 다음과 같은 결과를 표시할 것입니다.

 

이를 통해 우리는 Top-level program으로 자동생성된 경우 code는  Namespace를 정의하지 않는다는 것을 알 수 있습니다. 따라서 Program는 암시적으로 Namespace없이 정의됩니다.

 

(5) Visual Studio 2022에서 두 번째 project 추가하기

 

Visual Studio에서 File/Add/New Project menu를 선택하고 'Add a new project'의 'Recent project templates'에서 Console App [C#]을 선택하고 Next를 click 합니다.

 

'Configure your new project'에서 Project이름에 'AboutMyEnvironment'를 입력하고 'Next'를 click 합니다. 그 다음 'Additional information'에서 '.NET 8.0'을 선택하고 'Create'를 click합니다.

 

이제 AboutMyEnvironment project의 Program.cs를 열고 아래와 같이 현재 directory와 OS version을 표시하는 구문을 추가합니다.

// See https://aka.ms/new-console-template for more information
Console.WriteLine(Environment.CurrentDirectory);
Console.WriteLine(Environment.OSVersion.VersionString);

 

Visual Studio의 Solution Explorer에서 AboutMyEnvironment project에 mouse오른쪽 button을 click한뒤 'Set Startup Project'를 선택합니다. 그러면 해당 project의 이름이 진하게 변경되면서 해당 project가 시작 project로 설정되었음을 표시하게 됩니다. 이제 Debug/Start Without Debugging menu를 사용해 AboutMyEnvironment project를 실행하면 다음과 같은 결과를 볼 수 있습니다.

 

실제 Windows 11 OS를 사용하는 경우에도 Window NT 10으로 표시될 수 있습니다. Windows 11은 branding일 뿐이며 공식적인 주요 version은 여전히 10입니다.

Visual Studio 2022 for Windows를 사용해 console app을 실행할 때 app은 [project명]\bin\Debug\net8.0 folder에서 실행됩니다.

 

4. Visual Studio Code를 사용한 console app 만들기

 

Visual Studio 2022에서 가능한 대부분의 app은 Visual Studio Code와 CLI(Command Line Interface)를 통해서도 생성할 수 있습니다. 그러나 무엇을 사용하든 취향의 문제일 수 있기 때문에 만약 Visual Studio Code를 사용하고 싶지 한다면 이 부분은 그냥 넘어가도 괜찮습니다.

 

지금부터 설명되는 부분은 Windows에서의 작업을 기준으로 하지만 같은 작업을 macOS와 Linux에서의 Visual Studio Code와 동일하게 수행할 수 있습니다. 다만 command에서의 file삭제와 같은 명령이나 경로지정에서 차이가 생길 수는 있으나 CLI Tool은 모든 platform에서 동일합니다.

 

(1) Visual Studio Code에서 다중 project관리

 

Visual Studio Code에서는 workspace라는 개념을 가지고 있어서 이를 통해 여러 project를 묶어 관리할 수 있습니다.

 

(2) Visual Studio Code에서 code 작성하기

 

Visual Studio Code를 실행합니다. 아직 어떤 file이나 folder도 열지 않습니다. 'File/Save Workspace As...' menu를 선택해 test 하고자 하는 경로를 지정합니다. 여기에 'New Folder' button을 click한뒤 해당 folder안에서 'mywork1'이름의 folder를 생성합니다. 그리고 해당 folder안에서 'mywork1-workspace'이름으로 workspace를 저장합니다.

 

다시 Visual Studio Code에서 'File/Add Foler to Workspace...'을 선택하고 해당 folder안에서 'HelloCS'이름의 folder를 생성한 뒤 해당 folder를 선택하고 하단의 'Add' button을 눌러줍니다. 그러면 Visual Studio Code의 해당 workspace에 지정한 folder가 추가되어 있음을 알 수 있습니다.(다른 file이나 folder를 신뢰할 것인지 묻는 화면이 나올 수 있습니다. 그런 경우 'Yes'를 선택해 줍니다.)

 

이제 Terminal(command line)을 열고 위에서 추가한 HelloCS folder로 이동한 뒤 새로운 console app을 만들기 위한 아래 CLI명령을 실행합니다.

dotnet new console

 

위 명령은 기본적으로 system에 설치된 가장 높은 version의 .NET SDK를 target으로 하는 project를 생성하게 됩니다. 만약 다른 version을 사용해야 한다면 아래와 같이 -f를 사용하여 원하는 .NET version을 지정해 줄 수 있습니다.

dotnet new console -f net6.0

 

이제까지의 과정을 거치면 최종적으로 Visual Studio Code의 EXPLORER창에는 다음과 비슷한 folder와 file이 생성된 결과를 표시할 것입니다.

 

생성된 project를 보면 해당 folder의 이름과 동일함을 알 수 있습니다. 이것은 기본적인 동작으로 만약 project와 해당 project가 저장될 folder를 동시에 생성하고자 한다면 -o option을 통해 원하는 이름을 지정해 주면 됩니다.

dotnet new console -o HelloCS

 

마지막으로 Program.cs file을 열어 이전과 동일하게 'Hello, World!'부분을 'Hello, World! C#'으로 변경합니다.

 

(3) dotnet CLI를 사용한 code의 compile과 실행

 

Terminal을 열어 해당 project가 존재하는(*.csproj file이 있는) folder로 이동한 뒤 아래 명령을 통해 project를 실행합니다.

dotnet run

 

혹은 Visual Studio Code의 'View/Terminal'에서도 명령을 실행할 수 있습니다. 그러면 application이 실행된 결과를 아래와 같이 표시하게 됩니다.

Hello, World! C#

 

다시 Program.cs에서 아래와 같이 예외를 일으키는 구문을 추가하고

// See https://aka.ms/new-console-template for more information
Console.WriteLine("Hello, World! C#");
throw new Exception();

 

이전과 동일한 방법으로 project를 실행하면 Visual Studio 2022에서 봤었던 것과 동일한 결과를 표시하게 될 것입니다.

 

(4) Visual Studio Code에서 project 추가하기

 

하나의 workspace에 다른 project를 추가하려면 Visual Studio Code의 'File/Add Folder to Workspace...' menu를 선택하고 'mywork1'folder로 이동한 뒤 'AboutMyEnvironment'이름의 새로운 folder를 생성하고 'Add' button을 눌러줍니다. 그런 뒤 Terminal에서 이전과 같은 방법으로 새롭게 만든 folder안에서

dotnet new console

 

명령어로 project를 추가해 줍니다.

 

이제 Visual Studio Code의 EXPLORER에서 위에서 추가한 project folder의 Program.cs file을 열고 아래와 같이 현재 directory와 OS version을 표시하는 구문으로 변경합니다.

Console.WriteLine(Environment.CurrentDirectory);
Console.WriteLine(Environment.OSVersion.VersionString);

 

그런 다음 Terminal에서

dotnet run

 

명령어로 project를 실행하면 다음과 같은 결과를 볼 수 있을 것입니다.

 

Visual Studio Code를 사용할 때, 좀더 정확하게는 dotnet CLI를 사용할때 console app은 해당 project의 folder에서 실행되지만 Visual Studio 2022의 경우 '<project명>\bin\Debug\net8.0'과 같은 folder의 위치에서 실행됩니다.

 

5. Project의 Folder구조와 File

 

이미 언급한 바와 같이 Visual Studio 2022에서는 여러 project를 동시에 관리하기 위한 개념으로 Solution file(*.sln)을 사용합니다. 이전에 2개의 project를 생성했는데 각각의 project의 folder와 file을 구조적으로 표현하면 다음과 같이 나타낼 수 있습니다.

(1) Visual Studio 2022와 Visual Studio Code 간 호환성

 

Visual Studio Code에서는 .code-workspace를 사용하고 Visual Studio 2022에서는 .sln file을 통해 다중 project를 관리하지만 HelloCS와 AboutMyEnvironment와 같은 project의 folder와 file은 동일하게 취급될 수 있습니다. 따라서 Visual Studio 2022에서는 'File / Add Existing Project...' menu를 통해 Visual Studio Code에서 작성된 project를 불러올 수 있으며 Visual Studio Code에서는 'File / Add Folder to Workspace...' menu를 통해 Visual Studio 2022에서 작성된 project를 불러올 수 있습니다.

비록 .csproj와 .cs file과 같은 source code는 동일하지만 compiler에 의해 자동적으로 생성된 bin과 obj folder는 오류를 표시하는 file version이 일치하지 않을 수 있습니다. 만약 Visual Studio 2022에서 생성된 project를 열 때 Visual Studio Code에서 오류가 발생하는 경우 bin과 obj folder를 삭제하고 다시 시도해야 합니다.

6. 도움말 얻기

 

(1) Microsoft 문서

 

Microsoft 개발자 도구와 platform에 관한 도움을 얻기 위한 최종적인 resource는 Microsoft 문서이며 아래 link를 통해 찾아볼 수 있습니다.

 

Microsoft Learn: Build skills that open doors in your career

Microsoft Learn: Build skills that open doors in your career

 

(2) dotnet tool에서 도움말 얻기

 

terminal과 같은 command line에서 특정 project를 생성할 때 dotnet tool로부터 도움말을 확인해 보려면 -h 또는 --help option을 사용할 수 있습니다. 예를 들어 console project를 생성하는데 필요한 도움말은 다음과 같은 명령으로 확인해 볼 수 있습니다.

dotnet new console -h

 

(3) type에 대한 정의와 member확인

 

특정 type에 대한 정의와 해당 type의 member를 확인하는 가장 일반적인 방법은 code editor에서 'Go To Definition'을 사용하는 것입니다. 이 기능은 Visual Studio Code와 Visual Studio 2022에서 모두 가능하며 source link나 compile 된 assembly의 metadata를 읽음으로써 type이나 해당 type의 member를 표시할 것입니다.

 

ILSpy .NET Decompiler와 같은 몇몇 도구에서는 metadata와 IL code에서 C#이나 다른 언어로 변환하는 reverse-engineer기능을 제공하기도 합니다.

 

실제 Visual Studio 2022에서 해당 기능을 살펴보기 위해 HelloCS project의 Program.cs file을 열고 아래와 같이 int형 변수인 a를 선언합니다.

int a;

 

그리고 int부분에서 mouse 오른쪽 button을 눌러 'Go To Definition'을 click 하면 code editor안에서 int data type이 어떻게 정의되어 있는지를 직접 확인해 볼 수 있습니다.

 

이와 같은 방식에 따라 int는 struct keyword로 정의되었으며 System.Runtime assembly에 속해 있고 System namespace안에 포함되어 있다는 것을 알 수 있으며 또한 Int32라는 이름을 갖고 있고 IComparable와 같은 interface를 구현하고 있으며 최대치와 최소치에 대한 constant값과 Parse와 같은 method도 갖고 있음을 알 수 있습니다.

 

(4) Stack Overflow에서 도움말 찾기

 

Stack Overflow는 가장 인기 있는 third-party webite 중 하나로서 programming과정에서의 많은 질문들에 대한 답을 볼 수 있는 곳입니다. 이러한 service의 인기가 높아짐에 따라 해당 site를 검색하기 위한 특별한 기능을 가진 DuckDuckGo와 같은 검색 engine의 인기도 덩달아 높아졌습니다.

 

(5) Google을 사용한 검색

 

많은 개발자들은 원하는 답을 찾기 위해 Google검색을 이용하기도 합니다. 그런데 이러한 검색 engine을 이용할 때도 약간의 tip이 필요한데 단순검색에서는 검색에 입력한 단어에 대해 정말 필요한 답을 찾기 이전에 아무 관련 없는 내용들을 먼저 보게 되는 경우가 많습니다. 이런 경우 아래와 같이 Stack Overflow와 같은 site로 제한된 범위의 검색을 시도하고 JAVA, Rust와 같은 알고 싶지 않은 다른 언어를 제외하거나 C#과 .NET을 명시적으로 추가하는 방법을 통해 검색의 정확성을 향상할 수 있습니다.

webclient site:statckoverflow.com +C# -Java

 

(6) 공식 .NET Blog 활용하기

 

.NET에 대한 최신정보를 얻으려면 .NET engineering team에 의해 작성된 공식 .NET blog에 정기적으로 방문해 보는 것이 좋습니다.

 

.NET Blog (microsoft.com)

.NET Blog

 

(7) Chat GPT

 

Visual Studio에서는 다음과 같은 확장 기능을 통해 Chat GPT를 사용할 수 있으며

 

Visual chatGPT Studio - Visual Studio Marketplace

Visual chatGPT Studio - Visual Studio Marketplace

 

Visual Studio Code에서도 확장기능을 통해 Chat GPT의 사용을 지원하고 있습니다.

 

AI Code Helper | aicodehelper

AI Code Helper

 

이 외에도 다양한 확장도구가 존재할 수 있으니 참고하시기 바랍니다.