[C# 13과 .NET 9] 1. .NET 개요

우선 시작하기전 Visual Studio 2022(이하 줄여서 Visual Studio) 혹은 Visual Studio Code(이하 줄여서 VSCode)를 사용하기 위한 기본적인 환경설정방법을 알아보고자 합니다. 또한 .NET과 .NET Core, .NET Framework, Mono, Xamarin 그리고 .NET Standard와 같이 이름이 비슷한것들에 대해서 명확한 차이점을 알아볼 것이며 Visual Studio와 VSCode를 사용해 C#13과 .NET9기준의 간단한 Application을 생성해 보고 검토해 봄으로서 전체적인 개념을 잡아볼 것입니다.

 

이번 Chapter에서 시작할 주요 내용은 다음과 같습니다.
- 개발환경설정
- .NET의 이해
- Visual Studio를 사용해 Console App만들기
- VSCode를 사용해 Console App만들기

1. 개발환경설정

 

C#개발을 시작하려면 C# Code를 작성할 Editor가 필요합니다. 대게 Microsoft사의 제품을 사용하지만 원한다면 다른 회사의 제품을 사용할 수도 있습니다.

 

Microsoft는 다음과 같은 Code편집기 및 IDE(Integrated Development Enviroments) 제품군을 배포하고 있습니다.

• Visual Studio for Windows
• VS Code for Windows, Linux, Mac
• VS Code for Web, GitHub Codespace

이 외에 JetBrains사에서 만든 C# Code 편집기인 Rider가 있는데 cross-platform이기에 Windows, Linux, Mac에서 모두 사용할 수 있습니다. 오랜기간 C#개발자에게 꾸준히 사용되어 온것으로 본래 유료제품이었지만 2024년 10월부터 비상업용목적한에서 무료로 사용할 수 있게 되었습니다.

JetBrains사는 훌륭한 제품을 제공하는 꽤 괜찮은 회사지만 Rider와 Visual Studio확장 기능인 ReSharper만의 특이한 동작은 약간 어색할 수 있습니다. 예를 들어 Razor Pages,  Razor Views, Blazor Components에서 ' Cannot resolve symbol'과 같은 오류를 표시할 수 있습니다. 그럼에도 불구하고 해당 Application을 Build하고 실행하는데는 이무런 문제가 없습니다. 만약 Unity와 관련된 plugin을 설치했다면 Unity Game 개발자에게 이런 오류는 다소 심각할 수 있겠지만 그런 Project가 아니라면 해당 오류는 적용되지 않습니다.

 

.NET 세계에서 가장 많이 사용되는 도구로는 단연 Visual Studio를 들 수 있습니다. 크거 무거운 만큼 많은 것을 할 수 있으며 이를 위해 자체적인 Mechanism을 제공함으로서 이를 사용하는 .NET 개발자에게 많은 편의성을 부여하고 있습니다. 심지어 일부 개발자는 Project설정을 변경하거나 Code File을 편집하는등의 .NET관련작업을 수행하는데 Visual Studio가 유일한 방법이라고 오해하는 경우도 있습니다.

 

하지만 Visual Studio나 기타 다른 모든 도구는 수동적인 작업에 편의성을 더해주는 도구일뿐 극단적으로 말하면 Code작성은 메모장을 통해서도 할 수 있으며 compile(또는 build라고도 함)을 위해 dotnet command-line interface를 사용하면 이를 Compile하여 dll 또는 exe와 같이 실행가능한 형태의 file을 생성할 수 있습니다.

 

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

 

C#과 .NET을 학습하기에 가장 좋은 도구와 Application의 유형은 어떤것이 있을까?

 

C#언어를 학습할때 가장 좋은 도구는 Code의 작성과 설정에 도움을 주면서도 실제 발생하고 있는 일을 감추지 않는 것입니다. IDE의 경우 GUI환경의 interface를 제공함으로서 사용하기에는 좋지만 실제 사용자를 위해 어떤 동작을 수행하는지 자세히 나타내지 않는게 대부분입니다. 따라서 완전자동화된 거대한 도구보다는 Code를 작성하는데 도움을 주면서도 기능은 부족할 수 있지만 실제 동작을 세부적으로 살펴볼 수 있는 도구가 학습에는 유리하다고 볼 수 있습니다.

 

물론 어떤 도구든 이미 익숙하게 사용하고 있는 것이거나 혹은 귀하가 속한 조직이 이미 사용하고 있는 것이면 그것을 사용해도 괜찮을 것입니다. 그렇기에 Visual Studio든 VSCode든 Rider든 자유롭게 사용할 도구를 선택할 수 있으며 어떤것이 더 우위에 있다고 말할 수는 없습니다.(도구를 사용하는 것에 관한 설명은 최대한 자제하고자 하지만 필요한 경우  이에 대한 내용을 언급할 수 있습니다. 다만 현존하는 모든 도구를 가지고 설명을 진행할 수 없기에 Visual Studio와 VSCode로만 설명이 한정될 것입니다.)

 

C#언어와 많은 .NET Library학습을 위한 가장 좋은 Application의 유형은 불필요한 Code로 산만함을 유발하지 않는 것이여야 합니다. 예를 들어 단순히 if문을 작성하기 위한 학습을 진행하기 위해 Windows Desktop Application이나 Website전체 Project를 생성하는 것은 너무 낭비에 해당할 수 있습니다.

 

따라서 C#과 .NET을 학습하기 위해 가장 간수화된 Console App Project를 사용하고자 합니다. 이런 방법으로 시작해 어느정도 학습이 이루어지면 기타 다른 Project를 통해 필요한 더 많은 학습을 더 진행할 수 있을 것입니다.

 

2) Cross-Platform개발을 위한 VSCode

 

VSCode는 현재 가장 많이 사용되면서도 가벼운, Microsoft의 유일한 Cross-Platform Code Editor입니다. Cross-Platform답게 Windows, macOS뿐만 아니라 Red Hat Enterprise Linux(RHEL) 및 Ubuntu를 포함한 다수의 Linux Version에서 사용할 수 있습니다.

 

VSCode는 광범위하며 계속해서 성장중인 다수의 확장기능을 통해 C#뿐만 아니라 다른 많은 언어를 지원하고 있기에 최신의 Cross-Platform개발을 위한 가장 좋은 선택이라고 할 수 있습니다. VSCode의 많은 확장기능중 C#과 .NET개발자에게 가장 중요한 확장기능으로는 C# Dev Kit이 있습니다. 2023년 6월 preview로 처음 발표되었으며 VSCode를 일반적인 범용목적의 Code Editor에서 C#과 .NET개발에 최적화된 도구로 전환시켜 주는 중요한 확장도구입니다.

아래 Link를 통해 C# Dev Kit에 관한 공식안내문서를 확인할 수 있습니다.
https://devblogs.microsoft.com/visualstudio/announcing-csharp-dev-kit-for-visual-studio-code/

 

App 개발을 위해 VSCode를 선택한다는 것은 Cross-Platform개발을 위해 Cross-Platform Code Editor를 사용한다는 것을 의미합니다. 뿐만 아니라 ARM Processor에서도 사용할 수 있으므로 Apple Silicon과 Raspberry Pi개발에도 동일하게 활용할 수 있습니다.

 

다만 Cross-Platform특성상 Web개발에는 강력한 지원을 제공하지만 상대적으로 Mobile이나 Desktop개발에는 다소 취약한 면이 존재합니다. 그럼에도 불구하고 VSCode는 단연코 가장 인기있는 Code Editor로서 Overflow설문에 의하면 전체 개발자중 약 73%이상이 VSCode를 사용하는 것으로 파악되고 있습니다. 관련 내용은 아래 link에서 확인하실 수 있습니다.

 

2024 Stack Overflow Developer Survey

2024 Stack Overflow Developer Survey

 

3) Cloud개발을 위한 GitHub Codespaces

 

GitHub Codespaces는 VS Code기반하에 완벽하게 구성된 개발환경으로서 Cloud상에서 host된 그대로 모든 Web Browser에서 사용할 수 있습니다. Cloud환경이지만 Git Repos, 확장기능, 내장 Command-Line Interface를 지원하고 모든 Device상에서 Code를 편집, 실행, TEST할 수 있습니다.

 

하지만 GitHub Codespaces를 완벽하게 작동시키고 실질적으로 유용하게 사용하려면 License비용이 발생될 수 있음에 주의하시기 바랍니다.

GitHub Codespaces에 관한 추가적인 사항은 아래 link를 참고하시기 바랍니다.
https://github.com/features/codespaces

 

4) .NET 개발전용 Visual Studio

 

Visual Studio를 사용하면 Console App 및 Web관련, Desktop App까지 거의 모든 류의 Application을 생성할 수 있습니다.

 

그런데 Cross-Platform Mobile App을 개발하기 위해 Visual Studio를 사용하면 이를 Compile하기 위해 여전히 macOS와 Xcode가 필요할 수 있습니다. Visual Studio(2022기준)는 Windows에서만 동작하는데 Windows 10의 경우 Home, Professional, Education, Enterprise에서 Version 1909이상에서만 가능하며 Windows 11이라면 Home, Pro, Pro  Education, Pro for Workstations, Enterprise, Education에서 Version 21H2이상에서만 가능합니다. Windows Server라면 2016이상도 지원합니다. 32bit Windows나 Windows S Mode는 지원하지 않습니다.

Visual Studio for Mac은 .NET 8이후부터는 공식적으로 지원하지 않으며 2024년 8월에 공식적으로 지원이 종료됩니다. 만약 Visual Studio for Mac을 사용중이라면 VS Code for Mac나 Rider for Mac으로 전환해야 하며 가상환경을 통한 Windows혹은 Microsoft Dev Box와 같은 기술을 사용한 Cloud에서  Visual Studio for Windows을 사용할 수 있습니다. 관련된 내용은 아래 Link를 통해 확인할 수 있습니다.


https://devblogs.microsoft.com/visualstudio/visual-studio-for-mac-retirement-announcement/

 

5) .NET 9 Application 배포

 

.NET 9은 배포를 위한 아래 Platform을 지원하고 있습니다.

• Windows : Windows 10 Version 1607 부터, Windows 11 Version 2200 부터, Windows Server 2012 R2 SP1 부터, Nano Server 2019 또는 2022
• Mac : macOS Catalina Version 10.15 및 Rosetta 2 x64 emulator 부터
• Linux : Alpine Linux 3.19 또는 3.20, CentOS Stream 9, Debian 12, Fedora 40, openSUSE 15.5 또는 15.6, RHEL 8 또는 9, SUSE Enterprise Linux 15.5 또는 15.6, Ubuntu 20.04, 22.04, 또는 24.04
• 기타 iOS, iPadOS, Mac Catalyst

Windows 7과 8.1에 대한 .NET지원은 공식적으로 2023년 1월에 종료되었습니다. 자세한 사항은 아래 Link를 참고하시기 바랍니다.
https://github.com/dotnet/core/issues/7556

이와는 별도로 확인결과 Update가 충실히 이루어졌다면 .NET9은 Windows 7에서도 설치할 수 있습니다.

.NET 5부터는 Windows Arm64역시 지원되므로 Microsoft Windows Dev Kit 2023 (Project Volterra)와 Surface Pro 11, Surface Laptop 7등에 Device에서 개발및 배포가 가능합니다.

 

지원가능한 모든 .NET Version은 Windows상의 Microsoft Update를 통해 자동으로 Patch될 수 있습니다.

 

6) Visual Studio 내려받기 및 설치

 

Visual Studio는 많은 .NET개발자들이 주요 개발작업에 사용하고 있는 것으로 비록 Code작성을 위해 VSCode를 주로 사용한다고 하더라도 Visual Studio사용에 익숙해 지는 편이 좋습니다. 물론 많은 개발작업을 거치고 난 뒤에야 어떤것이 본인에게 잘 맞는지 판단할 수 있을테지만 .NET이라면 Visual Studio는 어떻게든 사용하게될 가능성이 많은 개발도구입니다.

 

현재 Visual Studio는 Windows용 밖에 존재하지 않으므로 만약 Windows운영체제를 사용하지 않는다면 이 부분에 대한 설명은 건너뛰어도 좋습니다. 대신 macOS나 Linux라면 VSCode를 내려받아 설치할 수 있습니다.

 

2014년 10월 이후부터 Microsoft는 Visual Studio Professional급의 제품을 학생, Open-Source기여자,  개인사용자에 한하여 무료로 사용할 수 있도록 배포하고 있습니다. 이것을 Commnuity Edition이라고 하며 다른 Edition은 유료로 사용해야 합니다.

 

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

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

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

해당 글을 작성하는 시점에 Visual Studio Version은 2022로 Version 17.12입니다. 예상컨데 다음 Update는 18.0으로 2025로서 2025년 상반기에 Release될것으로 보입니다. 기능적으로는 Visual Studio 2022와 거의 동일할 것이지만 설명과는 일부 사용자 Interface면에서 약간의 차이점이 발생할 수 있습니다.

 

Visual Studio 2022설치 File을 내려받아 설치를 시작하고 Workloads Tab에서 아래 항목을 선택합니다.

• ASP.NET 과 web development
• .NET Desktop development (Console App을 포함하고 있음)
• Desktop development with C++ (더 빠르게 시작하고 Memory사용량이 적은 Console App과 Web Service를 배포할 수 있음)

 

선택 후 Install을 Click하여 Installer가 선택한 Software를 내려받을 수 있도록 잠시 기다려 준뒤 해당 Software의 설치를 시작합니다.

 

설치가 완료되면 Launch를 Click하고 Visual Studio를 실행합니다. 처음 실행시에는 Sign in요청을 받을 수 있는데 Microsoft 계정이 있다면 해당 계정을 사용하면 되고 그렇지 않다면 아래 Link를 통해 새로운 계정을 생성하도록 합니다.

Create account

https://signup.live.com/?lic=1

 

또한 처음실행시 개발환경설정이 시작되는데 이때는 Visual C#을 선택하고 Color Theme에서는 자신이 선호하는 임의의 Theme를 선택합니다.

 

참고로 keyboard 단축Key는 Tools -> Options... Menu에서 Keyboard영역을 선택함으로서 설정할 수 있습니다.

 

7) Visual Studio 단축Key

 

Visual Studio는 무수히 많은 단축Key를 가지고 있으며 심지어 몇몇은 이 설정을 변경하여 사용할 수도 있습니다. 이에 관한 좀더 자세한 사항은 아래 Link를 참고 하시기 바랍니다.

 

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

Identify and customize keyboard shortcuts - Visual Studio (Windows)

 

8) VS Code 내려받고 설치하기

 

VS Code는 최근몇해동안 빠르게 발전을 거듭하였으며 이러한 인기는 Microsoft를 놀라게 했습니다. 만약 항상 최신 Update가 반영된 VS Code를 사용하고자 한다면 거의 매일 Version이 Update되는 Insiders Version을 사용할 수 있습니다.

 

주된 개발도구로 Visual Studio를 사용하는 경우에도 한번쯤은 VS Code를 내려받아 설치해보고 직접 사용해볼것을 권장합니다. 개발에 어떤 도구를 사용할지 성급하게 결정할 필요는 없습니다.

 

VS Code를 C# / .NET개발에 제대로 사용하려면 VS Code, .NET SDK, C# Dev Kit등을 설치해야 합니다. 우선 아래 Link에서 VS Code를 내려받을 수 있으며 안정화 Version을 사용할지 Insiders Version을 사용할지는 개인별 선호도에 따라 결정하시면 됩니다.

 

Visual Studio Code - Code Editing. Redefined

Visual Studio Code - Code Editing. Redefined

VS Code를 설치하는데 문제가 발생한다면 아래 Link에서의 공식 문서를 참고하시기 바랍니다.
https://code.visualstudio.com/docs/setup/setup-overview

 

9.0 또는 8.0에 대한 .NET SDK는 아래 Link에서 가능합니다.

 

Download .NET (Linux, macOS, and Windows)

Download .NET (Linux, macOS, and Windows)

대게는 여러 Version에 대한  .NET SDK가 설치되는 경우가 많으며 오로지 단 하나의 Version에 대한 .NET SDK의 설치만을 필요로 하는 경우는 드물다고 할 수 있습니다. 다양한 Version의 Project를 Build해야 한다면 실제 그 만큼의 SDK Version이 설치되어 있어야 하며 Project를 Build할때 마다 어떤 SDK Version을 사용할지 지정할 수 있습니다. .NET8과 .NET9는 2025년 2월 현재 공식적으로 지원되는 .NET Version에 해당하는데 이들 모두를 사용해야 한다면 필요한 SDK를 안전하게 설치하고 사용할 수 있습니다. 다만 여러 Version의 SDK가 설치된 경우 별도로 지정하지 않으면 Project를 Build하기 위해 가장 최신의 SDK가 사용됩니다.

 

C# Dev Kit 확장 도구를 설치하려면 우선 VS Code를 실행해야 합니다. VS Code에서 Extensions Icon을 Click하거나 View -> Extenstions Menu를 선택합니다. C# / .NET 개발자라면 C# Dev Kit은 거의 필수적으로 설치되어야 하는 것으로 확장기능 목록의 제일 상단에 보일 것입니다. 만약 그렇지 않은 경우라면 'C#'검색을 통해 C# Dev Kit을 찾아볼 수 있습니다.

C# Dev Kit은 C# 2.0 혹은 그 이후의 확장도구 Version에 대한 의존성을 갖고 있으므로 C# 확장도구를 별도로 설치할 필요는 없습니다. 또한 C# 확장도구는 2.0 Version부터는 새로운 Language Server Protocol(LSP) host를 갖고 있으므로 더이상 OmniSharp을 사용하지 않습니다. 또한 C# Dev Kit은 .NET Install Tool과 IntelliCode for C# Dev Kit에 대한 확장도구에 대한 의존성을 가지므로 C# Dev Kit을 설치하면 의존성을 가진 이들도 System에 같이 설치될 것입니다.

 

C# Dev Kit을 찾았으면 Install을 눌러 관련 Package를 내려받고 설치하는 동안 잠시 기다려 주면 됩니다.

C# Dev Kit을 설치할때는 C# 확장도구 보다 훨씬 제한적인 license를 가지므로 관련 license전반사항에 대해 숙지하는것이 좋습니다.
https://marketplace.visualstudio.com/items/ms-dotnettools.csdevkit/license

 

9) 다른 확장 기능 설치

 

상기 언급한 필수 확장도구 이외에 필요하다면 아래와 같은 확장도구를 추가로 설치할 수 있습니다. 이 밖에도 아래 Link를 통해 다양한 확장기능을 찾아볼 수 있습니다.

https://marketplace.visualstudio.com/vscode

Visual Studio Marketplace

이름	식별자	기능
MSBuild project tools	tintoy.msbuild-project-tools	<PackageReference>요소에 대한 자동완성을 포함해 MSBuild project file들에 대한 IntelliSense를 제공합니다.
Markdown All in One	yzhang.markdown-all-in-one	Keyboard 단축key, 목차, Preview등 Markdown문서 작성에 필요한 다양한 기능을 제공합니다.
Polyglot Notebooks	ms-dotnettools.dotnet-interactive-vscode	Notebook에 대한 .NET과 기타 다른 언어에 대한 사용지원을 추가합니다. 또한 Jupyter 확장도구에 대한 의존성을 가지고 있습니다.
ilspy-vscode	icsharpcode.ilspy-vscode	.NET, .NET Framework, .NET Core, .NET Standard에 대한 MSIL Assembly의 Decompile을 지원합니다.
REST Client	humao.rest-client	VS Code안에서 HTTP요청을 보내고 응답을 수신받을 수 있습니다.

 

참고로 명령줄(Terminal)에서 아래 명령을 사용해 확장도구를 관리할 수 있습니다.

code --list-extensions	설치된 확장도구를 나열합니다.
code --install-extension <식별자>	식별자에 해당하는 확장도구를 설치합니다.
code --uninstall-extension <식별자>	식별자에 해당하는 확장도구를 삭제합니다.

 

예를 들어 C# Dev Kit 확장도구를 설치하고자 한다면 아래와 같은 형태로 명령어를 사용할 수 있습니다.

code --install-extension ms-dotnettools.csdevkit

 

10) VS Code Version 확인

 

Microsoft는 거의 매달 VS Code의 새로운 Version을 Release하고 있으며 bug-fix version은 그 보다 더 자주 배포되고 있습니다. 예를 들어 1.93.0의 Version이 Release된 후에는 1.93.1의 bug-fix Version이 뒤이어 Release되었습니다.

 

2025년 2월 현재 최신 Version은 1.96.4이지만 이 보다 더 중요한 것은 C# Dev Kit 또는 C# 확장기능의 Version으로 이들 확장기능에 대해서는 수시로 Update를 진행해 주는 것이 좋습니다. 특히 C# 확장 기능은 Code를 입력하는 동안 IntelliSense기능을 제공하며 Code Navigation, Debugging 기능등을 제공하고 있으므로 설치하는 것을 권장하며 가장 최신의 C#언어기능을 지원하기 위해 최신의 Version을 꾸준히 유지해 줘야 합니다.

 

11) VS Code의 단축Key

 

VS Code에 대한 단축Key를 새롭게 설정하는것도 가능하며 자세한 사항은 아래 Link를 참고해 주시기 바랍니다.
https://code.visualstudio.com/docs/getstarted/keybindings

VS Code의 단축Key는 OS마다 달라질 수 있으며 관련 PDF자료는 아래 Link를 통해 내려받을 수 있습니다.
Windows : https://code.visualstudio.com/shortcuts/keyboard-shortcuts-windows.pdf
macOS : https://code.visualstudio.com/shortcuts/keyboard-shortcuts-macos.pdf
Linux : https://code.visualstudio.com/shortcuts/keyboard-shortcuts-linux.pdf

2. .NET 개요

 

.NET, .NET Core, NET Framework, .NET Standard와 Xamarin은 개발자가 Application과 Service를 Build하는데 사용하는 서로 관련되고 중복되는 Platform입니다.

.NET의 과거에 대해 관심이 있는 경우라면 아래 글에서 '2.NET의 이해'을 참고해 주시기 바랍니다.

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

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

 

상위 글과 관련해서는 이미 많은 사람들이 알고 있기도 하며 이전과 완전히 동일한 내용이기에 여기서는 이에 대한 설명을 생략하고자 합니다.

 

1) .NET의 지원주기

 

.NET의 Version은 Long-Term Support(LTS)나 Standard-Term Support(STS)(공식적으로 Current라고 함) 또는 Preview로 나눌 수 있습니다.

• LTS : LTS는 잦은 Update를 필요로 하지 않는 Application에 적합한 선택입니다(물론 보안을 위해 매달 .NET Runtime을 Update할 필요는 있지만). LTS는 Microsoft에서 GA(General Availability:실사용단계, Beta등의 단계를 거친후 정식 Service가 이루어지것)이후 3년간 또는 다음 LTS Release이후 1년간지원되며 이 둘이 겹치는 경우 더 긴쪽으로 지원이 유지됩니다.
• STS : Feedback을 통해 반영된 여러 기능이 포함된 것으로 최신의 향상된 접근성을 지원하므로 개발이 활발하게 진행중인 Application에 적합합니다. STS는 GA이후 18개월동안 또는 다음 LTS나 STS가 Release된 후 6개월동안 지원되며 이 둘이 겹치는 경우 더 긴쪽으로 지원이 유지됩니다.
• Preview : 공개 TEST를 위한 것으로 미리 새로운 언어나 Library, App, Service Platform등의 기능을 접해볼 수 있기 때문에 최신의 기술을 경험해 보고자 하는 개발자에게 유용합니다. 해당 Version에서는 대개 Microsoft의 지원을 받을 수 없지만 일부 Preview나 Release Candidate(RC)의 경우 Go Live로 선언될 수 있으며 이 경우 Production상에서 Microsoft의 지원을 받을 수 있습니다.

또한 STS와 LTS는 그들의 생명주기안에서 보안과 신뢰성을 위해 중대한 Patch가 이루어질 수 있으므로 이를 주기적으로 확인하는 것이 좋습니다. 예를 들어 System이 .NET 9.0.0 Version으로 동작중인 상태에서 9.0.1 Version이 Release되었다면 9.0.1 Version을 설치할 수 있습니다. Update는 Patch Tuesday라고 하여 매월 둘째 주 화요일에 Release됩니다.

 

아래 표는 .NET의 지원주기를 시각화 하여 표시한 것으로 파란색은 LTS Release에 대한 3년 지원 주기이며 노란색은 STS Release에 대한 1년6개월의 지원 주기를 나타낸 것입니다.

 

.NET 9의 생명주기동안에도 .NET 8은 여전히 지원될 것이며 그 안에 .NET 10이 Release될 것입니다. 새로운 .NET이 Release되는 경우 관심있다면 최신의 .NET에 대한 정보를 별도로 수집해 볼 필요가 있습니다. 현재 이 글을 보고 있는 여러분은 .NET 8이나 .NET 10을 사용할 수도 있지만 분명한건 미래에는 어떻게 바뀔지 아무도 알 수 없으므로 이 글역시 .NET 10에 관한 어떠한 기능도 다룰 수 없습니다.

 

만약 새로운 Project를 위해 LTS를 적용해야 한다면 현 시점에서는 .NET 8로 Target Version을 맞춰야 합니다. 그런 후에 2025년 .NET 10이 Release되면 해당 Version으로 Migrate하길 권장합니다. .NET 9는 STS이므로 LTS에 적용하기에는 적합하지 않으며 2026년에 .NET 8의 지원이 중단되기도 전에 .NET 9의 지원이 먼저 중단될 것이기 때문입니다. .NET 10이 Release되면 .NET 8의 지원기간은 1년이 남게 되므로 그 안에 Project의 Update를 진행해야 합니다.

어떠한 Release든 가급적 .NET Runtime 9.0.1 과 .NET SDK 9.0.101과 같이 bug-fix Release로의 Update를 진행하시기 바랍니다.

 

2024년 11월 배포시점에 .NET의 모든 Version은 아래 항목을 제외하고 모두 EOL(End of Life)에 도달하게 됩니다.

• .NET 9 (2026년 5월)
• .NET 8 (2026년 11월)
• .NET 10 (2025년 11월 Release예정이며 2028년 11월에 EOL에 도달할 예정)

현재 어떤 .NET Version이 지원되며 언제 EOL에 도달할지 여부는 아래 Link를 통해서도 확인할 수 있습니다.
https://github.com/dotnet/core/blob/main/releases.md

core/releases.md at main · dotnet/core

 

2) EOL (End of Life)

 

End of Support 또는 End of Life(EOF)는 bug fix, 보안 update, 기술적 지원이 Microsoft에서 더이상 이루어 지지 않음을 의미합니다.

 

예를 들어 .NET 6의 경우 2024년 11월에 이미 EOL에 도달했는데 .NET 6를 사용하는 Application을 계속 사용중이라면 다음과 같은 사항을 검토해야 합니다.

• .NET 6에 대한 새로운 보안 update가 나오지 않습니다. 따라서 현재상태를 유지한다면 보안 취약점이 발생할 가능성이 높아집니다.
• .NET 6 Application에 관한 어떠한 기술적 지원도 받을 수 없습니다.
• .NET 9 SDK와 같은 최신의 SDK에서 .NET 6를 대상으로 하는 Application Build하는 경우 NETSDK1138 Build 경고가 발생할 수 있습니다.
• .NET 6를 Target으로 하는 Project 생성시 Visual Studio에서 경고가 발생할 수 있습니다.

3) .NET의 지원단계

 

.NET의 각 Version에 대한 생명주기는 몇가지 단계를 거치게 되는데 그러는 동안 지원수준이 아래와 같이 달라집니다.

• Preview : 해당 Version은 지원되지 않습니다. .NET 9 Preview 1부터 7까지는 2024년 2월부터 8월까지 지원단계에 있었습니다.
• Go Live : GA까지 지원되며 그 이후에는 지원되지 않습니다. 따라서 가능한한 빠르게 최종 Release Version으로 Update해야 합니다. .NET 9 Release Candidate 1과 Release Candidate 2는 각각 2024년 9월과 10월에 지원상태에 있었습니다.
• Active : .NET 9는 2024년 11월 부터 2025년 11월까지 지원상태에 있을 것입니다.
• Maintenance : 생명주기중 마지막 6개월동안에는 보안관련 update만 지원됩니다. 따라서 .NET 9는 2025년 11월 부터 2026년 5월까지 지원상태에 있을 것입니다.
• EOL : 미지원대상입니다. .NET 9은 2026년 5월에 EOL에 도달할 예정입니다.

4) .NET Runtime과 SDK Version

 

독립실행형 App을 구축하는 것이 아니라면 OS에서 .NET Application을 실행할 수 있도록 .NET Runtime을 설치해야 합니다. .NET SDK는 .NET Runtime을 포함하고 있으면서 .NET Code로 App을 구축하는데 필요한 Compiler와 기타 도구들을 같이 포함하고 있습니다.

 

.NET Runtime Versioning은 semantic versioning을 따르고 있으므로 대규모의 변화여부를 나타내기 위해 Major값을 증가시키며 새로운 기능을 나타내기 위해 minor값을, Bug fix를 나타내기 위해 patch값을 증가시키게 됩니다. 반면 .NET SDK Versioning은 이를 따르지 않고 Major와 Minor번호를 Runtime Version과 일치하도록 연결하고 있으며 세번째 Version번호는 SDK의 Minor와 Patch Version을 나타내도록 하고 있습니다. 참고로 이 번호는 초기 버전의 경우 100에서 시작하고 첫 번째 숫자는 Minor버전이 증가함에 따라 증가하며 나머지 두 숫자는 Patch버전이 증가함에 따라 증가합니다.

 

아래 표는 .NET 9를 예시로 관련 Version을 표시하고 있습니다.

	Runtime	SDK
초기 Release	9.0.0	9.0.100
SDK bug fix	9.0.0	9.0.101
Runtime과 SDK bug fix	9.0.1	9.0.102
SDK의 새로운 기능 추가	9.0.1	9.0.200

 

5) 설치된 .NET Version확인 및 삭제

 

.NET Runtime update는 9.x와 같은 주 Version과 호환되며 .NET SDK의 Update된 Release는 Runtime의 이전 Version을 대상으로 구축된 Application을 유지할 수 있기때문에 이전 Version을 안전하게 삭제할 수 있습니다.

 

현재 설치된 SDK와 Runtime은 아래 명령을 통해 확인할 수 있습니다.

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

 

.NET SDK를 삭제는 '프로그램 추가 및 제거(Apps & features)'에서 가능합니다.

또 다른 방식으로 .NET SDK관리도구인 Dots와 같은 third-party도구를 사용할 수도 있습니다.
https://johnnys.news/2023/01/Dots-a-dotnet-SDK-manager
다만 현 시점 기준으로 GitHub Repository로 부터 Source로 부터 App을 Build해야 하고 사용해야 하므로 다소 번거로운 과정이 수반됩니다.

 

6) IL(Intermediate Language)

 

Roslyn이라고 불리는 C# Compiler는 C# Source를 중간언어(Intermediate Language)로 변환을 수행한뒤 이를 Assembly(DLL이나 EXE)로 저장합니다. IL Code는 Assembly언어의 구조와 비슷한데 .NET의 기존 CLR(Common Language Runtime)의 새로운 이름인 CoreCLR이라는 .NET Virtual Machine에서 실행되도록 되어 있습니다. 예전 .NET Framework는 Windows전용으로 동작하는 CLR만 있었다가 .NET Core의 시대로 접어들면서 이제는 Windows뿐만 아니라 macOS, Linux등 각각의 OS마다 하나씩 존재하게 되었는데 이들 모두를 일반적으로 CLR로 언급하고 있습니다.

Runtime에서 CoreCLR은 Assembly로 부터 IL Code를 Load하면 JIT(Just-in-time) compiler는 이를 실제 CPU명령으로 Compile하여 해당 Machine의 CPU상에서 실행하게 됩니다.

이와 같은 2가지 Compile방식에서 유리한 점은 Microsoft가 Windows뿐만 아니라 Linux나 macOS에 대한 CLR만 만들어 두면 실제 운영체제와 CPU명령어에 해당하는 Code를 두번째 Compile과정으로 생성할 수 있으므로 동일한 IL Code를 CLR만 있으면 어디서든 실행할 수 있다는 것입니다.

C#이나 VB.NET, F#등 작성된 Source code의 언어와는 상관없이 모든 .NET Application은 Assembly안에 저장된 명령어에대한 IL Code를 사용합니다. 여기에 맞춰 Microsoft와 기타 여러곳에서는 .NET Decompiler 확장도구인 ILSpy와 같이 Assembly를 열어 IL Code를 가져올 수 있는 Disassembler도구를 같이 제공하고 있습니다.

상술하였듯 .NET의 Compile처리는 일반적으로 Source Code를 IL로 변환하고 IL을 다시 JIT Compile을 사용한 CLR에 의해 runtime에서 기계어 Code로 Compile하는 과정을 수반하게 됩니다. 이러한 방식과는 조금 다른 최근 AOT(Ahead-of-Time) compile은 2단계 Compile 방식의 대안으로서 관심을 받고 있는데 이에 관해서는 추후에 자세히 알아볼 것입니다.

 

7) .NET 비교

 

아래 표에서는 현재까지의 .NET을 비교, 요약하고 있습니다.

종류	설명	적용 OS
.NET	현재 C# 8부터 C# 13언어를 완벽하게 지원하는 가장 최신기술입니다. 기존 App을 이식하거나 새로운 Desktop, Mobile, Web Service등을 개발할 수 있습니다.	Windows, macOS, Linux, Andriod, iOS 등
.NET Framework	C# 8까지만 지원하며 제한된 기능의 과거기술로서 기존 Application을 유지관리하는데만 사용될 수 있습니다.	Windows
Xamarin	Mobile과 Desktop Application 전용	Android, iOS, macOS

 

.NET Project는 (C# Dev Kit 확장 기능이 설치된)등은 Solution이라는 개념을 가지고 있으며 이를 통해 다수의 Project를 한꺼번에 모아서 관리할 수 있습니다. 이후에 만들어볼 Project역시 관리를 위해 Solution을 사용할 것입니다.

 

3. Visual Studio를 사용해 Console App만들어 보기

 

Visual Studio를 통해 어떤 방식으로 Console App을 생성할 수 있는지를 간단히 알아보려고 합니다. 만약 개발용 Machine으로 Windows를 사용하지 않거나 VS Code만을 사용하고자 한다면 해당 설명은 그냥 넘어가도 됩니다. 어차피 Code를 동일할 것이며 단지 사용하는 도구만 달라질 뿐입니다. 그러나 직접 Visual Studio를 사용하지 않더라도 일부 Code에 대한 설명과 함께 Top-Level Program이 어떤 방식으로 작동하는지에 대해 언급할텐데 이는 모든 Code Editor에게 공통된 사항이므로 한번쯤 봐두길 권장합니다.

 

1) Visual Studio를 사용해 Code작성하기

 

ⓐ Visual Studio를 실행합니다.

ⓑ Create a new project 화면에서 C#언어를 선택하여 해당하는 Project Template을 불러온뒤 Search for templates에 Console을 입력하고 Console App을 선택합니다. 이때 Windows전용의 .NET Framework가 아닌 cross-platform project template을 선택해야 하며 C# project template외에 Visual Basic.NET이나 TypeScript를 선택하지 않도록 주의해야 합니다.

ⓒ Next를 Click합니다.

ⓓ Configure your new project화면에서 Project name에 HelloCS를 입력하고 Solution name에는 Study-01를 입력합니다.

 

ⓔ Next를 Click합니다.

ⓕ Additional information의 Framework선택목록에서 .NET 9.0 (Standard Term Support)를 선택합니다. (.NET SDK Version은 원한다면 여러 Version을 설치할 수 있습니다. 만약 해당하는 .NET의 Version이 존재하지 않는다면 다음 Link에서 SDK를 내려받아 설치하시기 바랍니다.->https://dotnet.microsoft.com/ko-kr/download/dotnet)

.NET 다운로드(Linux, macOS 및 Windows)

ⓖ 'Do not use top-level statements'로 표시된 Checkbox는 Check하지 않습니다.(해당 Checkbox를 선택한 채로 Project를 생성한다면 꽤 다른 형태로 Project가 생성된다는 것을 알 수 있는데 이 부분에 대해서는 잠시 후 다시 언급할 것입니다.)

ⓗ 'Enable native AOT publish'이름의 Checkbox는 Check하지 않습니다.

ⓘ Create를 Click합니다.

ⓙ 잠시 후 실행되는 Visual Studio에서 Solution Explorer가 보이지 않는다면 'View -> Solution Explorer'을 선택합니다.

ⓚ Code가 보이지 않는다면 Solution Explorer에서 HelloCS project를 표시하고 있는지 확인합니다. Project에 Program.cs이름의 file이 있다면 이를 double click하여 해당 file을 열어볼 수 있습니다.

ⓛ Program.cs에서는 Code가 아래와 같이 하나의 주석문과 하나의 단일문만 포함되어 있음을 확인할 수 있습니다.

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

해당 Template은 C# 9에서 소개된 top-level program기능을 사용합니다. 해당 기능에 관해서는 잠시 후 알아보겠지만 Code상의 주석에서 말하는 것처럼 아래 Link를 통해 해당내용에 관해 더 많은 정보를 확인할 수 있습니다.
https://learn.microsoft.com/ko-kr/dotnet/core/tutorials/top-level-templates

 

ⓜ Program.cs의 2번째 줄, Console에서 'Hello, C#!'라는 문자열이 표시되도록 변경합니다.

예제 Code및 기타 명령어등을 표현해야 하는 경우 문자열 그대로 나타낼 것입니다. 필요한 경우를 제외하고는 ScreenShot을 직접 표현하지는 않을 것입니다.

 

(1) Visual Studio를 사용해 Code를 Compile하고 실행하기

 

아래 순서는 Code를 Compile하고 실행하기 위한 대략적인 절차를 나타내고 있습니다.

ⓐ Visual Studio에서 Debug -> Start Whitout Debugging Menu를 선택합니다.

Visual Studio에서 Project를 시작할때 debugger를 붙여줄지 여부를 선택할 수 있습니다. debugger를 붙여주면 상대적으로 더 많은 Resource를 필요로 하며 Process가 더 느려질 수 있기 때문에 만약 debug가 필요하지 않다면 붙이지 않고 실행하는 것이 더 유리하다고 말할 수 있습니다. Visual Studio에서 debugger를 붙여주는 것은 또한 단 하나의 Project만 가능하도록 제한됩니다. 따라서 하나 이상의 Project를 debugger를 붙여 실행해야 한다면 Visual Studio자체를 여러 instance로 실행해야 합니다. 상단의 toolbar에서 녹색외곽선의 삼각형을 button을 click하면 debugging없이 Project를 실행할 수 있으며 안쪽전체가 녹색인 삼각형 button을 click하면 Project를 실행할때 debugging으로 실행할 수 있습니다.

ⓑ Application이 실행되면 아래와 같이 Console Window를 화면에 표시하게 됩니다.

Hello, C#! C:\Users\test\source\repos\Study-01\HelloCS\bin\Debug\net9.0\HelloCS.exe (process 23448) exited with code 0 (0x0). Press any key to close this window . . .

 

ⓒ 아무 key나 눌러 Console App창을 닫고 Visual Studio로 돌아옵니다.
ⓓ HelloCS Project를 double click하여 HelloCS.csproj file을 열고 여기에서 Project가 .NET 9.0을 target으로 하는지 확인합니다.

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

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

</Project>

 

ⓔ Solution Explorer toolbar에서 Show All Files button을 click하여 compiler가 생성한 bin과 obj folder가 나타나도록 아래와 같이 설정합니다.

 

(2) Compiler가 생성한 folder와 file

 

compiler에 의해 생성된 folder는 bin과 obj 이렇게 2개가 존재합니다.

• obj : 각각의 source code file을 compile한 개체 file을 하나씩 포함하고 있습니다. 이들 개체는 아직 최종실행file로 연결되지 않은상태입니다.
• bin : 실행가능한 application 또는 class library인 binary를 포함합니다.

물론 아직까지는 이들 folder를 직접 열어보거나 이들 folder가 포함하고 있는 file에 대해 상세히 알필요는 없으므로 일단 해당 folder의 내부를 한번씩 열어보기만 해도 충분합니다.

일단은 compiler가 작동하기 위해서는 임시적인 folder와 file을 생성해야 한다는 것만 기억하면 됩니다. 인위적으로 이들 folder와 file을 삭제할 수 있지만 다음번에 project를 build하거나 실행하게 되면 다시 생성됩니다. 실제 개발자역시 project를 clean상태로 두기위해 이들 folder와 file을 삭제하는 경우가 종종있으며 심지어 Visual Studio안에서도 Build -> Clean Solution menu를 통해 동일한 기능을 실행할 수 있습니다. CLI에서는 'dotnet clean'이라는 동일한 명령을 사용할 수 있습니다.

 

(3) Top-level Programs

 

이전에 .NET project는 간단한 message를 출력하는것 자체만으로도 꽤 많은 수의 code를 필요로 했습니다. 그런데 위에서 생성한 project의 경우, 좀 더 정확히는 .NET 6이후의 project는 compiler가 기본 code를 생성해 주는 기능이 있으므로 정말 필요한 부분의 code만을 포함하고 있음을 알 수 있습니다.

.NET SDK 5나 그 이전에 생성된 project 혹은 project생성시 'Do net use top-level statements'부분을 check했다면 Program.cs file은 아래와 같이 더 많은 code를 포함한 채로 생성되었을 것입니다.

using System;

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

<예제1>

 

.NET SDK 6나 그 이후 부터 Program class와 Main method상에서 정의되는 모든 기본 code는 compile동안 자동으로 생성되고 그 안에 개발자가 작성한 code를 감싸놓게 됩니다.

이것은 top-level program이라는 기능으로 .NET 5에서 처음 도입되었지만 .NET 6에 와서야 비로소 Microsoft는 console app에 대한 project template에 대해 기본적으로 top-level 구문을 사용하도록 update하였고 그런 후 .NET 7이부터는 원하는 경우 이전의 style로 사용할 수 있도록 선택적으로 top-level 구문을 적용할 수 있는 option을 추가하게 되었습니다. 해당 option은 경우에 따라 다르게 사용할 수 있는데 Visual Studio를 사용한다면 'Do net use top-level statements'를 check하면 되고 dotnet CLI를 사용한다면 아래 명령을 사용하면 됩니다.

dotnet new console --use-program-main

 

(4) top-level program 사용시 규칙

 

top-level program을 사용하는 경우 지켜야할 사항은 아래와 같습니다.

• project에서 top-level program code를 사용하는 file은 하나여야 합니다.
• namespace를 선언하는 모든 using문은 file의 상단에 위치해야 합니다.
• 어떤 class나 기타 다른 유형을 선언하는 경우는 file의 가장 하단위 위치해야 합니다.
• 일반적으로 program의 주요 진입점에 해당하는 method의 이름은 main으로 지정해야 하지만 compiler가 생성하는 경우 method의 이름은 <Main>$가 됩니다.

(5) namespace의 암시적 import

 

위에서 업급한 <예제1>에서 using System;문은 System namespace를 import하는 것입니다. 이는 Console.WriteLine구문을 사용하기 위한 것이지만 우리가 생성한 project의 Program.cs에서는 그 어떤것도 import하지 않았습니다.

사실 System namespace를 import하는 것은 여전히 필요한 일이지만 지금의 project에서는 C#과 .NET6에서 도입된 기능의 조합을 사용하는 것으로 동일한 작업을 수행할 수 있습니다.

 

Solution Explorer에서 obj->Debug그리고 net9.0 folder를 순서대로 확장하여 HelloCS.GlobalUsings.g.cs file을 열어봅니다. 해당 file은 .NET 6나 이후의 version으로 target이 설정된 project를 위해 compiler가 자동으로 생성한 것으로서, file에서는 C# 10에서 도입된 global namespace import라는 기능을 사용하여 System처럼 공통적으로 사용되는 일부 namespace를 import하고 있습니다. 그리고 이렇게 선언된 import효과는 project의 모든 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.Net.Http;
global using global::System.Threading;
global using global::System.Threading.Tasks;

 

암시적 import는 .NET 5와 .NET 6사이에 생긴 중요한 변화중 하나로서 추후에 이에 관해서 자세히 알아볼 것입니다. 이렇듯 console app과 같은 다수의 project template에서는 새로운 SDK와 언어의 기능을 사용하여 실제 발생하고 있는 일을 직접적으로 드러내지 않고 처리하는 경우가 있으므로 이러한 것에 대해 관심을 가져줄 필요가 있습니다.

 

(6) 예외를 통해 숨겨진 code 확인하기

다음과 같은 방법을 통해 compiler가 작성한 숨겨진 code를 확인할 수 있습니다.

 

● Program.cs에서 message를 출력하는 문장 다음에 아래와 같이 예외를 일으키는 문을 추가합니다.

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

throw new Exception();

 

● Visual Studio에서 Debug->Start Without Debugging button을 눌러줍니다.(debugging을 걸고 project를 실행하지 마십시오. 그렇지 않으면 debugger가 예외를 잡게 됩니다.)

● 곧 console window가 열리고 숨겨진 Program class를 포함해 <Main>$ method(인수를 전달하기 위한 args매개변수와 함께)의 예외를 application의 실행결과로 표시할 것입니다.

Hello, C#! Unhandled exception. System.Exception: Exception of type 'System.Exception' was thrown.    at Program.<Main>$(String[] args) in C:\Users\test\source\repos\Study-01\HelloCS\Program.cs:line 4

 

(7) Program class의 namespace확인하기

 

Program class의 namespace를 보려면 Program.cs에서 예외를 던져구문 구문앞에 아래 구문을 추가합니다. 이러한 방법으로 Program class에 대한 namespace의 이름을 확인할 수 있으며, 예제에서는 확인된 이름으로 console을 통해 이름을 출력하도록 하고 있습니다.

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

예제에서 사용된 ??를 null 병합 연산자라고 합니다. 예제에서 ??은 Program의 namespace가 null이라면 공백(string.Empty)을 반환하고 그렇지 않으면 namespace값을 가져오라는 의미를 갖고 있습니다. 이들 keyword와 연산자에 관해서는 추후에 좀더 살펴볼 기회가 있을 것입니다. 지금은 대신 code를 보이는 대로 작성하고 실행하여 어떤 결과를 내는지만 지켜보시기 바랍니다.

Visual Studio 2022 Code editor는 code snippet이라는 기능을 갖고 있습니다. 이 기능은 사전에 약속된 일부 code만으로 입력하고 Tab key를 두번 눌러 이를 기반으로 완전한 code를 완성하는 기능입니다. 한 가지 예로 이 기능을 확인할 수 있는데, Console.WriteLine를 입력하고 괄호 중간에 cursor를 위치하도록 하여 출력하길 원하는 나머지 입력만을 수행하도록 하려면 cw를 입력한 뒤 Tab을 두번 빠르게 눌러보시기 바랍니다. 그러면 그 결과를 확인하실 수 있습니다. 현재 Visual Studio에 정의된 codesnippet을 확인해 보려면 Tools -> Code Snippets Manager를 click합니다.

 

Visual Studio에서 Debug -> Start Without Debugging을 click합니다. 그러면 project가 실행되고 console window는 다음과 같은 결과를 표시할 것입니다. 결과로 보면 숨겨진 상태의 Program clss는 namespace없이 정의되어 있음을 알 수 있습니다.

 

(8) Visual Studio를 사용해 두번째 Project 추가하기

 

이제 위에서 만든 solution에서 두번째 project를 추가하여 다중 project를 어떻게 관리할 수 있는지 알아볼 것입니다.

 

● Visual Studio에서 File -> Add -> New Project를 선택합니다.

지금 하려는 것은 기존의 solution에서 새로운 project를 추가하는 것입니다. 따라서 새로운 solution과 project를 생성하는(물론 해당 dialog box에서도 기존 solution에 추가할 수 있는 dropdown기능을 가지고 있기는 하지만...) File -> New -> Project...menu를 선택해서는 안됩니다.

 

●  Add a new project dialog의 최신 project template에서 Console App (C#)을 선택하고 Next를 눌러줍니다.
●  Configure your new project dialog에서 Project name에 'MyEnvironment'를 입력하고 location은 'C:\Users\test\source\repos\Study-01'를 계속 유지한채 Next를 눌러줍니다.
● Additional information dialog에서 .NET 9.0(Standard Term Support)을 선택하고 Do net use top-level statements부분을 check합니다.

Do net use top-level statements부분을 check하는건 이전 style의 Program.cs를 보기 위함입니다.

 

● Create Click합니다.
● MyEnvironment project의 Program.cs code를 보면 project이름과 일치하는 namespace가 정의되어 있음을 확인할 수 있습니다. 또한 Program이라는 이름의 초기 class가 있으며 Main이름의 정적 method역시 args이름의 매개변수와 함께 작성되어 있습니다. method는 void로 어떤것도 반환하지 않습니다.

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

 

● Program.cs의 Main method에서 기존 Console.WriteLine문을 삭제하고 현재 directory와 운영체제 version 그리고 Program class의 namespace를 화면에 출력하도록 아래와 같이 변경합니다.

static void Main(string[] args)
{
    Console.WriteLine(Environment.CurrentDirectory);
    Console.WriteLine(Environment.OSVersion.VersionString);
    Console.WriteLine("Namespace: {0}", typeof(Program).Namespace ?? string.Empty);
}

 

● Solution Explorer에서 Study-01 solution을 mouse 오른쪽 click하고 Configure Startup Project를 선택합니다.
●  Solution 'Study-01' Property Pages dialog box에서 Startup Project를 Current selection으로 설정하고 OK를 눌러줍니다.
● Solution Explorer에서 MyEnvironment project(또는 해당 project의 file 또는 folder)를 click합니다. 그러면 Visual Studio는 MyEnvironment를 진하게 표시함으로서 해당 project가 시작 project로 설정되었음을 표시할 것입니다.

시작 project를 설정하기 위해 상기 방법을 사용하길 권장합니다. 이 방법은 project(또는 project의 file)을 click하는 것만으로 시작 project로 설정하기때문에 시작 project의 전환을 아주 쉽게 수행할 수 있습니다. 물론 project를 mouse오른쪽 click하여 시작 project로 설정할 수 있지만 다른 project를 실행해야 한다면 수동적으로 이를 다시 바꿔줘야 하기 때문에 번거로울 수 있습니다. 이보다는 단순히 project어딘가를 그냥 click하는 것만으로 시작 project의 전환이 이루어지는 것이 더 자연스러울 수 있는데 물론 개인차에 따라 다르게 설정해도 무관합니다. project도 대부분의 경우 한번에 하나의 project만을 실행하지만 추후에는 다수의 시작 project를 설정하는 방법에 대해 논의해볼 것입니다.

 

● Debug -> Start Without Debugging를 선택하여 MyEnvironment project를 실행하고 아래와 같은 결과를 확인합니다.

Windows 10은 단지 brand이름일 뿐이고 공식적인 명칭은 Windows NT입니다. 또한 주 version번호는 10이며 patch version은 19045임을 확인할 수 있습니다.

Visual Studio가 console app을 실행시킬때 [project명]\bin\Debug\net9.0 folder에서 실행됨을 알 수 있습니다. VS Code를 사용할때, 더 정확히는 dotnet CLI를 사용할때는 곧 보게 되겠지만 동작이 다소 달라집니다.

 

2) VS Code로 console app 만들기

 

위에서는 Visual Studio를 사용해 console app을 만들어 보았는데 이번에는 VS Code를 사용하고자 합니다. 만약 VS Code혹은 dotnet 명령줄 도구를 사용하고 싶지 않다면 이 부분은 건너뛰어도 좋습니다.

지금부터의 설명은 모두 Windows를 기반으로 작성한 것이지만 특별한 경우가 아닌 이상 대부분은 macOS와 Linux에서도 동일한 동작을 수행할 것입니다.

주된 차이점이라면 file삭제와 같은 실제 명령줄에서 내리는 명령어로 Windows와 macOS, Linux모두에서 다를 수 있습니다. 하지만 dotnet CLI 도구자체와 그 명령은 모든 platform에서 동일합니다.

 

(1) VS Code에서 code 작성하기

 

● 탐색기를 실행하고 'C:\Users\w10tsp\source\repos\' folder로 이동합니다. 해당 folder는 위에서 이미 생성한 'Study-01'이라는 folder가 존재하는데 비슷한 이름의 folder로 Study-01-vscode라는 folder를 새로 생성합니다.
● cmd나 Terminal을 열고 위에서 생성한 Study-01-vscode folder로 이동합니다. 혹은 Study-01-vscode folder를 mouse오른쪽 click하고 'Open in Terminal'을 선택해도 동일합니다.
● Terminal에서 아래와 같이 dotnet CLI를 사용해 VSCode라는 새로운 solution을 생성합니다.

dotnet new sln --name VSCode

위 명령에서 --name option은 이름을 지정하는 부분인데 이때 --name을 -n으로 사용할 수 있습니다. 만약 이러한 option을 사용해 solution의 이름을 지정하지 않는다면 해당 folder의 이름이 대신 사용됩니다.

sln은 Visual Studio를 사용해 solution을 생성할때도 만들어지는 동일한 solution file입니다. sln은 Microsoft사의 독점적인 file format인데 file의 내용은 다소 장황하며 읽기어려운 면이 있습니다. 또한 project나 solution의 다른 component를 참조하기 위해 GUID(Globally Unique Identifiers)를 사용하는게 특징인데 Microsoft는 이를 대체하는 XML기반의 새로운 format형식을 준비중입니다. 이 새로운 format은 단순하면서도 이전보다 훨씬 읽기쉽게 설계되었는데 slnx file확장자명으로 사용될 예정입니다. 더 자세한 사항은 아래 URL를 참고하시기 바랍니다.

https://github.com/dotnet/sdk/issues/40913

 

● 아래와 같은 결과가 표시되는지 확인합니다.

The template "Solution File" was created successfully.

● Terminal에서 아래와 같이 dotnet CLI를 사용해 새로운 하위 folder와 HelloCS이름의 console app project를 생성합니다.

dotnet new console --output HelloCS

위 명령에서 --output option은 이름을 지정하는 부분인데 이때 --output은 -o로도 사용할 수 있습니다. 'dotnet new'명령은 기본적으로 가장 최신의 .NET SDK version을 대상으로 합니다. 따라서 만약 대상으로 지정되어야 하는 version이 다르다면 -f 혹은 --framework option을 사용해 '-f net9.0'처럼 대상 framework를 지정하면 됩니다.

 

● Terminal에서 아래와 같이 dotnet CLI를 사용해 solution에ㅓ project를 추가합니다.

dotnet sln add HelloCS

 

● 아래와 같은 결과가 표시되는지 확인합니다.

Project `HelloCS\HelloCS.csproj` added to the solution.

● Terminal에서 아래와 같이 VS Code를 실행하고 현재 folder를 열어볼 수 있도록 합니다. (.까지도 포함하여 입력합니다.)

code .

● 'Do you trust the authors of the files in this folder?'라는 message가 표시된다면 'Trust the authors of all files in the parent folder...'checkbox를 click하고 'Yes, Itrust the authors'를 선택합니다.
● VS Code의 EXPLORER에서 STUDY-01-VSCODE foder를 확인하고 HelloCS folder를 확장하여 HelloCS.csproj와 Program.cs이름의 dotnet 명령줄 도구가 생성한 2개의 file과 bin과 obj라는 2개의 folder가 존재하는지 확인합니다.

 

● VS Code의 View -> Output menu를 선택합니다.
● OUTPUT Pane에서 C# Dev kit을 선택하여 도구가 solution을 인식하고 적절한 처리를 수행했는지를 확인합니다.
● EXPLORER아래의 SOLUTION EXPLORER가 존재하는지 확인합니다.
● SOLUTION EXPLORER를 EXPLORER pane위에 drag하여 올려두고 이를 확장합니다.
● SOLUTION EXPLORER에서 HelloCS project를 확장하여 Program.cs이름의 file을 click하여 editor windows에 file의 내용을 표시합니다.
● Program.cs의 두번째 line을 변경하여 console에서 Hello, C#이 출력되도록 text를 변경합니다.

File -> Auto Save를 선택합니다. 이렇게 하면 application을 build할때 마다 매번 file을 저장해야 하는 번거로움을 피할 수 있습니다.

 

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

 

● SOLUTION EXPLORER의 HelloCS project에서 mouse오른쪽 button을 눌러 'Open In Integrated Terminal'을 선택합니다.
● TERMINAL에서 'dotnet run'명령을 입력하고 실행합니다.
● TERMINAL에서 표시하는 application의 실행결과를 확인합니다.
● Program.cs에서 message를 출력하는 구문 다음에 Program class의 namespace이름을 가져와 이를 console로 출력하고 그 다음에 예외가 발생하도록 하는 문을 아래와 같이 추가합니다.

string n = typeof(Program).Namespace ?? string.Empty;
Console.WriteLine($"Namespace : {n}");
throw new Exception();

● 위와 같이 code를 작성 후 다시 'dotnet run'명령으로 application을 실행합니다.
박스 : TERMINAL에서는 keyboard의 위/아래 화살표 key를 사용해 이전에 사용한 명령을 다시 불러올 수 있습니다. 이전에 사용한 명령을 불러오면 왼쪽/오른쪽 화살표키를 사용해 지금명령에 필요한 부분을 수정하고 Enter key를 누르면 해당 명령을 실행할 수 있습니다.
● TERMINAL Window에서는 application의 실행결과를 아래와 같이 표시할 것입니다. 이 message에는 compiler에 의해 숨겨진 Program class와 인수를 전달하는 args매개변수를 가진 <Main>$이름의 method를 포함하고 있는데 아래 결과에서 확인할 수 있는 것처럼 Program class에서는 별도의 namespace를 가지고 있지 않음을 알 수 있습니다.

Hello, C# Namespace : Unhandled exception. System.Exception: Exception of type 'System.Exception' was thrown.    at Program. $(String[] args) in D:\source\repos\CS\Study-01-vscode\HelloCS\Program.cs:line 6

 

(3) VS Code를 사용하여 2번째 project 추가하기

● TERMINAL에서 아래 명령을 사용해 directory를 변경합니다.

cd ..

● TERMINAL에서 MyEnviroment이름의 console app project를 생성합니다. 이때 top-level program style은 사용하지 않도록 합니다.

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

TERMINAL에서 명령을 입력해 실행할때는 현재 위치해 있는 folder가 정확한 위치인지를 확인하고 실행하시기 바랍니다.

● TERMINAL에서 dotnet CLI를 사용해 아래 명령을 실행하여 solution에 새로운 project folder를 추가합니다.

dotnet sln add MyEnviroment

● 위 명령의 실행결과로 아래와 같은 결과를 표시하는지 확인합니다.

'MyEnviroment\MyEnviroment.csproj' 프로젝트가 솔루션에 추가되었습니다.

● SOLUTION EXPLORER의 MyEnviroment project에서 Program.cs file을 열고 Main method를 아래와 같이 수정합니다. 해당 문은 현재 directory와 OS version, Program class의 namespace를 표시합니다.

Console.WriteLine(Environment.CurrentDirectory);
Console.WriteLine(Environment.OSVersion.VersionString);
Console.WriteLine("Namespace: {0}", typeof(Program).Namespace ?? string.Empty);

● SOLUTION EXPLORER의 MyEnviroment project안에서 mouse 오른쪽 button을 click하고 'Open In Integrated Terminal'을 선택합니다.
● TERMINAL에서 'dotnet run'명령을 사용하여 project를 실행합니다.
● TERMINAL에서 아래와 같은 결과를 표시하는지 확인합니다. directory경로는 설정환경에 따라 달리질 수 있습니다.

D:\source\repos\CS\Study-01-vscode\MyEnviroment Microsoft Windows NT 10.0.19045.0 Namespace: MyEnviroment

다수의 termianl window가 열렸다면 TERMINAL오른쪽 편에 있는 이름목록을 click함으로서 이들 사이를 전환할 수 있습니다. 이때 이름은 기본적으로 pwsh, powershell, zsh, bash등 일반적인 이름 중 하나가 될 수 있습니다. 만약 이들 목록중 하나의 이름을 변경하고자 한다면 원하는 이름을 선택하고 mouse오른쪽 button을 눌러 Rename을 선택하면 이름을 바꿀 수 있습니다.

VS Code에서, 더 정확히는 dotnet CLI에서 console app을 실행할때는 <project명> folder에서 실행하지만 Visual Studio는 <project명>\bin\debug\net9.0 folder에서 app을 실행합니다. 이러한 차이는 자칫 실행과정에서 혼동을 줄 수 있으므로 기억해 두는 것이 좋습니다.

.csproj와 .cs file과 같은 source code가 같다고 하더라도 compiler에 의해 자동적으로 생성된 bin과 obj folder에 일치하지 않은것이 있으면 error를 발생시킬 수 있습니다. Visual Studio와 VS Code모두에서 동일한 project를 다루고자 할때 error가 발생한다면 해당 tool에서 project를 열기전 bin와 obj folder를 삭제하고 다시 시도해 보시기 바랍니다.

 

(4) VS Code를 사용한 절차요약

VS Code를 사용해 solution과 project를 생성하기 위한 절차는 아래와 같이 요약할 수 있습니다.

절차	명령
solution을 위한 folder생성	mkdir <folder명></folder명>
생성한 folder로 이동	cd <folder명></folder명>
folder에 solution file생성	dotnet new sln
template을 사용해 folder와 project생성	dotnew new console -o
solution에 folder와 해당 project추가	dotnet sln add
다른 project를 생성하고 추가하는 경우 d와 e를 반복
VS Code를 사용해 solution을 포함하는 현재 folder열기 (현재 folder경로는 점(.)으로 지정)	code .

 

(5) 사용가능한 다른 project유형

 

아래 표는 template으로 생성가능한 다른 project유형을 나열하고 있습니다. 아래 유형은 흔히 사용되는 유형으로 더 많은 template이 존재합니다.

Visual Studio Template	dotnet new
Console App	console
Class Library	classlib
xUnit Test Project	xunit
ASP.NET Core Empty	web
Blazor Web App	blazor
ASP.NET Core Web API	webapi
ASP.NET Core Web API (native AOT)	webapiaot

solution에 기존과 다른 유형의 project를 추가하는 경우의 절차는 동일합니다. 이들 중 극히 일부는 command-line에서 option의 일부가 달라질 수 있지만 대부분은 지정하는 project template의 유형이름만 다를 뿐입니다.

 

4. 도움말 얻기

1) Micorsoft 기술 문서와 Ask Learn

 

Microsoft 개발자 도구와 platform에 관한 완벽한 resource는 Microsoft Learn에 대한 기술문서라고 할 수 있습니다.
https://learn.microsoft.com/ko-kr/docs/

기술 문서

.NET에 대한 Microsoft의 공식문서는 .NET의 모든 version을 다루고 있습니다. 이때 문서상에 표시되는 기본 version은 항상 최신의 GA version입니다. 예를 들어 2024년 11월과 2025년 11월사이 문서에 표시되는 기본 version은 .NET 9가 되며 2025년 11월과 2026년 11월사이 기본 version은 .NET 10이 됩니다. 따라서 아래와 같이 특정 부분(system.diagnostics.codeanalysis.stringsyntaxattribute)에 대한 URL을 사용하면 항상 현재 날짜에 기반하여 해당하는 현재의 version의 문서를 볼 수 있습니다.
https://learn.microsoft.com/en-us/dotnet/api/system.diagnostics.codeanalysis.stringsyntaxattribute

StringSyntaxAttribute Class (System.Diagnostics.CodeAnalysis)

따라서 만약 2025년 11월 이후 .NET 9에 대한 문서를 보려한다면 '?view=net-9.0'을 위 주소끝에 붙여주면 됩니다.
https://learn.microsoft.com/en-us/dotnet/api/system.diagnostics.codeanalysis.stringsyntaxattribute?view=net9.0

StringSyntaxAttribute Class (System.Diagnostics.CodeAnalysis)

또한 현재 기술문서상에서 어떤 .NET version이 지원되고 있는지 확인하려면 '#applies-to'를 주소끝에 붙여줍니다.
https://learn.microsoft.com/en-us/dotnet/api/system.diagnostics.codeanalysis.stringsyntaxattribute#applies-to

StringSyntaxAttribute Class (System.Diagnostics.CodeAnalysis)

해당 문서의 내용에 따라 stringsyntaxattribute는 .NET 7이후문서에서만 볼 수 있습니다.

Microsoft는 이에 더해 최근 Ask Learn이라고 하는 Microsoft Q&A에 대한 생성형 AI를 연결하는 Project를 진행하였습니다. 자세한 사항은 아래 URL을 참고하시기 바랍니다.
https://devblogs.microsoft.com/engineering-at-microsoft/how-we-built-ask-learn-the-rag-based-knowledge-service/

How we built "Ask Learn", the RAG-based knowledge service - Engineering@Microsoft

 

2) dotnet 도구를 통해 도움말 얻기

명령 prompt상에서는 dotnet 도구를 통해 명령어로 도움말을 요청할 수 있습니다.

dotnet help <명령>

위에서 지정된 명령에 따라 예를 들어 'dotnet help add'라고 하면 add명령에 대한 도움말을 web browser를 통해 해당 문서로 확인할 수 있습니다.

dotnet help new 명령은 .NET Core 3.1부터 .NET 6까지만 사용가능하므로 .NET 7이후에는 error를 반환하게 됩니다.

또 다른 방식으로는 command-line 문서가 있으며 사용방법은 아래와 같습니다.

dotnet <명령> -?|-h|--help

 

-?과 -h, --help는 모두 동일한 option이므로 'dotnet new -?'나 'dotnet new -h'등은 command prompt에서 new 명령에 대한 문서를 출력하게 됩니다.

'dotnet help help'는 help 명령에 대한 문서를 web browser를 통해 열게되지만 'dotnet help -h'는 command prompt상에서 해당 문서를 출력하게 됩니다.

 

예를 들어 dotnet build 명령에 대한 공식문서를 web browser를 통해 확인하기 위해 VS Code terminal 또는 command prompt상에서 아래 명령을 입력합니다.

dotnet help build

command prompt상에서 help말을 얻으려면 -? 또는 -h 이나 --help option을 사용해 아래와 같이 명령을 입력합니다.

dotnet build -?

 

3) Type의 정의와 해당 Type의 Member확인하기

Visual Studio의 code editor상에서 가장 많이 사용되는 기능 중 하나는 'Go To Definition(F12)'입니다. 이걸 VS Code에서도 사용할 수 있는데 이를 통해 type의 public 정의 혹은 member가 어떻게 정의되었는지를 compile된 assembly의 metadata를 읽음으로서 확인할 수 있습니다.

ILSpy.NET과 같은 일부 도구에서는 metadata와 IL Code에 대한 reverse-engineering을 수행함으로서 C#이나 다른 언어의 code로 다시 되돌려주기도 합니다.

이와 비슷한 기능으로는 'Go To Implementation'도 있는데 이때는 metadata를 읽거나 decompile하는 대신 source link기능을 사용하여 실제 source code를 표시할 수 있습니다.(내장된 경우)

Go To Definition은 기본적으로 member또는 type에 대한 decompile된 metadata로 이동하게 됩니다. 하지만 이전에 source link를 본적이 있다면 해당 link로 이동하게 됩니다. Go To Implementation도 기본적으로는 member혹은 type에 대한 source link 구현으로 이동하게 되지만 source link를 사용할 수 없는 경우라면 decompile된 meatadata로 이동하게 됩니다.

'Go To Definition'기능을 사용해 보기전 우선 Visual Studio를 사용한다면 Tools -> Options Menu로 이동해 navigation to source로 검색한 뒤 Text Editor -> C# -> Advanced로 이동합니다. 그리고 'Enable navigation to Source Link and Embedded sources' checkbox를 비운뒤 OK를 눌러줍니다. 이 기능은 어떻게 다르게 보이는지를 확인하기 위해 다시 사용할 것입니다.

Definition은 metadata에서 reverse-engineering을 수행하지만 가능한 경우 본래 source code에서 불러오는 경우도 있습니다.

 

HelloCS project에서 Program.cs아래에 다음 구문을 추가해 줍니다.

int z;

int부분을 mouse오른쪽 click하고 Go To Definition을 선택합니다. 그러면 code editor를 통해 int type이 어떻게 정의되어 있는지를 아래와 같이 바로 확인할 수 있습니다.

#region Assembly System.Runtime, Version=9.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
// C:\Program Files\dotnet\packs\Microsoft.NETCore.App.Ref\9.0.1\ref\net9.0\Systehttp://m.Runtime.dll
#endregion

#nullable enable

using System.Diagnostics.CodeAnalysis;
using System.Globalization;
using System.Numerics;
using System.Runtime.CompilerServices;

namespace System
{
    //
    // Summary:
    //     Represents a 32-bit signed integer.
    public readonly struct Int32 : IComparable, IComparable<Int32>, IConvertible, IEquatable<Int32>, IFormattable, IParsable<Int32>, ISpanFormattable, ISpanParsable<Int32>, IUtf8SpanFormattable, IUtf8SpanParsable<Int32>, IAdditionOperators<Int32, Int32, Int32>, IAdditiveIdentity<Int32, Int32>, IBinaryInteger<Int32>, IBinaryNumber<Int32>, IBitwiseOperators<Int32, Int32, Int32>, IComparisonOperators<Int32, Int32, bool>, IEqualityOperators<Int32, Int32, bool>, IDecrementOperators<Int32>, IDivisionOperators<Int32, Int32, Int32>, IIncrementOperators<Int32>, IModulusOperators<Int32, Int32, Int32>, IMultiplicativeIdentity<Int32, Int32>, IMultiplyOperators<Int32, Int32, Int32>, INumber<Int32>, INumberBase<Int32>, ISubtractionOperators<Int32, Int32, Int32>, IUnaryNegationOperators<Int32, Int32>, IUnaryPlusOperators<Int32, Int32>, IShiftOperators<Int32, Int32, Int32>, IMinMaxValue<Int32>, ISignedNumber<Int32>
    {
        //
        // Summary:
        //     Represents the largest possible value of an System.Int32. This field is constant.
        public const Int32 MaxValue = 2147483647;
        //
        // Summary:
        //     Represents the smallest possible value of System.Int32. This field is constant.
        public const Int32 MinValue = -2147483648;
...생략

위와 같은 과정을 통해 int에 대해 다음 사항을 알 수 있습니다.
● struct keyword를 통해 정의되어 있음
● System.Runtime assembly에 속함
● 본래 Int32로 명명됨, 따라서 System.Int32 type의 별칭으로 사용
● IComparable interface를 구현함
● maximum(2147483647)과 minimum(-2147483648)에 대한 상수를 가짐
● Parse와 같은 method를 가짐

위와 같은 과정을 통해 type이나 member의 상세한 code를 본다고 하더라도 아직 code에 대한 의미를 전부 알 수 없을 것입니다. C#언어에 대한 상세한 내용은 앞으로 천천히 진행할 것이므로 지금은 이러한 기능이 존재한다는 것만 알고 있는것으로도 충분합니다.

 

현재 code editor에서 scroll을 내려 하나의 매개변수만 가진 Parse method를 찾아 봅니다.

그러면 아래와 같이 해당 method에대한 주석을 확인할 수 있는데 이를 통해서도 다음과 같은 정보를 확인할 수 있습니다.
● method에 전달되는 string값의 매개변수가 존재함
● method에서 값을 반환하며 해당 값의 data type을 알 수 있음
● method를 호출할때 ArgumentNullException, FormatException, OverflowException의 3가지의 예외가 발생할 수 있으며 method를 호출할때 try 문을 사용하면 어떤 예외가 발생하는지 알 수 있음

 

4) inline 설정(inlay hint)

method를 호출할때는 해당 method에서 정의하는 매개변수이름을 명시적으로 지정할 수 있습니다. 예를 들어 아래와 같은 경우 WriteLine method를 호출할때 format과 arg0에 대한 매개변수를 지정하고 해당 매개변수에 값을 할당하고 있습니다.

Console.WriteLine(format: "Value is {0}", arg0: 19.8);

이때 inlay hint라 불리는 inline hint를 통해서 일일이 typing하지 않고서도 매개변수의 이름을 확인할 수 있습니다.
해당 기능은 Visual Studio와 VS Code에서 사용할 수 있는데 자동적으로 또는 Alt + F1 나 Ctrl key를 누른경우 표현될 수 있도록 설정할 수 있습니다.

 

ⓐ Visual Studio에서 Tools -> Options -> Text Editor -> C# -> Advanced를 순서대로 선택한뒤 설정화면을 내리면 'Inline Hints'를 찾을 수 있습니다. 여기에서 'Display inline parameter name hints'를 Check하고 OK를 눌러줍니다.

ⓑ VS Code에서 File -> Preferences -> Settings를 선택하고 inlay를 검색한 뒤 C# filter를 선택합니다. 그리고 여기에서 'Display inline parameter name hints'를 check합니다.

 

5) Stack Overflow 찾아보기

Stack Overflow는 다양하게 발생할 수 있는 Programming관련 질문을 통해 답을 구할 수 있는 인기있는 website중 하나입니다.
https://stackoverflow.com

Newest Questions

새롭게 발생하는 질문을 올려둘 수 있으며 이미 수많은 질문들과 답변들이 존재하므로 여기에서 원하는 답을 구할 수도 있습니다.

6) Goole 찾아보기

 

필요한 답을 얻기 위해 google을 검색하는 경우도 많습니다. 다만 검색에서 option을 추가하면 좀더 정확한 답을 얻을 가능성이 높아집니다. 예를 들어 garbage collection을 살펴보기 위해 google검색하면 Wikipedia의 computer부분에 정의된 garbage collection정보를 보기도 전에 수많은 쓰레기 수거 Service광고를 마주할 수 있습니다.

따라서 아래와 같이 검색의 기준을 Stack Overflow와 같은 site로 제한하거나 C++이나 Java와 같은 불필요한 언어에 대한 정보대신 C#과 .NET처럼 필요한 것만 추가하면 좀더 정확한 검색결과를 찾을 수 있을 것입니다.

garbage collection site:stackoverflow.com +C# -Java

7) 기타 Programming forum 이용하기

도움을 받는 또 다른 방법은 여러 Programming forum 원하는 질문을 요청하는 것입니다. 이때 도움이 될만한 답을 얻기 위해 아래 사항들을 참고하시기 바랍니다.

• 되도록이면 개인이 아닌 공개 글을 통해 질문하세요. 모든 질문과 그에 대한 답변은 community의 지식자원을 풍부하게 만들게 되므로 개인간 질문대신 공개적인 질문을 통해 여러 사람이 귀하를 도울 수 있도록 하는 것이 좋습니다.
• 질문하기전 스스로 답을 구해보세요. Community로 들어가기전 스스로 답을 찾아보는건 매우 중요한 부분입니다. 이를 위해 검색엔진를 사용하거나 공식 문서를 읽어볼 수 있으며 또는 forum안에서 미리 정해진 답을 구해볼 수도 있을 것입니다.
• 질문이 구체적이면서도 장황하지 않게 하세요. 달성하려면 목표가 무엇인지, 지금까지 문제를 해결하기 위해 어떤것을 시도했는지 그리고 지금 상태가 어떤지 명확하게 기술하는것이 좋습니다. 또한 질문을 장황하게 하면 그 만큼 응답이 느려질 수 있습니다.

문제를 해결하기위해 어떤걸 시도해 봤는지를 표현하는 것은 맥락을 제공할 뿐만 아니라 다른 사람이 자신에 대한 사고의 과정과 어떤 잘못된 길로 들어섰는지 이해하는데 도움을 줄 수 있습니다.

• 어떻게 질문할지 생각해 보세요. 너무 지루하거나 모호한 질문은 피하는 것이 좋습니다. 발생한 문제와 관련된 Screenshot이나 code조각을 첨부하면 훨씬 도움이 됩니다.

종종 문제가 발생하면 이를 camera로 찍어 올리는 경우가 있습니다. 이는 읽기도 어려울 뿐더러 실제 글을 올린이가 보여주려는 것을 나타내기도 어렵습니다. 이렇게 하기 보다는 code나 발생한 error message를 복사해 붙여넣는 것이 좋습니다. 아니면 흔들리는 angle의 사진보다는 차라리 훨씬 높은 해상도의 screenshot을 사용하세요.

• code를 적절히 형식화 하세요. 대부분의 forum에서는 Markdown 구문강조를 통해 code의 형식화를 지원하고 있습니다. code를 형식화 하면 훨씬 읽기가 편해집니다. 예를 들어 'public void'처럼 backtick을 사용해 keyword를 강조하거나 다음과 같이 code block을 표시할 수 있습니다.

```cs
Console.WriteLine("The C#");

 

위와 같이 Markdown에서 code block을 시작하는 3개의 backtick 다음에 cs, csharp과 같이 간략한 언어이름을 지정하세요.

 

• 예의를 갖추고 인내심을 가지세요. 질문을 올리면 사람들은 그들의 시간을 자진해서 소모하면서 질문에 대한 답변을 올리고 있음을 기억해야 합니다. 예의를 갖춘 글과 응답을 기다리는 동안의 인내심은 큰 도움이 될것입니다. 경우에 따라서 forum의 참여자는 다른 생활영역에 속해있을 수 있으므로 다음날이 되기 전까지 답변이 올라오지 않을 수 있습니다.

forum활동에 활발히 참여하세요. 질문을 올리고 나면 답변을 듣고 끝내는 것이 아니라 forum과의 관계를 계속 유지하는 것이 좋습니다. 어쩌면 비슷한 문제에 처한 다른 사람들에 의해 후속적인 질문을 받는 경우도 있습니다. 이에 대해 가급적 빠른 시간안에 그리고 명확하게 응답하는 것은 도음을 받을 수 있는 기회를 늘리는 기회가 될 수 있습니다.

이러한 내용을 감안하여 질문을 올리고 다른 사람의 응답에 사용한 시간과 노력에 예의를 표하게 되면 유용한 응답을 얻을 가능성을 높일 뿐만 아니라 forum에 긍정적인 영향력을 주게 될것입니다.

 

8) .NET Source에서 찾아보기

때로는 Microsoft Team이 어떤방식으로 .NET을 구현했는지 살펴보는 것만으로도 많은것을 배울 수 있습니다. .NET의 전체 source code는 공개 GitHub repository에서 찾아볼 수 있는데, 예를 들어 email 주소의 유효성검증을 위한 속성에 대해 알아보고자 한다면 다음과 같은 절차를 통해 repository에서 email을 검색하고 어떻게 동작하는지 확인해 볼 수 있습니다.

• web browser를 통해 https://github.com/search 로 접속합니다. (계정이 없다면 만들고 login을 해야 합니다.)
• advanced search를 click합니다.
• advanced search에서 'email'을 입력합니다.
• In these repositories에서 dotnet/runtime을 입력합니다.(이 밖에 dotnet/core, dotnet/aspnetcore등 다른 dotnet검색을 사용할 수도 있습니다.)
• Written in this language에서 C#을 선택합니다.
• advanced search에는 지금까지 설정한 내용을 토대로 어떻게 질의가 이루어지는지 확인할 수 있습니다. Search를 click하고 오른쪽 Code를 click해 filter를 수행해 보면 mailAddressAttribute를 포함한 결과를 아래와 같이 확인하실 수 있습니다.

• source file을 click하고 source내용을 확인해 보면 string값이 '@'문자를 포함하지만 첫번째와 마지막문자는 해당되지 않는 code를 확인하면 어떻게 email에 대한 유효성검증부분을 구현했는지 알 수 있습니다.

// only return true if there is only 1 '@' character
// and it is neither the first nor the last character
int index = valueAsString.IndexOf('@');

return
    index > 0 &&
    index != valueAsString.Length - 1 &&
    index == valueAsString.LastIndexOf('@');

email이 아닌 다른 내용을 검색해 보려면 검색된 link에서 email부분만 다른 용어로 교체하기만 하면 빠르게 다른 검색을 수행할 수 있습니다.

 

9) API 문서를 통해 Source code찾아보기

.NET API 문서를 찾아보는 경우에도 git으로 연결된 source code를 볼 수 있습니다. 일부 API에서는 아래와 같이 해당 source code로의 link를 포함하고 있으며

해당 link를 click하면 github.com에 속하는 source code를 바로 확인해 볼 수 있습니다.

이에 관한 좀더 자세한 사항은 아래 link를 참고 바랍니다.
https://devblogs.microsoft.com/dotnet/dotnet-docs-link-to-source-code/

Introducing links to source code for .NET API Docs - .NET Blog

 

10) 공식 .NET blog와 Standup, news

공식 .NET blog는 .NET 기술팀에 의해 운영되는 blog로, .NET에 관한 최신의 정보를 확인할 수 있습니다.
https://devblogs.microsoft.com/dotnet/

.NET Blog

 

또한 새로운 기능에 대한 미리보기를 .NET team이 안내하고 있는데 이를 보려면 아래 link를 통해 매달 standup을 시청할 수 있습니다.
https://dotnet.microsoft.com/en-us/live/community-standup

.NET Community Standups | .NET Live TV

 

최신의 .NET소식은 아래 link를 통해 확인할 수 있습니다.
https://github.com/dotnet/core/discussions/categories/news

11) ChatGPT나 GitHub Copilot등의 AI 도구 사용하기

dotnet core News · Discussions

 

지난 몇년간 software 개발과정에서 가장 큰 변화중의 하나는 생성형 AI(Artificial intelligence)의 등장일 것입니다. 이러한 AI는 coding작업시 완벽한 code조각이나 전체 함수를 구현하고 단위 test를 작성하며 현재 code에 대한 문제점과 해결책을 제시해 주는등 현실적으로 많은 도움을 제공할 수 있습니다.

2023년 Stack Overflow의 AI 도구에 관한 개발자 설문에서 44%정도가 개발과정동안 AI 도구를 사용했으며 다른 26%정도의 개발자 역시 AI를 사용할 것이라고 답했습니다.
https://stackoverflow.blog/2023/06/14/hype-or-not-developers-have-something-to-say-about-ai/

Hype or not? AI’s benefits for developers explored in the 2023 Developer Survey - Stack Overflow

 

기술연구에서 부터 debugging이나 문서화까지 개발자는 일부 작업에서 소모되는 시간을 절약하기 위해 생성형 AI를 사용합니다. 이중에서 가장 큰 비중을 차지하는 것은 code를 작성하는 것인데, 이는 최근 Stack Overflow 개발자 설문을 통해  많은 개발자가 응답한 생성형 AI를 사용하는 방식이기도 합니다.

ChatGPT는 최근 개인을 위한 몇가지 model을 가지고 있는데 40mini(무료), 40(무료지만 제한적인) 그리고 5배 더 많은 요청과 새로운 기능 및 DALE-E image 생성(월 $20)에 대한 사전 접근과 같은 혜택을 포함한 40입니다. 기업을 위한 결제조건이 따로 존재하므로 아래 link를 통해 가격조건을 따져볼 수 있습니다.
https://openai.com/chatgpt/pricing/

 

12) GitHub Copilot

Microsoft는 개발자를 위해 GitHub Copilot이라는 AI Service를 제공하고 있으며 이를 통해 code editor에서 자동적으로 code가 완성되는 기능을 사용할 수 있습니다. 해당 service는 Visual Studio에서는 물론 VS Code, JetBrains IntelliJ기반 IDE에서 사용할 수 있습니다.

AI를 사용할때 궁극적인 책임은 본인에게 있으므로 너무 전체적인 부분을 의지하는것에 대해서는 주의가 필요합니다. 너무 지루하거나 단순한 부분에 대해서는 이를 copilot에게 넘겨줄 수 있지만 이때도 필요한 경우 이를 되돌릴 준비를 준비를 해야 합니다.

GitHub Copilot은 본래 학생, 교육자 및 일부 open-source 개발자에 한해서만 무료로 제공했으며 개인인 경우 30일한정 free-trial로 사용하거나 월$10 또는 연$100의 가격으로 사용 할 수 있었습니다. 그러나 최근 월 2000회정도의 code를 제공하는 free version을 제공하기 시작했으므로 copilot을 경험해 보기위한 것으로는 충분할 것입니다.

JetBrain은 GitHub Copilot과 유사한 AI Assistant Service를 제공하고 있습니다. 자세한 사항은 아래 link를 참고바랍니다.
https://blog.jetbrains.com/idea/2023/06/ai-assistant-in-jetbrains-ides/

 

상술했듯이 GitHub Copilot은 code editor상에서 실질적인 coding역활을 수행할 수 있습니다. 예를 들어 Project에 Users.cs이름의 class file을 추가한 경우 class file안에서 Enter key를 눌러 빈 행을 삽입한 후 잠깐동안 기다리면 아래 그림과 같이 GitHub Copilot은 회색으로 일부 sample code를 자동으로 생성해 줍니다.

이때 code를 살펴보고 원래 필요했던 code에 근접한다면 tab을 눌러 전체 source를 그래도 넣을 수 있고 아니면 Alt + .(점) key를 눌러 다른 code를 제안받을 수 있습니다. 물론 원하는 code가 아니라면 자신이 직접 code를 작성해도 되지만, 보통은 이러한 제안을 통해서 사용할 수 있거나 사용해야 하는 구문을 상기시켜 주는 무엇인가 있을 수 있고 이를 통해 작성해야 하는 수십line의 지루한 code입력을 간편하게 처리할 수 있습니다.(Microsoft는 이러한 code를 GitHub Repository를 통해 AI 도구로 제공하고 있고, 이는 여기에 기여한 모든 개발자의 code가 제안될 수 있음을 의미하는 것입니다.)

GitHub Copilot의 계정은 아래 link에서 등록할 수 있습니다.
https://github.com/login?return_to=https%3A%2F%2Fgithub.com%2Fgithub-copilot%2Fsignup

GitHub Copilot을 통해 기술적 결정을 해야하는 초보자 Guide는 아래 link에서 확인할 수 있습니다.
https://dev.to/github/a-beginners-guide-to-prompt-engineering-with-github-copilot-3ibp

 

13) 오히려 방해될때 사용하지 않기

 

비록 위에서 언급한 도구가 유용하긴 하지만 이런것들이 오히려 방해가 되는 경우도 있습니다. 특히 학습을 하는 경우 스스로 해보지 않으면 온전히 배울 수 없기 때문에 이러한 기능을 꺼두는 것도 필요합니다.

Visual Studio에서 IntelliSense설정하려면 Tools -> Options를 click하고 Options Dialog Box의 tree view에서 Text Editor -> C# -> IntelliSense항목을 찾아 선택합니다. 참고로 화면상단 오른쪽의 '?' 표시 button을 click하면 관련 도움말을 찾아볼 수 있습니다. GitHub Copilot은 Options Dialog Box에서 GitHub -> Copilot을 선택한 후 Enable Globally를 설정함으로서 사용유무를 선택할 수 있습니다.

VS code에서 GitHub Copilot은 상태 bar오른쪽에 있는 알림 icon에서 GitHub Copilot icon을 선택하고 여기서 나오는 popup을 통해 Disable Globally나 Enable Globally를 선택하여 설정할 수 있습니다.