.NET 프로젝트를 부트스트랩하고 생성하는 방법

게시 됨: 2022-03-11

.NET 프로젝트 만들기

.NET 프로젝트를 처음부터 만드는 것은 Visual Studio 마법사를 사용하는 것만큼 간단합니다. File => New Project 로 이동하거나 기존 솔루션에 Add New Project . 새 프로젝트가 생성되면 바로 코딩을 시작할 수 있습니다. 그러나 마법사가 생성한 기본 프로젝트 설정은 품질에 대한 기준을 너무 낮게 설정하기 때문에 전문 팀에서는 거의 수용할 수 없습니다. 또한 특정 개발 환경에서 수행해야 하는 다른 설정 단계에 대해 알 수 있는 마법사는 없습니다.

이 기사에서는 미래의 기술 부채를 최소화하는 데 중요한 새 프로젝트를 생성하는 즉시 활성화해야 하는 몇 가지 중요한 설정을 안내합니다. 또한 많은 .NET 개발자가 솔루션과 새 프로젝트를 구성할 때 적용하는 몇 가지 일반적인 관행을 검토할 것입니다. 이러한 아이디어 중 일부를 적용하지 않더라도 대부분의 팀이 하는 일을 배우고 개요를 얻는 것이 좋습니다.

구조

복잡한 프로젝트에서는 잘 정의된 구조를 갖는 것이 중요합니다. 이렇게 하면 신규 사용자가 팀에 합류할 때 온보딩 경험이 향상되고 이전 프로젝트를 지원할 때 생활이 더 쉬워집니다. 좋은 구조의 두 가지 주요 지표는 다음과 같습니다.

  • 솔루션 및 프로젝트 폴더 사용
  • 일관된 이름 지정

폴더

가상 폴더 라고도 하는 솔루션 폴더는 프로젝트를 그룹화하는 데 매우 편리한 도구입니다. 솔루션 탐색기 보기에서 마우스 오른쪽 버튼을 클릭하고 Add => New Solution Folder 를 선택한 다음 기존 프로젝트를 이 새 폴더로 끌어다 놓기만 하면 됩니다. 이러한 폴더는 파일 시스템에서 미러링되지 않으므로 물리적 구조를 변경하지 않고 유지할 수 있으므로 한 솔루션 폴더에서 다른 솔루션 폴더로 프로젝트를 이동해도 물리적으로 이동하지 않습니다.

"1 - Common", "2 - Data", "3 - Server" 및 "4 - Client" 폴더가 있는 프로젝트 구조를 보여주는 솔루션 탐색기 창.

번호가 매겨진 접두사를 가질 필요는 없지만 폴더가 솔루션 탐색기 창에서 바로 정렬된 것처럼 보이게 합니다.

Visual Studio는 분할된 단일 솔루션 또는 다중 솔루션 모델을 활용하여 동시에 여러 솔루션을 사용할 수 있습니다. 그것들은 거의 사용되지 않으므로 이 기사에서는 다루지 않을 것입니다.

솔루션 폴더 와 달리 프로젝트 폴더 는 물리적 폴더 구조와 일치하므로 디스크에서 실제 폴더로 유지됩니다. 또한 C# 코드가 포함된 프로젝트 폴더는 프로젝트의 네임스페이스 와 일치해야 합니다. 이것은 탐색을 매우 자연스럽게 만듭니다. 이러한 불일치에 대해 경고하도록 ReSharper 규칙을 활성화할 수도 있습니다.

네이밍

명명과 관련하여 적용할 권장 규칙은 거의 없습니다.

  • CamelCase를 사용하세요.
  • 프로젝트 이름은 출력 어셈블리 이름과 일치해야 합니다.
  • 자동화된 테스트를 포함하는 프로젝트에는 .Tests 접미사가 있어야 합니다.
  • 모든 프로젝트 이름에는 Company.Product 와 같은 공통 접두사가 있어야 합니다.

이전과 동일한 프로젝트이지만 MyCompany.MyProduct.Windows.Controls.Tests를 포함하는 "4.1 - Tests"라는 새 폴더가 있습니다.

합리적인 규칙도 거의 없습니다. 상식(및 영어 문법은 물론)에 따라 언제 적용할지 스스로 결정해야 합니다.

  • 컨테이너(프로젝트 또는 폴더)에 같은 종류의 여러 인스턴스(예: Tests 또는 System.Collections )가 포함된 경우 복수 형태로 주제를 사용합니다.
  • 전체 컨테이너에 단일 엔터티(예: System.Collections.ObjectModel`)에 대한 코드가 모두 포함된 경우 단수 형식을 사용합니다.
  • 짧은 약어의 경우 System.IO 와 같이 대문자를 사용합니다.
  • 긴 약어의 경우 Modules.Forex. .

경험 법칙: 짧은 약어는 세 글자를 넘지 않아야 합니다.

솔루션 구성

솔루션 구성은 환경에 필요한 모든 인프라 파일을 제공하는 것만큼 간단합니다. 그 중 일부는 나중에 추가할 수 있지만(예: CI 통합 파일), 초기에 갖는 것이 더 나은 파일은 거의 없습니다.

ReSharper 설정

전문 .NET 개발자라면 ReSharper를 사용할 가능성이 매우 높습니다. ReSharper는 설정 관리에 있어 매우 유연합니다. 팀 리더는 다른 개발자가 사용할 팀 공유 설정을 만들고 배포할 수 있습니다. 팀 공유 설정은 확장자가 .DotSettings 인 파일에 저장됩니다. 파일 이름이 Visual Studio 솔루션 이름과 일치하는 경우 ReSharper는 다음 설정을 자동으로 선택합니다.

 MyCompany.MyProduct.sln MyCompany.MyProduct.sln.DotSettings

따라서 궁극적으로 전체 팀에 일부 설정을 적용하려면 맨 처음에 이 파일을 만들어야 합니다. 좋은 예는 var 키워드를 사용하거나 사용하지 않는 규칙입니다. 팀 공유 설정 파일에는 이 하나의 규칙만 있을 수 있지만 나머지는 개발자의 기본 설정입니다. 수정할 수 없는 일부 레거시 코드(예: var 키워드를 사용하도록 변경)가 있을 수 있으므로 ReSharper 설정을 프로젝트 수준에서 동일한 방식으로 설정할 수 있다는 점을 언급할 가치가 있습니다.

예제와 같이 이 파일의 이름을 올바르게 지정한 경우 새로운 ReSharper 설정이 포함된 Visual Studio의 모든 새 인스턴스는 이 파일을 자동으로 선택하고 규칙을 적용합니다. 이 파일을 소스 제어에 커밋하는 것을 잊지 마십시오.

StyleCop 규칙

ReSharper 설정과 마찬가지로 StyleCop 설정을 공유할 수 있습니다. ReSharper를 사용하는 경우 아마도 ReSharper의 StyleCop을 활용할 통합 플러그인이 설치되어 있을 것입니다. 그러나 StyleCop은 설정을 Settings.StyleCop 이라는 파일에 독립적으로 저장합니다. 마찬가지로 솔루션 파일 및 프로젝트 파일과 함께 이 파일을 가질 수 있습니다.

StyleCop을 사용하는 경우 StyleCop 구성 도구를 실행하고 수행하지 않을 검사를 비활성화하는 것을 잊지 마십시오. 기본적으로 모든 검사가 활성화되어 있습니다. 이 파일에 새 설정을 저장하고 소스 제어에 커밋합니다.

텍스트 파일

공개 제품을 빌드하고 소스 코드를 게시하려는 경우 다음 파일도 생성하고 커밋하는 것을 잊지 마십시오.

 README.md LICENSE

README.md 파일은 마크다운 형식을 사용하는 것이 좋습니다. 이는 산업 표준이 되었고 GitHub와 같은 공개 소스 제어 서비스와 BitBucket(이전 Stash)과 같은 사내 서버에서 지원되기 때문입니다.

NuGet 사양

NuGet 갤러리에 배포할 라이브러리를 빌드하는 경우 MyProject.nuspec 과 같은 패키지 사양 파일을 만들어야 할 가능성이 큽니다. 이러한 파일을 수동으로 만들고 소스 제어에 커밋하는 것을 선호합니다. 패키지는 일반적으로 지속적 통합(줄여서 CI) 작업 중 하나에서 릴리스되지만 언제든지 다음과 같이 콘솔에서 수동으로 패키지를 빌드하고 게시할 수 있습니다.

 nuget.exe pack MyLibrary.nuspec

이 명령을 실행하기 전에 패키지 버전을 높이는 것을 잊지 마십시오.

CI 특정 파일

우리는 모두 서로 다른 CI 서버를 사용하며 모두 다른 구성 스크립트와 설정을 가지고 있습니다. 추가를 고려할 수 있는 몇 가지 일반적인 추가 사항을 언급하겠습니다.

  • 특정 작업에 대해 CI 서버에서 실행할 테스트가 포함된 어셈블리를 지정하는 NUnit 설정. 모든 테스트는 실제로 몇 가지 범주로 나뉩니다. 모든 빌드에서 실행해야 하는 단위 테스트 , 야간에 실행되는 성능 테스트 , 릴리스별로 실행되는 통합 테스트가 있습니다.
  • 테스트 적용 범위를 위해 분석해야 하는 테스트 어셈블리를 지정하는 NCover 설정.
  • 소프트웨어 메트릭을 결정하는 SonarQube 설정이 수집됩니다.
  • NAnt, PowerShell 또는 단순히 Windows 배치 파일과 같은 작업 스크립트 .
적절하게 부트스트랩된 프로젝트는 미래의 기술 부채를 줄이고 제품 소스 코드를 읽기 쉽고 전문적으로 보이게 만듭니다.
트위터

프로젝트 구성

프로젝트 파일, 즉 .csproj 또는 .vbpro 에는 Visual Studio 및 MSBuild에서 사용하는 모든 설정이 포함되어 있습니다. 그러나 프로젝트 속성 창에서 모두 사용할 수 있는 것은 아닙니다. Visual Studio에서 이러한 파일을 수동으로 편집하려면 다음을 수행해야 합니다.

  • 솔루션 탐색기 보기에서 프로젝트를 마우스 오른쪽 버튼으로 클릭합니다.
  • 프로젝트 언로드를 선택합니다.
  • 다시 마우스 오른쪽 버튼을 클릭하여 xyz.csproj 편집 작업을 선택합니다.
  • 편집을 완료합니다.
  • 프로젝트를 다시 마우스 오른쪽 버튼으로 클릭하고 프로젝트 다시 로드 를 선택합니다.

또는 즐겨 사용하는 텍스트 편집기에서 프로젝트 파일을 열고 편집하고 저장할 수 있습니다. Visual Studio 창으로 다시 전환하면 변경된 프로젝트를 다시 로드하라는 메시지가 표시됩니다.

경고 제어

고품질 소프트웨어를 빌드하려면 빌드 경고를 무시해서는 안 됩니다. 따라서 최대 경고 수준을 활성화하고 모든 경고를 오류로 처리해야 합니다. 디버그 및 릴리스와 같은 모든 빌드 구성에 대해 이 작업을 수행해야 합니다. 이를 수행하는 가장 좋은 방법은 공통 속성 그룹에 다음 설정을 작성하는 것입니다.

 <WarningLevel>4</WarningLevel> <TreatWarningsAsErrors>true</TreatWarningsAsErrors>

그리고 다른 속성 그룹에 동일한 설정이 없는지 확인하십시오. 그렇지 않으면 공통 그룹의 해당 속성을 재정의합니다.

에프엑스캅

FxCop을 실행하는 것은 모든 빌드에서 실행하는 것이 실용적입니다. 대부분의 팀은 심각한 오류가 발생하지 않았는지 확인하기 위해 때때로(일반적으로 릴리스 전에) FxCop을 실행하는 것을 선호합니다. 그러나 모든 빌드에 대해 궁극적인 검사를 수행하려면 다음 옵션을 추가하세요.

 <RunCodeAnalysis>true</RunCodeAnalysis>

StyleCop과 같은 FxCop에는 루트 폴더에 배치하고 소스 제어에 추가할 수 있는 자체 설정이 있습니다. 이러한 설정은 CI 서버에서 FxCop을 실행할 때 사용됩니다.

선적 서류 비치

이 부분은 XmlDoc에 관한 것입니다. 공개 API를 구축하는 경우 API 문서를 만들고 유지 관리해야 합니다. 대부분의 개발자는 API 개발(실제 코딩)으로 시작하고 릴리스 직전에 Build / XML documentation file 프로젝트 설정을 활성화합니다. 당연히 모든 누락된 XmlDoc으로 인해 빌드 오류가 발생하기 때문에 다른 다시 빌드 후에 많은 오류가 나타납니다. 이를 방지하려면 맨 처음에 언급된 옵션을 활성화해야 합니다.

적절한 문서를 작성하기에 너무 게으르거나 너무 많은 텍스트를 입력하는 것을 좋아하지 않는다면 GhostDoc과 같이 이 프로세스를 자동화하는 도구를 사용해 보십시오.

코드 계약

코드 계약은 런타임 검사, 정적 분석 및 문서화를 위해 코드에서 사전 조건, 사후 조건 및 개체 불변성을 표현할 수 있는 Microsoft Research의 우수한 프레임워크입니다. 나는 이것을 많은 중요한 프로젝트에서 사용했고 많은 도움이 되었기 때문에 시도해 보시기 바랍니다.

코드 계약을 사용하기로 결정한 경우 새 프로젝트를 생성한 맨 처음에 계약을 활성화하는 것이 중요합니다. 개발 도중에 Contract를 추가하는 것도 가능하지만 Contact가 서로 일치하도록 하려면 많은 클래스를 통해 변경해야 합니다. 따라서 모든 필수 설정(적어도 CodeContractsEnableRuntimeChecking )을 활성화하고 이러한 설정이 공통 속성 그룹에 나타나는지 확인하는 것을 잊지 마십시오.

StyleCop 집행

이전에 개발 시간을 위한 StyleCop 구성에 대해 이야기했습니다. 그러나 프로젝트가 CI 서버에서 빌드되면 ReSharper가 거기에 영향을 미치지 않으므로 StyleCop 유효성 검사를 MSBuild와 함께 실행하도록 설정해야 합니다.

이것은 일반적으로 프로젝트 파일을 수동으로 수정하여 수행됩니다. Visual Studio에서 프로젝트를 언로드하고 프로젝트 파일을 편집한 다음 프로젝트를 다시 로드해야 합니다.

 <PropertyGroup> <!— add this to the common property group (common to Debug/Release/etc) —> <StyleCopTreatErrorsAsWarnings>false</StyleCopTreatErrorsAsWarnings> </PropertyGroup> <!— add this Import in the very bottom —> <Import Project="$(ProgramFiles)\MSBuild\Microsoft\StyleCop\v4.3\Microsoft.StyleCop.targets">

StyleCopTreatErrorsAsWarnings 를 설정하면 StyleCop 규칙 위반 시 빌드가 중단됩니다. MSBuild가 StyleCop 작업을 빌드 체인에 추가하려면 가져오기 요소가 필요합니다.

Program Files 의 경로를 눈치채셨을 것입니다. 개발자가 다른 StyleCop 버전을 설치했을 수 있기 때문에 일부 팀은 소스 제어 하에 동일한 StyleCop 설치의 개인 복사본을 유지하는 것을 선호합니다. 이 경우 경로는 상대적입니다. 또한 StyleCop을 로컬에 설치할 필요가 없기 때문에 CI 시스템을 더 쉽게 설정할 수 있습니다.

어셈블리 정보

Visual Studio 마법사로 생성된 모든 .NET 프로젝트에는 일부 Assembly 특성이 포함된 AssemblyInfo.cs 파일이 자동으로 채워집니다( 등록 정보 하위 폴더 참조). 그러나 어떤 마법사도 모든 Assembly 특성을 채울 수 없습니다. 최소한 다음 속성이 채워져 있는지 확인하십시오.

  • AssemblyTitle
  • AssemblyDescription
  • AssemblyCompany
  • AssemblyProduct
  • AssemblyCopyright
  • AssemblyVersion

모두 대괄호로 묶인 6개의 줄을 보여주는 Visual Studio의 스크린샷. 각 줄은 "어셈블리: "로 시작합니다. 각 줄에는 위에 나열된 속성 중 하나와 괄호와 따옴표로 묶인 해당 예제 텍스트 문자열이 있습니다. 예를 들어, 마지막은 "1.0.0.0"입니다.

배포하려는 모든 어셈블리에 이 최소값이 필요합니다. 이에 대한 실질적인 이유는 NuGet입니다. 선택한 어셈블리 파일에서 자동 NuGet 사양 생성을 사용하는 경우 이 도구는 이러한 속성에서 필요한 정보를 파생합니다.

맨 처음에 속성을 하나 더 채울 수도 있습니다.

 InternalsVisibleTo

이 속성은 내부 클래스와 인터페이스를 지정된 어셈블리에 표시합니다. 이것은 일반적으로 프로젝트에 대해 생성할 자동화된 테스트에 사용됩니다.

연결 문자열

연결 문자열을 관리하는 방법은 스택 오버플로에서 매우 인기 있는 질문입니다. 문제는 모든 개발자 또는 CI 작업에 대해 연결 문자열을 고유하게 만들고 소스 코드를 게시하는 동안 연결 세부 정보를 노출하지 않는 방법입니다.

App.config (데스크톱 응용 프로그램의 경우) 또는 Web.config (웹 응용 프로그램의 경우)에서 런타임에 user.config 파일을 로드할 다음 설정을 지정합니다. 이것을 소스 제어 하에 유지하십시오.

 <?xml version="1.0" encoding="utf-8" ?> <configuration> <connectionStrings configSource="user.config"></connectionStrings> </configuration>

분명히 user.config 파일은 소스 제어에서 제외되어야 하며 모든 개발자는 연결 문자열 개인 정보를 보호하기 위해 이 파일의 로컬 복사본을 가지고 있어야 합니다.

 <connectionStrings> <add name="test" connectionString="Server=.;Database=...;"/> </connectionStrings>

.gitignore

Git을 소스 제어로 사용하는 사람들에게는 .gitignore 파일에 일부 파일 패턴을 추가하는 것이 중요합니다. 그러나 우리의 스마트 커뮤니티는 이미 일반화된 파일을 구축했으며 여기에서 찾을 수 있습니다. github.com/github/gitignore/blob/master/VisualStudio.gitignore.

참조 .gitignore 파일로 가져와 추가로 필요할 수 있는 사용자 지정 제외를 추가하기만 하면 됩니다.

GitHub 배지

README 프로젝트 페이지에 멋진 배지가 표시되는 것을 본 적이 있을 것입니다. GitHub에 프로젝트를 게시하는 경우 다음을 위해 프로젝트를 공개 서비스에 연결하는 것을 고려하십시오.

  • 건물: 빌드가 실패하거나 통과하고 있음을 표시합니다.
  • 테스트: 테스트 커버리지와 테스트 실행 상태를 보여줍니다.
  • 게시: 최신 NuGet 패키지 버전을 표시합니다.

뱃지 및 관련 서비스의 전체 목록은 shields.io에서 찾을 수 있습니다. 오픈 소스 프로젝트에 적합한 흥미로운 배지를 많이 찾을 수 있습니다.

선택한 서비스에 프로젝트를 등록하면 이미지에 대한 링크와 README.md 파일에 추가할 수 있는 완전한 마크다운 구문 링크가 제공됩니다. 그건 그렇고, 이것이 Readme 파일에 대해 마크다운을 선호해야 하는 이유 중 하나입니다.

Roslyn 프로젝트의 샘플 마크다운 배지:

[![Build Status]([http://dotnet-ci.cloudapp.net/job/roslyn_master_win_dbg_unit32/badge/icon)](http://dotnet-ci.cloudapp.net/job/roslyn_master_win_dbg_unit32/)](http://dotnet-ci.cloudapp.net/job/roslyn_master_win_dbg_unit32/badge/icon)](http://dotnet-ci.cloudapp.net/job/roslyn_master_win_dbg_unit32/)) [![Join the chat at [https://gitter.im/dotnet/roslyn](https://badges.gitter.im/Join%20Chat.svg)](https://gitter.im/dotnet/roslyn?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge)](https://gitter.im/dotnet/roslyn](https://badges.gitter.im/Join%20Chat.svg)](https://gitter.im/dotnet/roslyn?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge))

Linux/Mac - 모든 셀에 "빌드 통과" 배지를 표시하는 단위 테스트 테이블. 행은 안정화, 마스터, 미래 안정화, 미래 및 핫픽스입니다. 열은 Linux 및 Mac OSX입니다. 테이블 뒤 왼쪽 하단 모서리에 "gitter 조인 채팅" 배지도 있습니다.

자동 솔루션 구조 검증

이 기사에서 논의한 모든 설정을 지정했더라도 조만간 개발자 중 한 명이 이를 변경하고 변경 사항을 소스 제어에 커밋할 수 있습니다. 때때로 이것은 실수로 발생하며 종종 이러한 변경 사항이 코드 검토 중에 포착되지 않습니다. 이러한 사고 외에 다음과 같은 일반적인 오류에 주의해야 합니다.

  • 잘못된 참조 : 누군가가 다른 사람들에게 없을 수도 있는 로컬 어셈블리를 참조하거나 누군가가 디스크에서 파일을 삭제했지만 해당 파일에 대한 링크는 .csproj 파일에 남아 있는 경우입니다. 이렇게 하면 빌드가 확실히 중단되지만 변경 사항이 푸시되고 다른 사용자가 변경하면 너무 늦게 발생할 수 있습니다. 이것은 빌드 중에 확인할 수 없는 정적 웹 파일에 특히 중요합니다.
  • 명명 일관성 : StyleCop과 같은 도구는 C# 소스 코드를 제어할 수 있지만 어떤 도구도 프로젝트 파일 또는 어셈블리 속성에 대한 규칙을 적용할 수 없습니다. 좋은 예는 다음과 같습니다. 출력 어셈블리 이름과 일치하도록 프로젝트 이름을 지정하고 MyCompany.MyProduct 와 같은 공통 접두사를 프로젝트 이름에 지정하려고 합니다.

코드 리뷰에서 이러한 오류를 관찰하는 것은 오류가 발생하기 쉽고 자동화되어야 한다는 것을 발견했습니다. 그래서 솔루션 일관성을 확인하기 위해 이러한 검사와 기타 여러 검사를 수행하는 간단한 도구를 작성했습니다. SolutionInspector를 만나보세요. 이것은 오픈 소스이며 MIT 라이선스에 따라 배포됩니다. 소스 코드에서 빌드하거나 NuGet에서 설치할 수 있습니다.

 Install-Package SolutionInspector

이 도구는 전체 솔루션 구조를 살펴보고 많은 유효성 검사 규칙을 적용합니다. 규칙은 다른 솔루션 파일과 함께 배치되는 XML 파일로 구성됩니다. 프로젝트별로 설정을 제어하려면 해당 프로젝트 폴더에 설정이 다른 동일한 파일을 추가하기만 하면 됩니다.

기본적으로 구성 파일이 필요하지 않습니다. 이 경우 도구는 사용 가능한 모든 규칙을 적용하고 모든 문제를 콘솔에 제공합니다.

다음은 구성 파일의 예입니다.

 <?xml version="1.0" encoding="utf-8"?> <Settings xmlns:xsi="[http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">](http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">) <SolutionSettings> <MinSolutionFormatVersion>12.00</MinSolutionFormatVersion> <MaxSolutionFormatVersion>12.00</MaxSolutionFormatVersion> <DetectMissingFiles>true</DetectMissingFiles> <ProjectNamePrefix>MyCompany.MyProduct.</ProjectNamePrefix> <ProjectNameIsFileName>true</ProjectNameIsFileName> <IgnoredProjects> AVerySpecialProject1; AVerySpecialProject2; </IgnoredProjects> </SolutionSettings> <ProjectSettings> <DetectMissingFiles>true</DetectMissingFiles> <AllowBuildEvents>true</AllowBuildEvents> <AssemblyNameIsProjectName>true</AssemblyNameIsProjectName> <RootNamespaceIsAssemblyName>true</RootNamespaceIsAssemblyName> <RequiredImports>StyleCop.MSBuild.Targets</RequiredImports> <Properties> <TreatWarningsAsErrors>true</TreatWarningsAsErrors> <StyleCopTreatErrorsAsWarnings>false</StyleCopTreatErrorsAsWarnings> </Properties> </ProjectSettings> </Settings>

설정이 다소 설명적이지만 그 중 일부를 설명하겠습니다.

  • MinSolutionFormatVersion / MaxSolutionFormatVersion 은 개발자가 Visual Studio 버전을 전환하는 것을 방지합니다.
  • DetectMissingFiles 는 솔루션이나 프로젝트에 추가된 정적 웹 콘텐츠 또는 기타 비코드 파일에 매우 유용합니다.
  • AllowBuildEvents 는 불필요한 작업을 수행할 수 있는 사용자 지정 빌드 이벤트를 추가하는 것을 방지할 수 있습니다.
  • Properties 은 가장 유연한 요소입니다. 알려진 속성이든 사용자 정의이든 원하는 값에 대해 속성을 확인할 수 있습니다.

결론

새 프로젝트를 시작할 때 적용할 수 있는 몇 가지 표준 사례, 구성 파일 및 프로젝트 설정을 검토했습니다. 처음부터 이렇게 하면 미래의 기술 부채가 줄어들고 제품 소스 코드가 멋지고 전문적으로 보일 것입니다. 오픈 소스 프로젝트의 경우 이는 기여자가 솔루션 구성 및 프로젝트 파일을 검사하여 귀하의 기대치를 알 수 있기 때문에 특히 중요합니다.

관련 항목: .NET Core - 야생 및 오픈 소스 진행. 마이크로소프트, 왜 이렇게 오래 걸렸어?!