.NETプロジェクトをブートストラップして作成する方法

公開: 2022-03-11

.NETプロジェクトを作成する

.NETプロジェクトを最初から作成するのは、VisualStudioウィザードを使用するのと同じくらい簡単です。 File => New Projectに移動するか、既存のソリューションに[新しいプロジェクトをAdd New Project移動します。 新しいプロジェクトが作成されたら、すぐにコーディングを開始できます。 ただし、ウィザードによって作成されたデフォルトのプロジェクト設定は、品質の基準が低すぎるため、プロのチームにはほとんど受け入れられません。 さらに、特定の開発環境で実行する必要のある他のセットアップ手順をウィザードが知ることはできません。

この記事では、新しいプロジェクトを作成したらすぐに有効にする必要があるいくつかの重要な設定について説明します。これは、将来の技術的負債を最小限に抑えるために重要です。 また、多くの.NET開発者がソリューションや新しいプロジェクトを構築するときに適用するいくつかの一般的な方法を確認します。 これらのアイデアの一部を適用していない場合でも、ほとんどのチームが行っていることの概要を学び、理解することは素晴らしいことです。

構造

複雑なプロジェクトでは、明確に定義された構造を持つことが不可欠です。 これにより、新参者がチームに参加するときのオンボーディングエクスペリエンスが向上し、古いプロジェクトをサポートするときの作業が楽になります。 優れた構造を示す2つの重要な指標があります。

  • ソリューションおよびプロジェクトフォルダーの使用
  • 一貫した命名

フォルダー

ソリューションフォルダは、仮想フォルダと呼ばれることもあり、プロジェクトをグループ化するための非常に便利な手段です。 ソリューションエクスプローラービューで、右クリックして[ Add => New Solution Folder ]を選択し、既存のプロジェクトをこの新しいフォルダーにドラッグアンドドロップします。 これらのフォルダーはファイルシステムにミラーリングされないため、物理構造を変更せずに保持できるため、プロジェクトを1つのソリューションフォルダーから別のソリューションフォルダーに移動しても、物理的に移動することはありません。

「1-共通」、「2-データ」、「3-サーバー」、「4-クライアント」のフォルダーを含むプロジェクト構造を示すソリューションエクスプローラーウィンドウ。

プレフィックスに番号を付ける必要はありませんが、ソリューションエクスプローラーウィンドウにフォルダーが順番に表示されるようになります。

Visual Studioは、パーティション化された単一のソリューションまたはマルチソリューションモデルを活用することにより、同時に複数のソリューションを処理できます。 それらはめったに使用されないので、この記事では取り上げません。

ソリューションフォルダーとは異なり、プロジェクトフォルダーは物理フォルダーの構造と一致するため、ディスク上で実際のフォルダーとして存続します。 さらに、C＃コードを含むプロジェクトフォルダーは、プロジェクトの名前空間と一致する必要があります。 これにより、ナビゲーションが非常に自然になります。 ReSharperルールを有効にして、このような不一致を警告することもできます。

ネーミング

ネーミングに関連して適用する推奨ルールはいくつかあります。

  • キャメルケースを使用します。
  • プロジェクト名は、その出力アセンブリ名と一致する必要があります。
  • 自動テストを含むプロジェクトには、接尾辞.Testsを付ける必要があります。
  • すべてのプロジェクト名には、 Company.Productなどの共通のプレフィックスを付ける必要があります。

以前と同じプロジェクトですが、MyCompany.MyProduct.Windows.Controls.Testsを含む新しいフォルダー「4.1--Tests」があります。

合理的なルールもいくつかあります。 常識（そしてもちろん英文法）に基づいて、いつそれらを適用するかを自分で決める必要があります。

  • コンテナ（プロジェクトまたはフォルダ）に同じ種類の複数のインスタンス（ TestsまたはSystem.Collectionsなど）が含まれている場合は、複数形でサブジェクトを使用します。
  • コンテナ全体に単一のエンティティに関するコードがすべて含まれている場合は、単一の形式を使用します（System.Collections.ObjectModel`など）。
  • 短い略語の場合は、 System.IOのように大文字を使用します。
  • 長い略語の場合は、Modules.ForexのようなModules.Forex. 。

経験則：短い略語は3文字を超えてはなりません。

ソリューションの構成

ソリューションの構成は、環境に必要なすべてのインフラストラクチャファイルを提供するのと同じくらい簡単です。 それらのいくつか（CI統合ファイルなど）は後で追加できますが、最初に用意したほうがよいファイルはほとんどありません。

ReSharper設定

プロの.NET開発者であれば、ReSharperを使用する可能性が非常に高くなります。 ReSharperは、設定の管理に非常に柔軟性があります。 チームリーダーは、他の開発者が使用するチーム共有設定を作成して配布できます。 チーム共有設定は、拡張子が.DotSettingsのファイルに保存されます。 ファイル名がVisualStudioソリューション名と一致する場合、ReSharperはこれらの設定を自動的に選択します。

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

したがって、最終的にチーム全体にいくつかの設定を適用する場合は、最初にこのファイルを作成する必要があります。 良い例は、 varキーワードを使用する（または使用しない）ルールです。 チーム共有設定ファイルには、この1つのルールだけを含めることができますが、他のルールは開発者の好みです。 変更できないレガシーコードがある可能性があるため（ 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）ジョブの1つによってリリースされますが、次のように、いつでもコンソールから手動でパッケージをビルドおよび公開できます。

 nuget.exe pack MyLibrary.nuspec

このコマンドを実行する前に、パッケージのバージョンをインクリメントすることを忘れないでください。

CI固有のファイル

私たちは皆、異なるCIサーバーを使用しており、それらはすべて異なる構成スクリプトと設定を持っています。 追加を検討する可能性のある一般的な追加のいくつかについて説明します。

  • NUnit設定。特定のジョブに対してCIサーバーで実行されるテストを含むアセンブリを指定します。 すべてのテストは、実際にはいくつかのカテゴリに分けられます。 すべてのビルドで実行する必要のある単体テスト、夜間に実行されるパフォーマンステスト、およびリリースごとに実行される統合テストがあります。
  • NCover設定。テストカバレッジについて分析するテストアセンブリを指定します。
  • ソフトウェアメトリクスを決定するSonarQube設定が収集されます。
  • NAnt、PowerShell、または単にWindowsバッチファイルなどのジョブスクリプト。
適切にブートストラップされたプロジェクトは、将来の技術的負債を減らし、製品のソースコードを読みやすくプロフェッショナルなものにします。
つぶやき

プロジェクトの構成

プロジェクトファイル、つまり.csprojまたは.vbproには、VisualStudioおよびMSBuildで使用されるすべての設定が含まれています。 ただし、それらのすべてが[プロジェクトのプロパティ]ウィンドウから利用できるわけではありません。 Visual Studioでこれらのファイルを手動で編集するには、次の手順を実行する必要があります。

  • ソリューションエクスプローラービューでプロジェクトを右クリックします。
  • [プロジェクトのアンロード]を選択します。
  • もう一度右クリックして、アクションEditxyz.csprojを選択します。
  • 完全な編集。
  • プロジェクトをもう一度右クリックし、[プロジェクトの再ロード]を選択します。

または、お気に入りのテキストエディタでプロジェクトファイルを開き、編集して保存することもできます。 Visual Studioウィンドウに戻ると、変更したプロジェクトを再読み込みするように求められます。

警告制御

高品質のソフトウェアを構築するには、構築の警告を決して無視しないでください。 したがって、最大警告レベルを有効にし、警告をエラーとして扱う必要があります。 デバッグやリリースなど、使用しているすべてのビルド構成に対してこれを行う必要があることに注意してください。 これを行う最良の方法は、共通のプロパティグループに次の設定を書き込むことです。

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

また、他のプロパティグループに同じ設定がないことを確認してください。 それ以外の場合は、共通グループの対応するプロパティを上書きします。

FxCop

FxCopの実行は、すべてのビルドで実行するのが実際的です。 ほとんどのチームは、重大なエラーが発生していないことを確認するために、時々（通常はリリース前に）FxCopを実行することを好みます。 ただし、すべてのビルドで最終的なチェックを実行する場合は、次のオプションを追加します。

 <RunCodeAnalysis>true</RunCodeAnalysis>

FxCopには、StyleCopと同様に、ルートフォルダーに配置してソース管理に追加できる独自の設定があることに注意してください。 これらの設定は、CIサーバーでFxCopを実行するときに使用される可能性があります。

ドキュメンテーション

この部分はXmlDocについてです。 パブリックAPIを構築している場合は、APIドキュメントを作成して維持する必要があります。 ほとんどの開発者はAPI開発（実際のコーディング）から始め、リリースの直前にプロジェクト設定のBuild / XML documentation fileを有効にします。 当然、別の再構築後、XmlDocが欠落しているとビルドエラーが発生するため、多数のエラーが表示されます。 これを回避するには、最初に上記のオプションを有効にする必要があります。

適切なドキュメントを書くのが面倒な場合、またはテキストを入力しすぎたくない場合は、GhostDocなどのこのプロセスを自動化する機器を試してください。

コード契約

コードコントラクトは、Microsoft Researchの優れたフレームワークであり、ランタイムチェック、静的分析、およびドキュメント化のために、コード内で前提条件、事後条件、およびオブジェクトの不変条件を表現できます。 私はこれを多くの重要なプロジェクトで使用しましたが、非常に役立ちましたので、試してみることをお勧めします。

コードコントラクトを使用する場合は、新しいプロジェクトを作成した直後にコントラクトを有効にすることが重要です。 開発の途中でコントラクトを追加することは可能ですが、連絡先を相互に一致させるには、多くのクラスで変更する必要があります。 したがって、必要なすべての設定（少なくともCodeContractsEnableRuntimeChecking ）を有効にすることを忘れないでください。また、これらの設定が共通のプロパティグループに表示されることを確認してください。

StyleCop施行

以前、開発時のStyleCop構成について説明しました。 ただし、プロジェクトがCIサーバー上に構築されている場合、ReSharperはそこで効果がないため、MSBuildでStyleCop検証を実行できるようにする必要があります。

これは通常、プロジェクトファイルを手動で変更することによって行われます。 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マシンのセットアップも簡単になります。

AssemblyInfo

Visual Studioウィザードによって作成されたすべての.NETプロジェクトには、 Assembly属性の一部を含むAssemblyInfo.csファイルが自動的に入力されます（[プロパティ]サブフォルダーを参照）が、ウィザードですべてのAssembly属性を入力することはできません。 少なくとも次の属性が設定されていることを確認してください。

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

Visual Studioのスクリーンショットで、6つの線がすべて角かっこで囲まれており、それぞれが「アセンブリ：」で始まります。各行には、上記の属性の1つと、括弧と引用符で囲まれた対応するサンプルテキスト文字列があります。たとえば、最後は「1.0.0.0」です。

この最低限の要件は、配布するすべてのアセンブリに必要です。 この背後にある実際的な理由はNuGetです。選択したアセンブリファイルからNuGet仕様の自動作成を使用している場合、このツールはこれらのプロパティから必要な情報を取得します。

最初にもう1つのプロパティを設定することもできます。

 InternalsVisibleTo

このプロパティにより、内部クラスとインターフェイスが指定されたアセンブリから見えるようになります。 これは通常、プロジェクト用に作成する自動テストに使用されます。

接続文字列

接続文字列を管理する方法は、スタックオーバーフローで非常によくある質問です。 問題は、接続文字列をすべての開発者またはCIジョブに対して一意にする方法であり、ソースコードの公開中に接続の詳細を公開しないようにする方法です。

App.config （デスクトップアプリケーションの場合）またはWeb.config （Webアプリケーションの場合）で、実行時に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ファイルのマークダウンを好む理由の1つです。

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とMacOSXです。テーブルの後の左下隅にも「gitterjoinchat」バッジがあります。

自動ソリューション構造検証

この記事で説明したすべての設定を設定したとしても、遅かれ早かれ、開発者の1人がそれらを変更し、ソース管理に変更をコミットする可能性があります。 これは誤って発生する場合があり、多くの場合、これらの変更はコードレビュー中に検出されません。 これらの事故以外に、次の一般的なエラーに注意する必要があります。

  • 悪い参照：誰かが他の人が持っていない可能性のあるローカルアセンブリを参照している場合、または誰かがディスクからファイルを削除したときに、そのファイルへのリンクが.csprojファイルに残っている場合。 これは確かにビルドを壊しますが、変更がプッシュされ、他の人がそれをプルすると、遅すぎる可能性があります。 これは、ビルド中に検証できない静的Webファイルにとって特に重要です。
  • 名前の一貫性：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は、開発者がVisualStudioのバージョンを切り替えることを防ぎます。
  • DetectMissingFilesは、ソリューションまたはプロジェクトに追加された静的Webコンテンツまたはその他の非コードファイルに非常に役立ちます。
  • AllowBuildEventsは、不要な処理を行う可能性のあるカスタムビルドイベントの追加を防ぐことができます。
  • Propertiesは最も柔軟な要素です。既知のプロパティであるかカスタムであるかに関係なく、任意のプロパティを目的の値と照合できます。

結論

新しいプロジェクトを開始するときに適用できるいくつかの標準的な方法、構成ファイル、およびプロジェクト設定を確認しました。 これを最初に行うと、将来の技術的負債が減り、製品のソースコードが見栄えが良くプロフェッショナルになります。 オープンソースプロジェクトの場合、これは特に重要です。なぜなら、貢献者はソリューション構成とプロジェクトファイルを調べることであなたの期待を知ることができるからです。

関連： .NETCore-ワイルドでオープンソースになります。 マイクロソフト、どうしてそんなに時間がかかったの？