[열세번째 C#] C# 세계에 온걸 환영합니다!

1. 시작하기 전에

 

우선 C# Programming을 시작하기 전에 개발환경을 갖추는 것부터 시작할 것입니다. 실력 없는 목수가 연장 탓을 한다지만 그것도 연장이 있을 때 얘기죠. 개발자에게 필요한 연장은 개발도구라고 할 수 있고 원하는 개발작업을 위해서는 개발도구에 대한 적절한 환경설정이 되어 있어야 할 것입니다.

 

C# 개발에 필요한 연장은 다양하겠지만 우리가 주로 다루게 될 연장은 Visual Studio Code와 Visual Studio 2022입니다. 앞으로의 설명도 이 2가지를 중심으로 진행할 것이므로 Visual Studio Code나 Visual Studio 2022둘중 하나는 반드시 설치되어 있어야 합니다. 물론 2가지를 다 갖추고 있어도 됩니다.

Visual Studio Code와 Visual Studio 2022에 대한 명칭은 앞으로 각각 VSCode와 VS2022로 줄여서 표현하고자 합니다.

 

개발환경과 함께 .NET에 대한 전반적인 이해도 같이 진행하고자 합니다. .NET은 아주 초기시절부터 지금까지 여러 version으로 파생되기 시작했는데 각각마다 부르는 명칭이 비슷하면서도 목적은 달라서 이들에 대한 정확한 구분이 선행될 필요가 있습니다.

 

물론 아직 본격적으로 C# Programming을 시작하기 전이지만 간단한 예제를 직업 만들어 보면서 대략 어떤 식으로 시작하는지에 대한 감을 잡아볼 것입니다. 아무것도 알 수 없을 테지만 괜찮습니다. 자세한 건 시간이 지나면서 알게 될 테니 서두르지 않아도 됩니다.

 

1) 예제 code

 

이 책에 대한 예제 code는 GitHub Repository에서 따로 배포할 것입니다. 배포되면 그때 주소를 알려드리겠습니다.

 

2) 이 Article에서 다루고자 하는 것

 

해당 article에서는 오로지 아래 2가지 사항에 대해서만 집중할 것입니다. WEB개발과 같은 다른 분야는 기회가 된다면 별도의 안내서를 통해 학습해 볼 것입니다.

• 언어의 기본 : 언어에 대한 다양한 문법, 기능과 함께 객제지향 programming까지 언어전반
• .NET : .NET base class library를 비롯해 일반적인 상황에서 유용하게 사용될 수 있는 Nuget package

2. 개발환경 설정

 

다른 언어도 마찬가지겠지만 C# 역시 특정한 code editor를 필요로 하지 않습니다. 극단적으로는 메모장으로도 C# programming이 가능하며 dotnet command interface를 통해 project(source)를 compile 하고 build 할 수 있습니다. 다만 coding작업의 효율성은 떨어질 수 있기 때문에 C#개발에 필요한 code editor를 사용하고자 하는 것입니다.

 

C#에 필요한 개발도구는 대표적으로 Microsoft사의 VS2022나 VSCode가 존재합니다. 물론 third party사의 제품도 존재하지만 이에 대해서는 별도로 다루지 않을 것입니다.

 

Microsoft의 VS2022는 Windows용 통합개발환경:IDEs(Integrated Development Enviroments) 도구로서 개발에 필요한 전반적인 기능을 풍부하게 제공하고 있는 강력한 개발도구입니다. 기능이 강력한 만큼 자체적으로 많은 작업을 쉽게 수행할 수 있기에 팀단위의 project에서 많이 사용되고 있으며 .NET을 위한 가장 보편적인 개발도구라 할 수 있습니다. VSCode는 Windows뿐만 아니라 Mac, Linux에서도 사용가능한 code편집기이며 심지어 Web(GithUb Codespaces)상에서도 사용할 수 있습니다. 초기 때부터 C#뿐 아니라 다른 언어에 대한 code editor로도 많이 사용되고 있습니다.

 

1) 학습을 위한 준비

 

VS2022는 C#/.NET개발을 위한 훌륭한 개발도구이기는 하지만 역설적으로 기능이 너무 많아서 문제인데 도구자체가 매우 크고 복잡해 간단한 작업을 수행하기에는 오히려 너무 과도한 overspec이 될 수 있습니다. 또한 실제 뒤편에서 수행되는 동작을 감추고 그 결과만을 보여주는 경우가 많기 때문에 학습을 위한 것으로는 그리 유용하지 않을 수 있습니다. 따라서 coding을 위한 적절한 도움을 주면서도 세부적인 동작을 살펴보기 위한 것이 필요한데 현실적으로 VSCode가 이러한 조건에 가장 잘 맞는 선택지라고 할 수 있습니다. 따라서 학습을 위해 어떤 것을 선택할지 고민 중이라면 VSCode의 사용을 권장합니다. 물론 이미 사용 중인 editor가 있고 그것이 사용하기에 더 친숙한 경우라면 그것도 괜찮습니다. VSCode는 필수가 아닌 하나의 선택사항에 불과합니다. 결론적으로는 본인에게 가장 적합하다고 판단되는 것을 선택하는 것이 중요하며 도구의 선택에 크게 연연할 필요는 없습니다.

 

또한 학습을 위해 예제로 만들어나갈 type은 특별한 경우가 아니면 Console Application으로 진행할 것입니다. 다른 project유형의 경우 부수적인 code가 너무 많이 포함되어 있어 오히려 학습에 산만함을 더해줄 뿐이므로 최대한 간소하게 진행해 나가기 위한 것입니다.

 

2) VS Code

 

Visual Studio Code는 Microsoft에서 개발한 훌륭한 code editor로서 가벼우면서도 cross-platform이며 Windows뿐만 아니라 대부분의 linux배포판 운영체제에서도 사용할 수 있습니다. 게다가 ARM Processor를 지원하기에 macOS 및 Raspberry Pi에서도 문제없이 사용할 수 있습니다. 또한 개발에 도움을 주는 광범위한 확장도구를 지원함으로써 그 활용성은 다른 그 어떤 editor보다 매우 높은 편입니다.

 

C#과 .NET을 위한 확장도구 중에서는 2023년부터 공개된 C# Dev Kit이 있는데 이 확장도구는 VSCode를 C#과 .NET개발의 최적화된 환경으로 만들어 줍니다. C# Dev Kit에 관해서는 아래 link에서 더 많은 내용을 확인하실 수 있습니다.

https://devblogs.microsoft.com/visualstudio/announcing-csharp-dev-kit-for-visual-studio-code/

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

 

다만 단점도 있는데 web개발이나 Console app수준의 개발은 큰 어려움이 없지만 mobile이나 Desktop UI개발에서는 아직 부족한 점이 있는 것으로 보입니다. 그럼에도 불구하고 VSCode는 많은 개발자가 선택한 가장 인기 있는 code editor로 성장해 가고 있습니다.

3) VS2022

 

VS2022는 언급했듯이 통합개발환경으로 Web뿐만 아니라 Desktop까지 대부분의 application을 개발할 수 있습니다. 일부 mobile app으로 개발이 가능하기도 하지만 iOS계열이라면 compile을 위해 macOS와 Xcode가 필요할 수 있습니다.

 

Visual Studio는 한때 macOS용으로 배포되긴 했지만 현재는 지원이 중단되었으므로 현실적으로 Windows상에서만 사용할 수 있습니다. 다만 64bit여야 하며 Windows S는 지원하지 않습니다.

 

참고로 앞으로 작성하게 될 많은 예제는 Windows 11 OS상에서 VS2022와 VSCode를 사용하여 작성되었습니다.

 

4) .NET 호환 patform

.NET 9은 아래 platform을 지원하고 있으므로 작성된 application은 해당 platform에서 자유롭게 배포되어 사용될 수 있습니다.

• Windows : Windows 10, 11, Server(2012 R2이상), (Windows 7에 대한 지원은 공식목록에 존재하지 않지만 확인결과 runtime을 설치하고 application을 동작시킬 수 있었습니다.)
• Mac : iOS나 iPadOS를 포함해 Catalina 이상
• Linux : Linux는 Alpine, CentOS, Debian, Fedora, openSUSE, ReadHat, SUSE Enterprise, Ubuntu 등 대부분의 배포판에서 사용할 수 있습니다.

Windows Hardware의 경우 ARM64는 .NET5부터 지원하기 시작했습니다. 따라서 Surface Pro 11과 Surface Laptop 7에도 사용되며 사용가능한 .NET의 모든 version은 Windows의 update를 통해 자동으로 update 될 수 있습니다.

 

5) VS2022 내려받기 & 설치하기

 

VS2022는 .NET개발을 위한 가장 대표적인 IDE에 해당합니다. 하지만 Windows를 사용하지 않는다면 VS2022 대신 VSCode의 사용을 권장하며 해당 설명은 무시하고 넘어가도 좋습니다.

 

VS2022는 강력하지만 유료로 구입해서 사용할 수 있는 도구입니다. 그러나 2014년 10월 이후부터 Microsoft는 VS2022 Professional수준의 개발도구를 학생이나 open-source개발자, 개인개발자를 위해 Community Edition이라는 이름으로 무료로 제공하고 있으므로 해당하시는 분은 비용부담 없이 VS2022의 사용을 시작하실 수 있습니다.

 

VS2022는 아래 link를 통해 내려받으실 수 있습니다.

https://visualstudio.microsoft.com/downloads/

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

이 글을 쓰는 시점에는 아직 존재하지 않지만 추후에는 VS2025가 발표될 가능성이 있고 실제 위 link로 들어갔을 때 VS2025가 보일 수 있습니다. VS2025는 사용자 interface에서 약간 달라질 수 있지만 거의 기능이 비슷할 것이므로 VS2025를 대신 내려받으시면 됩니다.

 

위 link로 들어가면 3가지 내려받기 가능하며 이중 Community 설치 file을 내려받아 실행합니다.

 

실행 후 continue button을 누른 후 잠시 기다리면 다음과 같은 화면을 볼 수 있습니다.

 

해당 화면의 WorkLoad영역에서 .NET desktop development 항목만 check해준 뒤 install button을 눌러주고 설치가 완료될 때까지 잠시 기다려 줍니다. (오로지 C#학습을 목적으로 하므로 다른 선택사항은 필요하지 않습니다. 따라서 web이나 mobile에 관련된 다른 개발작업이 필요한 경우 해당하는 option을 선택해 줘야 합니다.)

 

설치가 완료되면 자동실행을 선택한 경우 VS2022가 실행되겠지만 그렇지 않다면 Launch을 눌러 VS2022를 실행합니다. 일단 처음 VS2022가 실행되면 아마도 login화면이 나올 텐데 Micorsoft계정을 가지고 있다면 해당 계정으로 login 하고 그렇지 않다면 새롭게 계정을 등록해 사용할 수 있습니다.

 

그다음에는 VS2022의 개발환경을 설정하는 화면이 나올 것입니다. 여기서는 Visual C#을 선택하고 Theme도 원하는 것을 선택한 뒤 'Start Visual Studio'를 눌러주면 VS2022의 첫 실행화면을 볼 수 있습니다.

 

6) VSCode 내려받기 & 설치하기

 

VSCode는 지난 몇 년간 놀랍도록 발전을 거듭한 code editor로서 대부분의 개발자가 사용 중인 광범위한 점유율을 자랑하고 있습니다. 만약 가장 최신의 VSCode를 빠르게 사용해 보려면 일반 build version이 아닌 수시로 update 되는 insiders edition을 사용할 수도 있습니다.

 

이미 VS2022만을 사용하겠다고 결정했을지라도 꼭 한 번은 VSCode를 사용해 볼 것을 권장합니다. 어느 순간에 어느 것을 사용할지는 모두 사용해 보고 결정해도 늦지 않습니다.

 

VSCode는 아래 link를 통해 내려받을 수 있습니다. 여기서는 안정화 version은 물론 Insiders version 역시 내려받을 수 있으며 platform 따른 VSCode 역시 내려받을 수 있습니다.

https://code.visualstudio.com/

Visual Studio Code - Code Editing. Redefined

 

설치는 큰 어려움이 없이 진행할 수 있으며 해당 설치화면마다 필요한 option이 있는 경우 여기에 대한 설정만 진행해 주면 됩니다.

 

VS2022를 설치하면 개발에 필요한 모든 component들이 자동으로 설치되지만 VSCode는 그렇지 않습니다. 엄밀히 VSCode는  C#/.NET전용 개발도구가 아닌 범용 code editor에 해당합니다. C#개발에 필요한 .NET SDK는 아래 link에서 별도로 내려받아 설치할 수 있습니다.

https://dotnet.microsoft.com/en-us/download

Download .NET (Linux, macOS, and Windows) | .NET

 

참고로 여기에서는 .NET SDK 9.0과 8.0을 같이 내려받아 설치하도록 합니다. 최신 version의 개발을 위해서라면 9.0만 있으면 되지만 computer에 여러 version의 .NET SDK가 설치된 경우 이들을 어떻게 다룰 수 있는지를 같이 알아보기 위해 서로 다른 version의 SDK를 설치해 놓고자 하며 이런 경우는 생각보다 빈번하게 발생합니다.

 

VSCode의 설정에 관해서는 천천히 알아볼 것이며 큰 어려움이 없지만 여기에 더 자세한 도움을 받고자 한다면 아래 link를 참고하실 수 있습니다.

https://code.visualstudio.com/docs/setup/setup-overview

Setting up Visual Studio Code

 

VSCode의 설치가 완료되면 그다음으로 C# Dev Kit 확장기능을 설치해야 합니다. 이를 위해 VSCode를 실행하고 Extentions 또는 View -> Extesions Menu를 선택합니다. 그리고 'C#'이라는 단어로 확장기능을 검색하여 'C# Dev Kit'을 찾아 'Install'을 눌러 설치를 진행해 줍니다.

C# Dev Kit 확장기능은 C#, .NET Install Tool에 대한 의존성을 갖고 있으므로 이들의 확장기능이 같이 설치될 것입니다.
C# 확장기능은 InstalliSense와 code탐색, debuging과 같은 매우 유용한 기능을 제공합니다.

 

이로서 C#학습을 위한 준비는 모두 마쳤습니다.

 

(1) 이외에 도움 될만한 확장도구

아래 확장도구는 필수는 아니지만 설치하면 C# Programming에 편리성을 더할 수 있습니다.

IntelliCode for C# Dev Kit (ms-dotnettools.vscodeintellicode-csharp)	Code작성시 AI를 통한 도움을 받을 수 있습니다.
ilspy-vscode (icsharpcode.ilspy-vscode)	.NET Framework 부터 .NET Core, .NET에 이르기까지 해당 platform을 사용해 개발된 Assembly의 Decompile을 지원합니다.
REST Client (humao.rest-client)	VSCode안에서 HTTP를 통한 요청을 보내고 그 응답을 확인할 수 있습니다. PostMan과 같은 program의 좋은 대안이 될 수 있습니다.

 

참고로 확장도구는 VSCode안의 확장도구를 통해 검색해 설치할 수 있지만 아래 명령을 통해서도 가능합니다.

code --list-extensions	설치된 확장도구를 확인합니다.
code --install-extension [확장기능 id]	해당 id의 확장기능을 설치합니다.
code --uninstall-extension [확장기능 id]	해당 id의 확장기능을 제거합니다.

예를 들어 IntelliCode for C# Dev Kit을 명령줄을 통해 설치하고자 한다면 아래와 같이 사용할 수 있습니다.

code --install-extension ms-dotnettools.vscodeintellicode-csharp

 

(2) 단축키

 

VSCode에서 사용가능한 단축키는 아래 link에서 찾아볼 수 있습니다.

 

keyboard-shortcuts-windows.pdf

 

만약 VSCode를 macOS에서 사용한다면 아래 link를

 

keyboard-shortcuts-macos.pdf

 

Linux를 사용한다면 아래 link를 참고하시면 됩니다.

 

keyboard-shortcuts-linux.pdf

 

단축키는 필요에 따라 변경하여 사용할 수 있습니다. 이에 관한 Guide는 아래 글을 통해 확인하실 수 있습니다.

 

Keyboard shortcuts for Visual Studio Code

Keyboard shortcuts for Visual Studio Code

 

2. .NET

 

지금의 .NET의 과거를 거슬러 올라가면 .NET Framework, .NET Standard, .NET Core, .NET이나 Xamarin과 같은 platform이 등장하게 됩니다. 현재 시점으로 이들을 바라보면 Application을 개발하는 데 있어 상당 부분 겹치는 면이 존재하며 서로 연결되어 있기도 합니다. 사실 과거의 것을 필수적으로 알아야 하는 것은 아니지만 이들을 이해하면 현재 .NET의 철학을 이해할 수 있기도 이들을 포함하여 .NET에 관한 여러 가지 이야기를 먼저 시작하고자 합니다.

(1) C#과 .NET의 관계

 

오로지 .NET만을 위해 탄생한 C#은 그 태생에 따라 .NET과는 떨어질 수 없는 언어입니다. C#자체는 단순한 Programming언어에 해당하지만 일단 C#으로 작성된 source code는 .NET의 compiler에 의해 IL이라고 하는 Common Intermediate Language(CIL)로 compile 될 수 있습니다. 그리고 이렇게 compile 된 IL code는 다시 .NET Runtime의 CLR(Common Language Runtime)을 통해 load 되는데, 이때 현재 실행 중인 Computer의 CPU에 맞는 기계어 code로의 compile과정(Just In Time:JIT)을 다시 거쳐 실행되는 구조를 갖습니다. 2번의 compile과정을 거치는 것이 매우 이상해 보이지만 이러한 구조 덕분에 거의 대부분의 Platform에서 .NET Application이 실행될 수 있습니다. 이에 관한 자세한 사항은 추후에 자세히 다뤄볼 것입니다.

 

이러한 동작방식은 .NET의 다른 언어인 VB.NET이나 F#도 마찬가지며 .NET의 모든 언어가 동일한 실행방식을 취하고 있습니다.

 

위의 이미지처럼 .NET에 대한 언어는 C#외에 다른 언어도 존재하므로 C#만이 .NET Application을 개발하는데 필요한 필수적인 언어는 아닙니다. 그러나 반대로 C#은 오로지 .NET Application을 개발하기 위해서만 사용될 수 있는 언어이며 다른 platform에서는 C#언어를 사용할 수 없습니다. 사실 C#은 개방형 표준에 해당하므로 이론적으로 누군가가 C# Compiler를 다른 platform에서도 사용할 수 있도록 만들 수는 있으나 실제 그렇게 하는 것이 큰 의미는 없기에 아직 이걸 시도한 경우는 없는 것으로 보입니다. .NET생태계에 들어가 있는 언어는 여러 가지지만 C#은 그중에서도 압도적인 사용자계층을 구축하고 있으며 그 지휘는 앞으로도 계속 유지될 것입니다.

 

(2) 과거부터 현재까지의 .NET

 

.NET을 처음 접하면 .NET의 여러 platform의 존재로 인해 혼란을 느끼는 경우가 있습니다. .NET의 역사는 2025년 기준으로 거의 20년이 넘어가는데 그 사이에 그때의 시기에 맞춰진 여러 .NET platform이 존재하며 많은 곳에서 이들 platform이 아직까지 거론되고 있기 때문입니다. 그러나 알고보면 .NET이 진화되는 과정에 불과하며 각각의 platform에 대해 세부적인 지식이 필요하지도 않습니다. 따라서 순서대로 간단한 개념정도만 짚어볼 것이므로 부담 없이 읽어 내려가면 됩니다.

 

1) .NET Framework

 

Code의 실행을 관리하는 CLR과 Application을 개발하는데 필요한 수많은 class들을 제공하는 BCL(Base Class Library)를 포함한 최초의 .NET 개발 platform으로 Application개발을 위한 종합선물세트라 할 수 있습니다(그래서 너무 무겁습니다.). 사실 이때부터 Microsoft는 cross-platform을 염두에 두고 있었으나 당시 복잡한 한계를 극복하지 못하고 사실상 Windows전용의 platform으로 개발이 지속되어 왔습니다. 그리고 .NET Framework 4.5.2 version에 이르러서 Microsoft는 공식적으로 Windows전용임을 인정하게 됩니다. 그래도 .NET Framework는 꽤나 성공적이어서 수많은 computer에 설치되었는데 이 때문에 지금은 아주 약간의 bug수정조차도 문제를 일으킬 수 있으며 그 영향력은 엄청나게 커질 수 있습니다. 따라서 현재로서는 거의 지원이 중단된 상태라고 볼 수 있으며 더군다나 .NET Framework 4.0부터는 GAC(Global Assembly Cache)에 저장된 동일한 version의 CLR과 Library를 공유하고 있으므로 이들 중 일부가 호환성을 위해 특정한 version을 필요로 한다면 문제를 일으킬 소지가 많습니다. 지원이 중단된 상태이기도 하며 추후에 문제가 될 가능성이 많기에 신규 project에 .NET Framework를 도입하는 건 전혀 권장되지 않습니다.

 

2) Mono와  Xamarin

 

Mono는 .NET Framework의 open-source version으로 Microsoft가 아닌 제3의 다른 개발사가 개발한 것입니다. .NET Framework와의 가장 큰 차이점은 cross-platform으로서 linux와 같은 운영체제에서도 동작할 수 있다는 것입니다. 다만 .NET Framework만큼의 수준에는 미치지 못해서 개인적으로 실무적인 것보다는 학교와 같은 교육기관에서 교육용으로 많이 사용되었던 것 같습니다.

 

Xamarin은 mobile개발 platform으로서 2016년 Microsoft가 인수하여 당시 유료였던 Xamarin확장 program을 Visual Studio에서 무료로 사용할 수 있도록 하였습니다. 이후 Microsoft는 Mobile app개발을 위한 Xamarin Studio development tool을 Visual Studio for Mac이라는 이름으로 변경하였고 여기에 console app이나 web service와 같은 다른 project도 생성할 수 있는 기능을 추가하였습니다. 그리고 Visual Studio 2022 for Mac에 이르러서 Microsoft는 Xamarin Studio editor의 일부를 Windows용 Visual Studio 2022의 일부로 대체함으로써 비슷한 수준의 경험과 성능을 제공하기 시작했고 이후에 다시 Visual Studio 2022 for Mac을 macOS용 native app으로 재개발함으로써 신뢰성과 성능을 크게 향상하게 됩니다. 그리고 이러한 과정을 거치게 되면서 Visual Studio 2022 for Mac은 자연스럽게 Windows용 Visual Studio 2022와는 전혀 다른 형태로 만들어지게 됩니다.

 

3) .NET Core

 

.NET Framework는 Windows에 전속된 개발 platform으로서 cross-platform이 중요해지는 시대에 개발자의 영역을 .NET Framework만으로 확장시키기에는 어려움이 많았습니다. 이에 한계를 느낀 Micorsoft는 2015년 부터 .NET Framework를 Windows OS로부터 분리시키고 cross-platform으로 만들기 위한 시도를 시작했으며 이 과정에서 .NET Framework의 많은 부분이 재개발되고 cross-platform으로 유지할 수 없는 부분은 과감히 제거하게 됩니다. 이렇게 해서 만들어진것이 .NET Core이며 기존 CLR이 CoreCLR로 BCL이 CoreFX로 포함되게 됩니다. .NET Core는 발표직후부터 빠르게 진화되기 시작했으며 무엇보다 app과 함께 병행하여 배포될 수 있어서 특정 변경사항이 동일한 system안의 서로 다른 app에 영향을 주지 않게 되었습니다.

 

4) .NET

 

.NET을 통합하려던 Microsoft의 시도의 결과로 2020년 11월 10일 드디어 .NET5가 처음 발표되었습니다 .NET5는 mobile을 제외하고 모든 version의 .NET을 통합한 첫번째 version이었습니다. 그리고 2021년 11월 .NET6에 와서야 mobile의 통합까지 완성하게 됩니다.

 

.NET Core 3이 발표된 이 후 .NET으로 넘어오면서 그때까지의 이름에서 Core가 제거되고 .NET이라는 이름만 남아 공식적인 명칭으로 유지되어 오고 있는데, 사실 .NET이 처음나올때 version은 순서상 4가 되어야 하지만 .NET Framework 4와의 혼동을 방지하기 위해 4 version을 건너뛰고 .NET 5라는 이름으로 세상에 등장하게 됩니다. 이때부터 Microsoft는 .NET의 주요 version이 매해 11월마다 update 될 것이라고 발표하였으며 이러한 발표내용대로 현재 .NET 9가 2024년 11월에 발표되었고 .NET 10은 2025년 11월에 발표될 예정입니다. 

.NET 주요 Version	발표일
.NET 5 (Current)	2020년 11월
.NET 6 (LTS)	2021년 11월
.NET 7 (STS)	2022년 11월
.NET 8 (LTS)	2023년 11월
.NET 9 (STS)	2024년 11월
.NET 10 (LTS)	2025년 11월

Microsoft는 .NET을 open-source화 하였으며 이를 통해 .NET의 개선사항이나 변경사항 등을 공개하고 있고 특히 성능적인 향상을 위해 주력하고 있습니다. 또한 단일적인 .NET Framework와 달리 .NET은 모듈화를 기본으로 하고 있고 .NET Framework에서 cross-platform으로 사용할 수 없거나 불필요한 많은 code를 제거함으로써 훨씬 가벼운 상태를 유지할 수 있게 되었습니다. 특히 .NET Framework에서 존재하던 WinForm이나 WPF(Windows Presentation Foundation)과 같은 기술은 WindowsOS와 밀접하게 연결된 기술로 macOS나 Linux에서는 통용되지 않기 때문에 crosss-platform을 기본으로 지향하는 .NET에서는 이를 포함하지 않게 되었습니다.

 

5) 요약해 보기

 

지금까지 언급했던 1)~4)까지의 내용은 아래와 같이 정리할 수 있습니다. 

.NET Platform	특징	대상
.NET Framework	Legacy기술로 C# 8까지 지원되며 그 이상은 지원하지 않습니다. 신규 개발에는 사용하지 말아야 하며 기존의 Application을 전환하는 용도로만 사용되어야 합니다.	Windows 전용
Xamarin	모바일과 일부 Desktop개발 전용	Android, iOS, macOS등
.NET	C# 8부터 C# 13까지 완벽하게 지원하며 .NET으로 가능한 신규 Project에 사용할 수 있습니다.	Windows, Linux, macOS, Android등

 

참고로 .NET Project는 solution이라는 project관리 개념을 갖고 있으며 이를 통해 다수의 project를 한 묶음으로 관리할 수 있습니다. 추후에 만들게 될 예제에서도 solution을 사용해 볼 것입니다.

 

6) Windows Desktop Application 개발은 불가능한가?

 

.NET은 기본적으로 cross-platform이지만 WinForms이나 WPF와 같은 Windows전용의 Desktop개발이 필요하다면 Windows Desktop Pack을 추가로 설치할 수 있습니다. 물론 이렇게 되면 macOS나 Linux의 .NET보다 훨씬 덩치가 커지고 여전히 cross-platform은 기대할 수 없게 되겠지만 최신의 .NET기술을 활용하면서 이전보다 좀더 새로운기능과 성능적인 이점을 가져갈 수 있다는 장점도 있습니다. 따라서 legacy방식의 Windows Desktop Application의 개발이 여전히 필요하다면 예전 .NET Framework를 사용하는 것보다 .NET + Windows Desktop Pack의 형태를 유지하는 것이 좋습니다.

 

7) Web 개발은 어떻게 달라지나?

 

.NET Framework때의 ASP.NET Web Forms와 WCF(Windows Communication Foundation)는 개발방식이 현재 Web개발 Trend에는 적합하지 않은 면이 많습니다. 이로서 .NET에서는 해당 기술이 제거되었으므로 더 이상 사용할 수 없게 되었습니다. 대신 이를 대체하는 개발기술로 .NET의 ASP.NET Core platform으로 통합된 ASP.NET MVC, ASP.NET Web API 등을 사용할 수 있으며 추가로 SignalR과 gRPC도 존재합니다.

 

참고로 ASP.NET Web Forms나 WCF, WF(Windows Workflow)를 사용하고자 일부 개발자들이 여전히 존재하며 심지어 이러한 기술을 .NET에 맞게 전환하려는 open-source project가 존재합니다.

https://devblogs.microsoft.com/dotnet/supporting-the-community-with-wf-and-wcf-oss-projects/

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

 

그리고 해당 project의 결과물로 CoreWCF가 이미 2022년 4월에 발표되었으며

https://devblogs.microsoft.com/dotnet/corewcf-v1-released/

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

 

Blazor를 Web Forms형태로 개발하기 위한 open-source project도 같이 진행되고 있습니다.

https://github.com/FritzAndFriends/BlazorWebFormsComponents/

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

 

8) Database 개발 관련

 

.NET Framework에서 사용되던 EF(Entity Framework)는 개체-관계 mapping 기술로서 Oracle이나 MSSQL Server와 같은 관계형 Database에서 작동하도록 설계되었습니다. 하지만 해당 기술 역시 수년에 걸쳐 기존의 호환성을 유지하면서 보완을 거듭해 온 탓에 지금의 .NET과는 맞지 않는 면이 많았습니다. 따라서 다른 platform과 마찬가지로 .NET으로의 새로운 변화가 시도되었고 그 결과 이전보다 더 간소화되면서 Azure Cosmos DB와 같은 비 관계형 Database에서도 사용가능하도록 Entity Framework Core라는 이름으로 새롭게 탄생하게 되었습니다.

 

해당 기술에 관해서는 Database연동과정을 알아볼 때 자세히 다뤄볼 예정입니다.

 

9) .NET Standard

2019년에 .NET platform은 아래와 같이 크게 3가지 영역이 공존하게 되었습니다.

 

- .NET
- .NET Framework
- Xamarin

 

.NET Framework는 이전 legacy개발을 위해, Xamarin은 mobile개발을 위해 존재한 것인데 이들은 모두 엄밀히 전혀 다른 영역에 해당되며 각각의 위해 개별적인 학습이 필요할 정도였습니다. 때문에 이러한 상황에서 이 3가지를 모두 포괄할 수 있는 표준적인 개발사양의 필요성이 대두되었고, 그 결과 .NET Standard가 등장하게 됩니다.

 

.NET Standard는 모든 .NET Platform이 구현할 수 있는 일련의 API에 대한 사양을 정의한 것인데 이것도 version에 따라 호환가능한 수준이 달랐습니다. 초기 version은 1.4이며 2.0에 들어서는 Microsoft가 상기 3가지 platform을 .NET Standard안에 통합되도록 만들었고, 따라서 해당 platform끼리 code 공유가 가능하게 되었으며 덩달아 개발의 효휼성도 같이 올라가게 되었습니다. 또한 이때쯤 .NET Framework로 작성된 많은 legacy code를 .NET Core로 이식하기 위한 수많은 API들도 추가 외었습니다. 다만 .NET Core은 여전히 cross-platform이기 때문에 일부 API에서는 .NET이 실행되는 운영체제상의 차이로 인해 실제 API가 사용되지 않도록 알리기 위한 예외가 발생하곤 하였습니다.

 

어쨌건 .NET Standard는 일종의 표준이라는 점을 기억해야 합니다. 개발에 필요한 실제적인 platform이 아니며 이를 어디엔가 설치해서 사용하는 것도 아닙니다. 다른 .NET Platform을 사용하여 개발할때 따라야할 규칙이자 표준인 것입니다.

 

.NET Standard의 최종 version은 2.1이며 여기에는 .NET Core 3.0, Mono, Xamarin등이 구현되었으나 .NET Framework 4.8은 제외되었습니다. 또한 C# 8.0의 완전한 사용을 위해 .NET Standard 2.1을 필요로 하였습니다.

 

.NET 6부터는 mobile과 .NET이 하나로 결합된 단일적인 platform으로 개발되기 시작하면서 .NET Standard와의 필요성이 사라졌습니다. .NET은 하나의 BCL과 2개의 CLR을 가지고 있는데 이중 CoreCLR은 Web이나 Windows app과 같이 Server나 Desktop에 최적화된 것이며 Mono runtime은 주로 mobile에서 최적화된 것입니다. 이에 관한 내용은 아래 link를 통해 더 자세히 확인해 보실 수 있습니다.

https://devblogs.microsoft.com/dotnet/performance-improvements-in-net-6/#blazor-and-mono

어쨌건 현재의 .NET은 더 이상 .NET Standard를 필요로 하지 않으며 더이상 새로운 version이 나오지도 않을 것입니다. 따라서 신규 project를 생성하는 경우 .NET Standard는 더이상 고려사항이 아닙니다.

 

(3) .NET의 지원 체계

 

.NET의 version체계는 크게 LTS(Long-Term Support)와 Current라고 부르는 STS(Standard-Term Support), 그리고 Preview로 나뉠 수 있습니다.

 

LTS는 거의 월단위의 update가 지원되는 version으로 application에 잦은 update가 적용되는 것은 아니지만 대신 안정적으로 꾸준히 운영되어야 하는 환경에 적합합니다. 지원기간은 GA(General Availability:TEST를 거친 후의 안정화기간) 이후 3년 또는 다른 LTS가 release 된 이후 1년간 지원되며 더 긴 기간이 우선합니다.

 

STS는 개발자의 feedback을 기반으로 많은 변경사항을 내포한 version입니다. 가장 최근에 완료된 개선점을 반영하고 있으므로 개발이 활발히 이루어지고 있는 application에 적합한 version이라 할 수 있습니다. 지원기간은 GA이후 18개월 또는 다음 STS나 LTS가 release된 이후 6개월간 지원되며 더 긴 기간이 우선합니다.

 

따라서 시기상 .NET8의 지원기간이 .NET9의 지원기간 범위를 넘게 되며 이 시기안에 .NET10이 release 될 것입니다. 또한 2024년 11월이 되면 .NET 8/9/10을 제외하고 모든 .NET version의 지원이 종료됩니다.

 

Preview는 간단히 말해 TEST중인 것으로 최신 변경사항을 가장 빠르게 반영하지만 안정화와는 거리가 먼 version입니다. 대부분 release 되기 이전에 언어나 platform에 대한 신기능을 미리 접해보고자 하는 경우에 사용할 수 있습니다. LTS와 STS가 지원기간 동안 보안과 신뢰성에 영향을 주는 중대한 patch가 지속적으로 이루어지지만 Preview는 Microsoft에 의해 지원이 이루어지지 않습니다. 다만 일부 특별한 경우에 preview나 RC(Release Candidate)라도 production에서 지원되는 경우도 있지만 극히 드문 경우에 속하므로 Preview를 Production환경에 적용해서는 안됩니다.

 

.NET Project에서 LTS를 사용하고자 한다면 당연히 target을 .NET8로 설정해야 하며 2025년 11월 .NET10이 release 된다면 해당 version으로 전환할 필요가 있습니다. 실제 이런 상황이라면 .NET8의 지원기간종료까지는 1년의 시간이 남아있는 상태가 되며 .NET9의 경우 STS에 해당하므로 2026년 5월에 지원이 끝나게 됩니다.

Windows Update시 .NET에 대한 중요한 patch가 같이 이루어지므로 update만 꾸준히 한다면 최신 version의 .NET을 항상 유지할 수 있습니다. 만약 그렇지 않은 경우라면 가급적 update 된 version을 내려받아 설치하여 최신상태를 유지하시기 바랍니다. 예를 들어 9.0.0 version을 최초로 설치했다면 곧 9.0.1 version이 나올 수 있습니다. update주기는 Patch Tuesday라고 하여 매달 둘째 주 화요일에 이루어집니다.

 

현재 지원되는 .NET version과 지원종료(EOL:End of life)까지의 기간은 아래 link를 통해 지속적으로 확인할 수 있습니다.
https://github.com/dotnet/core/blob/main/releases.md

 

1) .NET의 지원단계

 

.NET은 Preview, Go Live, Active, Maintenance, EOL 이렇게 5단계로 지원단계를 구분할 수 있습니다.

 

● Preview : Preview를 달로 있는 모든 .NET version은 지원되지 않습니다.

● Go Live : GA동안에만 지원되며 그 이후에는 지원되지 않습니다. 따라서 다음 version으로 가능한 한 신속히 update 해야 합니다.

● Active : 현재 시점으로 .NET9가 이 단계에 머물러 있습니다.

● Maintenance : 지원기간 동안의 마지막 6개월을 기점으로 보안 관련 patch만 이루어지는 기간을 의미합니다. 현재 시점을 기준으로 .NET9가 2025년 11월에서 2026년 5월까지 이 단계에 접어들게 됩니다.

● EOL : End of life 또는 End of Support라고 하며 결함 및 보안 update나 그 밖에 기술지원을 Microsoft에서 진행하지 않는 시기를 의미합니다. 2024년 11월 .NET6는 이미 EOL에 도달했는데 이를 target으로 한 Application이 EOL에 도달했다고 해서 즉각적으로 영향을 미치는 부분은 없을 것입니다. 그러나 일단 보안 patch가 더 이상 진행되지 않으므로 잠재적으로 보안취약성을 가질 수 있으며 어떠한 기술적 지원도 받을 수 없습니다. 또한 Visual Studio에서 해당 project를 열 때 이에 대한 경고메시지가 나타날 수 있으므로 가급적 새로운 .NET으로의 전환을 빠르게 추진해야 합니다.

 

(4) .NET Runtime과 SDK

 

.NET Project가 Standalone으로 build되지 않는이상 .NET Application을 실행하기 위한 최소한의 구성요소로 .NET Runtime이 유일합니다. .NET SDK는 .NET Runtime을 포함해 .NET Application을 개발하는데 필요한 compiler및 기타 도구등을 포함하고 있습니다. 따라서 단순히 .NET Application을 실행하는 경우라면 runtime을, C#과 같은 언어를 통해 .NET Application을 개발하고자 한다면 SDK를 사용해야 합니다. 만약 SDK를 설치했다면 runtime은 이미 포함되어 있으므로 따로 설치하지 않아도 됩니다.

 

.NET Runtime version의 부여방식은 semantic을 따르고 있습니다. 따라서 대규모 변화를 나타내는 따라서 각 version은 주요 version과 기능추가를 나타내는 중간 version, 그리고 bug수정을 나타내는 마지막 version으로 구분됩니다.

 

반면 .NET SDK는 주요 version과 중간 version이 runtime version과 동일하게 연결되며 있으며 세 번째 version만이 SDK의 기능추가와 bug수정을 나타내는 숫자로 사용됩니다. 이때 세번째 version은 초기에 100으로 시작하는데 이는 기능추가와 bug수정이 이루어지지 않은 0.0과 동일하게 사용되며 이중 첫 번째를 minor수준의 증가로, 나머지 2개의 숫자를 patch와 관련된 증가를 나타내는 용도로 사용됩니다.

	Runtime version	SDK version
초기 SDK	9.0.0	9.0.100
SDK의 bug 수정	"	9.0.101
Runtime과 SDK의 bug 수정	9.0.1	9.0.102
SDK에 신규기능 추가	"	9.0.200

 

(5) 내 PC의 .NET 설치 확인하기

 

.NET Runtime은 9.x.x와 같은 주요 version끼리만 호환되며 .NET SDK 역시 update 되더라도 주요 version이 일치하면 그 안에서 이전 version에 맞춰진 application을 build 할 수 있습니다. 따라서 이전 version은 비교적 안전하게 제거할 수 있습니다.

주요 version에서 차이가 나는 application을 build 하는 경우 version전환에 따른 약간의 작업이 추가될 수 있지만 비교적 원활하게 application을 update를 진행할 수 있습니다.

 

자신의 PC에서 현재 설치된 SDK와 runtime의 version을 확인해 보기 위해서는 다음과 같은 명령을 사용할 수 있습니다.

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

 

.NET을 삭제하고자 하는 경우에는 Windows의 Program 추가/삭제에서 삭제할 수 있습니다. Linux라면 각 배포판마다 방법이 달라질 수 있는데 아래 link를 통해 자세한 정보를 확인하시기 바랍니다. 

https://learn.microsoft.com/en-us/dotnet/core/install/remove-runtime-sdk-versions?pivots=os-linux

Remove the .NET runtime and SDK - .NET

Dots와 같은 .NET관리를 위한 도구를 사용할 수도 있습니다.
https://johnnys.news/2023/01/Dots-a-dotnet-SDK-manager
물론 이런 tool을 사용하는 것도 나쁘지 않지만 GitHub repository로부터 source를 가져와 app을 build 해야 하는 과정을 거쳐야 하는 과정이 필요해서 이를 이해하는 개발자가 아니면 접근하기가 까다롭다는 단점이 있습니다.

 

(6) IL (Intermediate Language)

 

Roslyn이라 불리는 C# compiler는 dotnet CLI tool을 사용해 C# code를 IL code로 변환하고 이를 DLL이나 EXE file형태로 저장합니다. IL code는 언뜻 보면 assembly언어와 비슷한데 CPU를 직접적으로 하는 대신 CoreCLR이라고 하는 .NET 가상 machine상에서 실행되는 code입니다. .NET Framework에서는 CLR이라고 하여 Windows전용만 존재했었으나 현재 .NET은 Windows뿐만 아니라 Linux나 macOS에 대한 CLR이 각각 존재합니다. 여러 CLR이 있는 경우다 보니 이를 CLRs라고 표시하기도 합니다.

 

.NET Application을 실행하면 CoreCLR은 IL code를 Assembly로부터 불러오게 되고 JIT(Just in time)는 이를 다시 native CPU에 맞게 compile 하여 해당 CPU에서 실행되도록 합니다.

 

2단계에 걸쳐진 compile방식은 뭔가 비효휼적인것처럼 보일 수 있지만 이러한 방식은 Windows 외에 Linux나 macOS용의 CLR만 있으면 .NET Application을 실행할 수 있다는 뜻이 되기 때문에 상당한 장점으로 작용합니다. 즉, 동일한 IL code라 하더라도 두 번째 compile과정에서 실제 해당 CPU에 맞는 code를 만들어낼 수 있기 때문에 OS platform에 따라 code를 바꿔야 하는 문제를 피할 수 있는 것입니다.

 

.NET에서 C#뿐 아니라 VB.NET, F#과 같은 다른 언어에서도 동일하게 IL code 구조를 사용하는데 이중적인 compile구조의 특징 때문에 IL code를 다시 역 compile 하는 것도 가능합니다. 실제 Micorsoft나 JetBrain과 같은 곳에서도 ILSpy.NET과 같은 Decompile 도구를 제공하고 있고 해당 도구를 사용하면 편리하게 IL code를 실제 source로 들여다볼 수 있습니다.

 

정리하자면 .NET compile 처리는 1차적으로 source code를 IL code로 변환하고 IL code는 다시 CLR에서 JIT를 통해 CPU에 맞는 기계어로 compile됩니다. 예외적으로 AOT(Ahead-of-Time)라는 것이 존재하기도 하는데 이 방식은 IL code로의 과정없이 바로 native CPU의 기계어로 compile을 수행하는 것입니다. 이에 관해서는 추후에 한번더 살펴보도록 하겠습니다.

 

3. Visual Studio를 사용해 예제 만들어 보기

 

.NET Project가 생성되는 과정을 간단히 살펴보기 위해 console용 app을 만들어보고자 합니다. Console app project는 간소하면서도 필수적인 내용들은 거의 다 설명할 수 있기 때문입니다.

 

혹시 Windows OS를 사용하지 않거나 VSCode만을 사용하기로 결정했다 하더라도 이 과정을 건너뛰지 말고 가볍게 읽어보시길 바랍니다. Project를 생성하는 데 사용하는 도구만 다를 뿐 기본적인 원리는 동일하며 code 역시 달라지지 않지만 꼭 알아둬야 할 공통적인 설명을 여기서 언급할 것이기 때문입니다.

 

1) Code 작성하기

 

Visual Studio를 실행하고 첫 화면에서 'Create a new project'를 선택합니다.

 

Create a new project dialog에서 'All languages'부분에 C#을 선택하고 상단 'Search for templates'box에 console을 입력합니다.

 

그런 다음 하단에서 'Console App'항목을 선택한 뒤 Next button을 눌러줍니다.

List에서 .NET Framework라고 되어 있는 걸 선택해서는 안되며 언어 또한 상기 이미지처럼 C#으로 되어 있는지 정확히 확인하시기 바랍니다.

 

'Configure your new project' dialog에서 Project name에 CSExam1을 입력하고 Location에는 repos\CSStudy01로 지정합니다. 그리고 'Solution name'에도 동일하게 CSStudy01로 입력합니다. CSStudy01이 Solution이름이며 CSExam1이 Project이름에 해당합니다.

 

모든 입력이 완료되었으면 Next button을 눌러줍니다.

 

'Additional Information' dialog에서 Framework에는 현재 선택가능한 .NET SDK가 표시되는데 특별한 경우가 아니면 여기서는 .NET 9.0 (Standard Term Support)를 선택합니다. 만약 다른 version의 SDK가 필요하다면 아래 link에서 해당 version을 내려받아 설치할 수 있습니다.

https://dotnet.microsoft.com/en-us/download/dotnet

 

그 외 'Do net use top-level statements'와 'Enable native AOT publish'항목에는 check 하지 않습니다. 해당 항목들이 어떤 역할을 하는지에 대해서는 추후에 알아볼 것입니다.

 

모든 설정이 완료되었으면 Create button을 눌러줍니다.

 

잠시동안의 시간이 지난 후 Solution이 성공적으로 생성되었다면 다음과 같은 화면이 표시될 것입니다.

 

만약 화면상 오른쪽에 Solution Explorer가 표시되지 않는다면 상단의 View -> Solution Explorer menu를 통해 해당 화면을 표시할 수 있습니다. 또한 위 화면과 같이 code가 표시되지 않는다면 Solution Explorer에서 Program.cs file을 double click 하면 해당 file의 내용을 왼쪽 화면에 표시할 것입니다.

 

Program.cs안의 code내용은 한 줄의 주석과 한줄의 code로만 구성되어 있는데 이는 Project를 생성할 때 사용한 template에서 C#9에서 도입된 top-level program기능을 사용했기 때문입니다. 이와 관련된 자세한 사항은 주석에 있는 https://aka.ms/new-console-template 주소를 통해 확인하실 수 있습니다.

 

이제 Code에서 Console.WriteLine("Hello, World!");부분을 Console.WriteLine("안녕, World!");로 변경해 봅니다.

 

2) Compile 및 실행하기

 

필요한 code의 작성이 완료되었으면 이제 code를 compile 하고 실행해야 합니다. 위 예제에서는 단순히 'hello'를 '안녕'으로 변경한 것밖에 없지만 아직 제대로 시작하기 전이므로 간단하게만 진행해 볼 것입니다.

 

Visual Studio의 상단 menu에서 Debug -> Start Without Debugging를 선택합니다. 또는 toolbar에서 안이 비어있는 삼각형 button을 누르거나 CSExam1 project에서 mouse오른쪽 button을 눌러 Debug -> Start Without Debugging menu를 선택해도 됩니다. 보통은 debugging으로 시작하는 것이 일반적이지만 debugging이 필요하지 않다면 Start Without Debugging을 선택해 debugging을 수반하지 않는 것이 성능상 더 유리합니다.

debugging을 수반하여 project를 실행하면 code의 debugging을 위해 흐름을 하나씩 따라가는 절차를 거치게 될 뿐만 아니라 성능추적 같은 부가적인 기능이 같이 동작하게 되므로 많은 resource를 요구하게 되며 결과적으로 모든 면에서 성능이 느려지게 됩니다. 또한 debugging을 수반하여 실행할 수 있는 project는 하나로 제한됩니다. 만약 여러 project에 Debugging을 걸어 실행하고자 한다면 필요한 만큼 Visual Studio를 여러 개 실행하여 각각의 project를 열고 실행시켜야 합니다.

 

Start Without Debugging로 project를 실행하면 console화면이 표시되고 project의 application이 실행된 결과를 표시할 것입니다.

 

결과를 보면 한글 부분이??로 표시되어 있습니다. 한글문자의 encoding이 맞지 않으니 아래와 같이 code를 추가합니다.

using System.Text;

// See https://aka.ms/new-console-template for more information
Console.OutputEncoding = Encoding.UTF8;
Console.WriteLine("안녕, World!");

 

그리고 다시 실행하면

 

한글이 제대로 표시될 것입니다.

 

project의 전반적인 정보는 [project명].csproj라는 파일에 있습니다. 해당 file은 Visual Sutdio의 Solution Explorer에서 project명을 double click 하면 아래와 같이 project의 정보를 확인할 수 있습니다.

 

설정상 해당 project는 .NET9를 target으로 하고 있다는 것을 알 수 있습니다.

 

3) obj와 bin folder

 

Visual Studio의 Solution Explorer에서 'Show All Files' button을 누르면 해당 project에 포함된 전체 folder와 file을 표시하게 되는데 이 중에 bin과 obj folder가 존재함을 알 수 있습니다.

 

이 중 obj는 각 source file을 compile 한 개체 file을 포함하고 있는 것으로 각 개체가 아직 실행가능한 형태로 결합되어 있지 않은 상태의 것입니다. 그리고 이들이 결합해 최종 실행가능한 application file 혹은 class library로 만들어지게 되는데 그 file이 bin folder에 존재합니다. 자세한 사항은 추후에 다시 한번 살펴볼 기회가 있을 테지만 일단은 compiler가 실행되면 이러한 folder와 file이 생성된다는 것만 기억해 두시기 바랍니다. 이러한 동작은 compile을 시도할 때마다 실행되기 때문에 obj와 bin을 임의로 삭제한다고 하더라도 project를 실행(실행과정에서 build작업이 선행되므로 compile이 시도됨)하거나 build 하게 되면 이러한 folder와 file은 다시 생성됩니다. 흔한 경우는 아니지만 project자체를 깔끔히 정리하기 위해 이러한 folder와 file을 고의적으로 지우는 경우도 있습니다. Visual Studio에서 Build -> Clean Solution이나 Clean [Project명] menu를 선택하면 전체는 아니지만 일부 임시 folder를 삭제하며 CLI를 사용하는 경우 'dotnet clean'명령을 통해 동일한 동작을 수행할 수 있습니다.

 

4) Top-level Program

이전의 C# Program을 작성해 본 적이 있다면 예제와 같이 단순한 message를 표시하는 경우라도 지금과는 다른 많은 양의 code가 사용되었다는 것을 알 수 있을 것입니다. 반면 우리가 만든 예제 program은 매우 간결하게 작성되었는데 그 이유는 이전에 사용되었던 code가 더 이상 필요하지 않은 것이 아니라 compiler가 필요한 다른 code를 대신 작성해 주기 때문입니다. 이 기능은 .NET5(.NET6가 아님에 주의!)부터 사용되는 것으로 project의 target framework를 .NET5 혹은 그 이전으로 설정하거나 project생성시 'Do net use top-level statements'설정을 check하게 되면 Program.cs file은 아마도 이전 방식 그대로 아래와 같이 작성될 것입니다.

using System;

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

 

.NET SDK 6나 이후의 version을 target으로 한 project의 경우 compile을 진행하게 되면 compiler는 이 과정에서 Program class와 그 안에 Main method를 정의하기 위한 많은 code를 생성하고 여러분이 작성한 구문을 그 안으로 포함시켜 결과적으로 우리가 만든 예제의 code를 완성하게 됩니다.

 

해당 기능은 .NET5에서 top-level program이라는 이름으로 최초 도입되었으나 .NET6에 들어오면서 console app에 대한 project template에 top-level program기능을 사용하도록 기본화하였고 .NET7에서 'Do net use top-level statements'설정을 추가하여 원하는 경우 이전 style을 계속 사용할 수 있도록 하였습니다. 만약 Visual Studio를 사용하지 않는 경우라면 다음과 같은 CLI명령을 통해 동일한 동작을 구현할 수 있습니다.

dotnet new console --use-program-main

top-level program기능을 통해 code가 작성되는 경우 namespace가 정의되지 않습니다. 일반적으로 namespace명은 project의 이름이 사용되지만 이때 Program class는 암시적으로 이름이 없는 빈 namespace안에 정의됩니다.

 

참고로 top-level program기능을 사용할 때는 아래 사항에 주의해야 합니다.

•  top-level program기능은 Program.cs라는 시작 point기능을 가진 하나의 file에서만 사용될 수 있습니다.
• 모든 using문은 file의 가장 처음 부분에 위치해야 합니다.
• class와 같은 type을 선언하는 문은 file에서 아래 부분에 위치해야 합니다.
• Program의 주 진입 method인 Main method를 직접 생성하는 경우 Method의 이름을 Main으로 지정해야 하지만 compiler에서 생성하는 경우 주진입 method의 이름은 <Main>$가 됩니다.

Program에서 예외(Exception)를 발생시켜 보면 실제 위에서 만든 예제에서 compiler가 어떠한 형태로 Main method를 생성했는지 확인할 수 있습니다. 다만 예외에 관해서는 추후에 자세히 알아볼 것이며 C#을 공부하는데 꼭 필요한 부분은 아니므로 빠르게 지나가고 싶다면 그냥 눈으로만 보고 지나가도 좋습니다.

 

예제에서 message를 출력하는 구문 바로 아래에 다음과 같은 구문을 추가합니다. Program이 해당 구문을 실행하게 되면 예외가 발생할 것입니다.

using System.Text;

// See https://aka.ms/new-console-template for more information
Console.OutputEncoding = Encoding.UTF8;
Console.WriteLine("안녕, World!");
throw new System.Exception(); //추가된 구문

 

Visual Studio에서 Debug -> Start Without Debugging를 선택해 예제를 실행합니다. 그렇지 않고 Debugger를 달고 실행한다면 예외가 발생할 때 debugger가 이를 잡게 되므로 정확한 결과를 확인할 수 없게 됩니다.

 

위의 방법으로 예제를 실행하면 아마도 예외를 통해 다음과 같은 오류 message를 보게 될 것입니다.

 

결과를 보면 Main method를 <Main>$ method로 표현하고 있으며 method에 args라는 이름의 매개변수가 존재함을 알 수 있습니다.

 

이번에는 다른 구문을 조금 더 추가하여 compiler에 의해 생성된 Program class의 Namespace를 확인해 보겠습니다.

 

위에서 추가한 예외 발생구문을 삭제하고 대신 아래와 같이 변경된 구문을 작성합니다.

using System.Text;

// See https://aka.ms/new-console-template for more information
Console.OutputEncoding = Encoding.UTF8;
Console.WriteLine("안녕, World!");
string namespaceName = typeof(Program).Namespace ?? "이름없음";
Console.WriteLine(namespaceName);

 

참고로 예제에서 사용된 '??'은 'null 병합 연산자'라고 하는 것으로 'typeof(Program).Namespace의 값이 존재하면 해당 값을 반환하지만 만약 null이라면 "이름 없음"을 대신 사용하라'라는 뜻으로 동작합니다. null이나 연산자와 같은 내용은 추후에 자세히 알아볼 것이므로 지금은 그냥 code를 동일하게 입력하고 실행하여 결과만을 확인해 보시기 바랍니다.

Visual Studio의 code editor는 code snippets라는 기능을 갖고 있어서 일반적으로 사용하는 code의 전체를 입력하지 않고 code의 단축 keyword만으로 전체 code를 입력할 수 있는 편리함을 제공하고 있습니다. 예를 들어 Console.WriteLine()를 입력하기 위해서는 'cw'만을 입력한 뒤 바로 tab key를 눌러주면 됩니다. 그러면 Console.WriteLine() code를 만든 뒤 괄호중간에 cursor를 자동으로 위치시켜 줄 것입니다.

 

Visual Studio에서 다시 Debug -> Start Without Debugging를 선택해 예제를 실행하면 다음과 같은 결과를 표시할 것입니다.

 

이전에 언급했듯이 compiler가 program class를 생성할 때 namespace는 이름이 없는 상태이기 때문에 '이름 없음'이 결과적으로 표시됩니다.

 

5) Global namespace import

 

상기 예제에서 'using System;'구문은 System이라는 이름의 namespace를 import 하는 구문으로 Console의 WriteLine method를 사용하기 위한 것입니다. 하지만 우리가 이전에 만든 예제 program에서는 여전히 Console.WriteLine을 사용하지만 어떠한 namespace import문도 존재하지 않습니다. 이게 가능한 이유가 무엇일까?

 

사실 필요한 namespace를 import 해야 하는 방식에는 변함이 없지만 그럼에도 불구하고 별다른 오류가 발생하지 않는건 .NET6에서 도입된 Global namespace import기능을 통해 암시적으로 필수적인 namespace를 import 하고 있기 때문입니다.

 

실제 이러한 기능이 사용된 결과를 보려면 Visual Studio의 Solution Explorer에서 obj -> Debug -> net9.0 folder를 열고 그 안에 CSExam1.GlobalUsings.g.cs file을 열어보면 됩니다. 이 파일은 project가 target framework를 .NET6부터 설정한 경우 compiler에 의해 자동적으로 생성되는 file로서 C#10에서 도입된 'Global namespace imports'기능을 사용한 것입니다. 해당 file은 System을 포함해 일반적으로 필요로 하는 namespace들을 모아 import 하고 있는데 이러한 구현은 project내의 모든 cs file에 적용됩니다.

// <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.http.Net.Http;
global using global::System.Threading;
global using global::System.Threading.Tasks;

 

이와 같이 향상된 언어와 SDK에 대한 기능은 편리하기는 하지만 뒤편에서 발생하는 많은 부분을 감추고 있으므로 C#과 .NET을 처음 접하는 경우일수록 세부적인 것을 많이 살펴볼 필요가 있습니다.

 

6) Visual Studio에서 두 번째 project추가하기

 

Visual Studio에서는 Solution이라는 단위를 사용해 다수 project를 관리할 수 있도록 지원하고 있습니다. 예제를 통해 두번째 project를 추가하여 하나의 Solution에 다수의 project가 존재할 때 이를 어떻게 사용할 수 있는지 간단하게 알아보도록 하겠습니다.

 

Visual Studio에서 File -> Add -> New Project menu를 선택합니다. 비슷한 menu로 File -> New -> Project도 있지만 기능적으로 다른 것입니다. 전자는 현재의 solution에 새로운 project를 추가하기 위한 목적이지만 후자는 새로운 project를 새로운 solution과 함께 생성하기 위한 것입니다.(물론 후자의 경우라도 새로운 project를 기존의 solution에 추가할지 여부를 option을 통해 선택할 수 있습니다.)

 

Add a new project dialog에서 Recent project templates에 있는 Console App을 선택하고 Next를 눌러줍니다.

 

Configure your new project dialog에서 Project name에 CSExam2를 입력하고 Next를 눌러줍니다.

 

Addtional information dialog에서 이번에는 'Do not use top-level statements'에 check 하고 Create를 눌러줍니다.

 

Project가 성공적으로 생성되면 아래와 같이 해당 Project의 Program.cs file이 나타나는데, 현재 project명과 동일한 namespace가 정의되어 있으며 Program이름의 internal class가 존재하며 그 안에 args매개변수를 가진 Main이름의 정적 method가 있는 예전 style의 구문이 완성되어 있음을 확인할 수 있습니다.

 

Main method안에서 기존의 문을 제거하고 대신 현재 OS의 version을 나타내는 문을 아래와 같이 추가합니다.

static void Main(string[] args)
{
    Console.WriteLine(Environment.OSVersion.VersionString);
}

 

Visual Studio의 Solution Explorer에서 CSStudy01 solution을 mouse오른쪽 button으로 click 한 뒤 'Configure Startup Projects' menu를 선택합니다.

 

Solution 'CSStudy01' Property Pages dialog에서 Startup Project를 Current selection으로 선택한 뒤 'OK'를 눌러줍니다.

 

그리고 Solution Explorer에서 CSExam2 project(또는 그 안에 어떤 folder나 file이든)를 선택하면 Visual Studio는 선택한 project가 시작 project가 되었음을 진한 글자로 표시하게 됩니다.

시작 project로 설정하고자 하는 project를 mouse오른쪽 button을 눌러서 'Set as Startup Project'menu를 선택해 지정하는 방법도 있습니다. 어떤 방법이든 원하는 방식으로 설정하면 됩니다.

 

Debug -> Start Without Debugging를 선택해 CSExam2 project를 실행하면 다음과 같은 결과를 표시할 것입니다.

예제에서 표시된 Microsoft Windows NT 10.. 은 Windows 11의 공식명칭으로서 주요 version은 여전히 10이지만 patch version은 26100이 된다는 것을 알 수 있습니다. Windows 11은 단시 brand명일뿐입니다.

예제의 실행을 통해 예제의 실행파일이 debug\net9.0\CSExam2.exe로 실행된다는 것을 알 수 있습니다. 하지만 이 경로는 Visual Studio의 경우인데 VSCode와 같은 경우에는 이러한 동작방식이 달라집니다.

 

4. VSCode를 사용해 예제 만들어보기

 

이번에는 상기 예제를 VSCode와 dotnet CLI를 통해 다시 만들어보고자 합니다.

 

다만 위의 Visual Studio설명에서 대부분의 기초적인 project구조에 대해 설명했으므로 여기서는 VSCode와 dotnet CLI에 관련된 내용만 언급하고자 합니다. 따라서 VSCode나 dotnet CLI를 사용하지 않기로 했다면 해당 설명은 그냥 넘어가도 좋습니다.

 

차이가 나는 부분이라면 대부분의 개념은 동일하지만 UI가 아닌 command line에서 명령을 직접 입력해야 하는 경우가 있으며 Windows와 macOS, Linux에 따라 이러한 명령이 달라질 수 있다는 것입니다.(다만 예제는 Windows상에서 진행됩니다.) 다만 dotnet CLI의 경우에는 모든 OS상에서 동일하게 사용됩니다.

 

1) VSCode에서 code작성하기

 

만약 위에서 Visual Studio를 사용한 예제를 진행했다면 'C:\Users\[사용자명]\source\repos'경로에 CSStudy01 folder가 존재할 것입니다. VSCode를 사용한 예제를 시작하기 전에 해당 folder를 삭제하고 CSStudy01 이름의 빈 folder를 다시 생성하시기 바랍니다.

 

CSStudy01 folder를 mouse오른쪽 button으로 눌러 '터미널에서 열기'를 선택합니다. Windows PowerShell과 같은 terminal이 열리면 아래 명령을 통해 새로운 solution file을 생성합니다.

dotnet new sln

solution file을 생성할 때 -n이나 --name switch를 사용하면 solution file의 이름을 지정할 수 있습니다.
dotnet new sln -n [이름]
다만 위에서 처럼 해당 switch를 사용하지 않으면 folder의 이름으로 대체됩니다.

sln solution file은 내부에서 GUID(Globally Unique Identifiers)를 통해 각 project와 기타 다른 component들을 참조하고 있으며 Microsoft의 고유한 file format으로 매우 길고 즉각적으로 의미를 파악하기 어려운 구조를 갖고 있습니다. Microsoft는 이에 대한 문제점을 인식하고 XML기반에 간소하고 의미적으로 파악하기 쉬운 새로운 구조를 도입할 예정이며 해당 solution의 확장자도 slnx로 변경될 예정입니다. 이에 관련해서는 아래 link에서 자세히 확인하실 수 있습니다.

`slnx` support in the `dotnet` CLI · Issue #40913 · dotnet/sdk

`slnx` support in the `dotnet` CLI · Issue #40913 · dotnet/sdk

 

현재 CSStudy01 folder하위에 CSExam1 이름의 하위 folder를 만들고 terminal에서 'cd CSExam1'명령으로 해당 folder안으로 들어가 아래 명령을 통해 project를 생성합니다.

dotnet new console

project를 생성할 때 -o나 --output switch를 사용하면 project의 이름을 지정할 수 있습니다.
dotnet new console -o [이름]
다만 위에서 처럼 해당 swicth를 사용하지 않으면 folder의 이름으로 대체됩니다.
또한 project생성 시 대상이될 .NET SDK의 version은 현재 system에 설치된 가장 최신의 .NET SDK가 기본으로 적용됩니다. 따라서 만약 특정 version이 지정되어야 한다면 -f나 --framework switch를 사용하면 됩니다.
dotnet new console -f net8.0

 

Project가 생성되었으면 terminal에서 'cd..'명령을 통해 상위 folder로 이동한 후 아래 명령을 통해 이전에 만든 project를 solution에 추가합니다.

dotnet sln add CSExam1

 

여기까지 완료하였으면 아래 명령으로 VSCode를 실행합니다. 참고로 뒤에 .(점)은 현재 folder를 나타내는 뜻으로 VSCode를 실행하면서 현재 folder가 VSCode의 EXPLORER에 나타날 수 있도록 합니다.

code .

 

위와 같이 실행 시 VSCode에서 아래와 같은 화면이 나오면 "Trust the authors of all files in the parent folder 'repos'"에 check 하고 'Yes, Itrust the authors.'를 선택합니다.

 

VSCode의 EXPLORER에서 CSExam1 folder를 확장해 보면 아래와 같이 dotnet CLI가 생성한 CSExam1.csproj와 Program.cs 그리고 bin과 obj folder를 볼 수 있을 것입니다.

 

참고로 OUTPUT panel에서 'C# Dev Kit'을 선택하면 solution을 어떻게 인식하고 처리했는지를 볼 수 있습니다.

 

VSCode의 SOLUTION EXPLORER에서 기본적으로 열려있는 CSSTUDY01 folder를 접고 하단에 SOLUTION EXPLORER를 mouse를 통해 맨 위로 끌어올린 후 CSStudy01 -> CSExam1 folder순으로 확장하여 표시되는 Program.cs를 선택해 해당 file을 열어봅니다.

 

Program.cs의 source code를 아래와 같이 변경합니다.

using System.Text;

// See https://aka.ms/new-console-template for more information
Console.OutputEncoding = Encoding.UTF8;
Console.WriteLine("안녕, World!");

 

2) dotnet CLI를 사용해 source code compile 하고 실행하기

 

SOLUTION EXPLORER에서 CSExam1 project를 선택한 뒤 mouse오른쪽 button을 눌러 'Open In Integrated Terminal'을 선택합니다. 그런 후 terminal이 실행되면 dotnet run명령을 사용해 project를 실행합니다. 그러면 termianl에서는 project의 실행결과를 아래와 같이 표시할 것입니다.

 

Program.cs에서 다시 아래와 같이 code를 수정합니다.

using System.Text;

// See https://aka.ms/new-console-template for more information
Console.OutputEncoding = Encoding.UTF8;
Console.WriteLine("안녕, World!");
throw new System.Exception(); //추가된 구문

 

다시 dotnet run을 실행해 그 결과를 확인합니다.

 

3) 두 번째 project 추가하기

 

두 번째 project를 추가하기 위해 'cd ..' 명령으로 상위 folder이동 후 아래 명령을 통해 'CSExam2'이름의 project를 생성합니다. 단, VS2022 예제와 마찬가지로 top level program기능은 사용하지 않도록 합니다.

dotnet new console -o CSExam2 --use-program-main

-o switch를 사용하면 두번째 project를 생성하기 위한 CSExam2 folder를 생성할 필요가 없습니다.

 

그리고 생성한 project를 solution에 다음과 같이 추가합니다.

dotnet sln add CSExam2

 

VSCode의 SOLUTION EXPLORER에서 CSStudy01 folder를 보면 CSExam2 folder가 추가되어 있음을 확인할 수 있는데 해당 folder를 확장하여 Program.cs file을 열고 그 안에 저장된 Main함수를 확인합니다. 그리고 해당 file을 VS2022예제와 마찬가지로 아래와 같이 변경합니다.

namespace CSExam2;

class Program
{
    static void Main(string[] args)
    {
        Console.WriteLine(Environment.OSVersion.VersionString);
    }
}

 

그리고 TERMINAL에서 'cd CSExam2'명령으로 CSExam2 project folder로 진입한 뒤 'dotnet run'명령을 입력해 해당 project를 실행합니다.

 

성공적으로 실행되면 아래와 같은 결과를 표시할 것입니다.

 

참고로 VSCode의 TERMINAL에서 각각의 project folder위치에 해당하는 TERMINAL을 개별적으로 열어둘 수 있습니다. 이렇게 하면 일일이 project의 실행을 위해 cd 명령으로 folder를 이동하지 않아도 됩니다. 해당 설정은 SOLUTION EXPLORER에서 원하는 project folder를 선택하고 mouse오른쪽 button을 눌러 'Open In Integerated Terminal'을 선택합니다. 이렇게 원하는 project의 TERMINAL을 이렇게 열고나서 TERMINAL의 오른쪽 panel을 보면 각각의 TERMINAL이 생성되었음을 볼 수 있는데 이들을 mouse로 선택하면 원하는 TERMINAL사이를 전환할 수 있습니다. 기본적으로 이렇게 표시되는 이름은 TERMINAL인데 해당 TERMINAL을 mouse오른쪽 button으로 눌러 rename을 선택하면 TERMINAL의 이름을 변경할 수 있습니다.

VS2022에서 project를 실행하면 project folder의 bin\Debug\net9.0 folder안에서 실행되는 반면 TERMINAL에서 dotnet CLI를 통해 dotnet app을 실행하면 project folder에서 실행된다는 차이가 있습니다.

Project에서 사용된 csproj나 sln 및 기타 source file은 VS2022나 VSCode에서 모두 동일하지만 project가 실행되는 bin과 obj foler에서 문제가 발생할 수 있으므로 VS2022와 VSCode에서 동일한 project를 열어야 하는 경우에는 bin과 obj folder를 삭제하는 것이 좋습니다.

예제로 생성한 Console App Project는 생성가능한 수많은 template 중 하나일 뿐입니다. 다른 유형의 project라 하더라도 기본절차는 모두 동일합니다. 다만 일부 명령에 사용되는 switch가 달라질 수 있는데 이에 대한 상세한 내용은 아래 link에서 찾아볼 수 있습니다.
https://github.com/markjprice/cs13net9/blob/main/docs/ch01-project-options.md

 

5. 도움 받을 수 있는 방법

 

어떤 programming언어든 이제 막 시작할 때도 마찬가지겠지만 수년간 해당 직무에 종사해 온 숙련자도 모든 걸 기억하고 있지는 않기 때문에 외부로부터 특정 정보를 찾아보는 경우는 흔하다고 할 수 있습니다. 나에게 어떤 문제가 생겼을 때 어떻게 하면 나에게 가장 적합한 정보를 찾아볼 수 있는지를 미리 알아둔다면 그만큼 빠르고 정확한 대처가 가능할 것입니다.

 

1) Micorsoft Leran

 

Microsoft사의 개발자도구와 platform에 관한 가장 방대하며 완벽한 문서로는 Microsoft Learn이라는 기술문서가 있으며 거의 대부분의 기술적 정보들을 담고 있습니다.

https://learn.microsoft.com/ko-kr/docs/

기술 문서

 

또한 Micorsoft Q&A에서는 생성형 AI를 제공하고 있으므로 고품질의 답변을 얻을 수 있습니다.

https://devblogs.microsoft.com/engineering-at-microsoft/how-we-built-ask-learn-the-rag-based-knowledge-service/

 

2) dotnet 명령어

dotnet 명령어는 application을 생성하고 build 하는데 필요한 모든 기능을 제공하고 있습니다. Visual Studio와 같은 IDE를 사용하지 않는다면 dotnet은 아마도 필수가 될 것입니다.

 

dotnet에서는 아래 명령을 통해 필요한 답을 구할 수 있습니다.

dotnet help [keyword]

 

예를 들어 dotnet에서 new명령에 관한 자세한 사항을 알고 싶다면 다음과 같이 사용할 수 있습니다.

dotnet help new

 

이렇게 하면 관련정보를 포함하고 있는 web page를 표시할 것입니다.

 

dotnet에서 도움을 구할 수 있는 또 다른 방식으로 아래와 같은 사용법도 유효합니다.

dotnet [keyword] -?|-h|--help

 

예를 들어 new에 관한 내용을 살펴보려면 다음과 같이 사용할 수 있습니다.

dotnet new -h

 

위와 같이 하면 new다음에 사용가능한 다양한 option들을 자세히 표시할 것입니다. -?와 -h, --help는 모두 동일합니다.

 

3) Type 정의와 member 살펴보기

 

개인적으로 생각했을 때 VS2022나 VSCode에서 가장 유용한 기능 중 하나는 '정의로 이동(Go To Definition)'이라는 기능입니다. 이 기능은 assembly의 metadata를 읽어 type이 가진 member를 포함해 type이 어떻게 정의되어 있는지를 보여줄 수 있습니다. ILSpy와 같은 Decompiler들도 metadata와 IL code를 읽어 이를 C#이나 다른 언어의 code로 되돌려 주는데 이와 비슷한 원리를 사용합니다.

 

유사한 기능으로 'Go To Implementation'도 있는데 이는 metadata나 decompile을 통하는 대신 선택적 source link기능을 사용해 실제 source code가 내장되어 있다면 해당 source code를 표시하는 기능입니다.

'Go To Definition'는 member나 type에 대한 decompil 된 metadata로 이동하지만 이전에 source link를 본 적이 있다면 그곳으로 이동합니다. 'Go To Implementation'은 member나 type에 대한 source link 구현으로 이동하지만 source link를 비활성화했다면 decompile 된 metadata로 이동할 것입니다.

 

VS2022에서 'Go To Definition'을 사용해 보기 위해 우선 Tools -> Options -> Text Editor -> C# -> Advanced에서 'Enable navigation to Source Link and Embedded sources'항목을 check해제하고 저장합니다.

 

그리고 CSExam1 project의 Program.cs에서 Console부분에 mouse오른쪽 button을 눌러 'Go To Definition' menu를 선택하면 editor에서 Console이 어떻게 정의되어 있는지 표시할 것입니다.

 

이를 통해 Console class는 정적 class이며 내부에도 모두 정적 method만 존재한다는 것을 알 수 있습니다. 또한 각 method에 대해서 Microsoft가 기재한 주석을 통해 해당 method가 대략적으로 어떠한 역할을 수행하는지도 파악할 수 있습니다.

 

물론 필요하다면 다른 type에 대해서도 동일한 방법으로 내부를 살펴볼 수 있습니다. 아직은 이런 내용들이 친숙하게 다가오지 않겠지만 C#을 충분히 익힌 뒤 다시 이 부분을 살펴보면 많은 걸 이해할 수 있을 것입니다.

 

4) Inlay hints 설정

 

Inline hints라고도 하는 inlay hints는 method를 호출할 때 해당 method와 일치하는 매개변수명을 표시하여 어떠한 값이 어떠한 매개변수에 할당되어 있는가를 알려주는 유용한 기능입니다. 이 기능을 사용하려면 VS2022에서 Tool -> Options -> Text Editor -> C# -> Advanced에 존재하는 Inline Hints의 'Display inline parameter name hints'를 check 하거나

 

VSCode라면 File -> Preferences -> Settings -> Extentions -> C# -> Text Editor에 있는 'Enable Inlay Hints For Parameter'의 'Display inline paramter name hints'를 check 하면 됩니다.

 

5) Stack Overflow에서 검색하기

 

Stack Overflow는 수많은 개발자와 소통할 수 있는 가장 유명한 website로 다양한 질문글을 등록하고 그에 대한 답을 구할 수 있는 곳입니다. 다만 이미 수많은 질문글들이 올라와 있기 때문에 궁금한 점이 있다면 먼저 그에 대한 질문글을 올리기 전에 이미 다른 사람이 동일한 질문글을 올리지 않았는지 검색해 볼 필요가 있습니다.

https://stackoverflow.com/

Newest Questions

 

6) Google 검색하기

 

Google검색 역시 많은 개발자가 원하는 답을 얻기 위해 시도하는 것 중 하나입니다. 하지만 필요한 답을 좀 더 정확히 얻기 위해서는 몇 가지 검색 option을 알아둘 필요가 있습니다. 예를 들어 C#의 if문에 관한 내용을 검색해 보기 위해 무작정 'if'만을 검색창에 입력해 보면 수많은 if문의 검색결과를 보게 될 것입니다. 이중에는 C#에 관련된 내용도 포함될 수 있지만 그렇지 않은 것도 있으며 심지어 programming과는 전혀 관련 없는 정보까지 장황하게 나열될 수 있습니다.

 

이러한 결과를 줄이기 위해서는 검색할 대상을 위에서 언급한 Stack Overflow와 같은 site로 제한해 둘 수 있으며, C++이나 Java, Python과 같은 관심 외에 언어 역시 제거하고 오로지 C#과 .NET만을 대상으로 검색영역을 지정할 수 있습니다. 이러한 방식으로 실제 검색을 수행하려면 다음과 같은 내용으로 검색 keyword를 지정하면 됩니다.

if site:stackoverflow.com +C# -Java