バックエンド
.NETプロジェクトをブートストラップして作成する方法
.NETプロジェクトを作成する
.NETプロジェクトを最初から作成するには、VisualStudioウィザードを使用するのと同じくらい簡単です。 File => New ProjectまたはAdd New Projectに移動します既存のソリューションに。新しいプロジェクトが作成されたら、すぐにコーディングを開始できます。ただし、ウィザードによって作成されたデフォルトのプロジェクト設定は、品質の基準が低すぎるため、プロのチームにはほとんど受け入れられません。さらに、特定の開発環境で実行する必要のある他のセットアップ手順をウィザードが知ることはできません。
この記事では、新しいプロジェクトを作成したらすぐに有効にする必要があるいくつかの重要な設定について説明します。これは、将来の技術的負債を最小限に抑えるために重要です。また、いくつかの一般的な慣行を確認します .NET開発者 ソリューションや新しいプロジェクトを構築するときに適用します。これらのアイデアの一部を適用していない場合でも、ほとんどのチームが行っていることの概要を学び、理解することは素晴らしいことです。
構造
複雑なプロジェクトでは、明確に定義された構造を持つことが不可欠です。これにより、新規参入者がチームに参加するときのオンボーディングエクスペリエンスが向上し、古いプロジェクトをサポートするときの作業が楽になります。優れた構造を示す2つの重要な指標があります。
- ソリューションおよびプロジェクトフォルダーの使用
- 一貫した命名
フォルダー
ソリューションフォルダ 、と呼ばれることもあります 仮想フォルダ は、プロジェクトをグループ化するための非常に便利な手段です。の中に ソリューションエクスプローラー 表示するには、右クリックしてAdd => New Solution Folderを選択し、既存のプロジェクトをこの新しいフォルダーにドラッグアンドドロップします。これらのフォルダーはファイルシステムにミラーリングされないため、物理構造を変更せずに維持できるため、プロジェクトを1つのソリューションフォルダーから別のソリューションフォルダーに移動しても、物理的に移動することはありません。
コンサルティングビジネスのクライアントを見つける方法
プレフィックスに番号を付ける必要はありませんが、フォルダが順番に表示されます。 ソリューションエクスプローラー 窓。
Visual Studioは、を活用することで、複数のソリューションを同時に処理できます。 パーティション化された単一のソリューション または マルチソリューション モデル。これらはめったに使用されないため、この記事では取り上げません。
とは異なり ソリューションフォルダ 、 プロジェクトフォルダ 物理フォルダの構造と一致するため、ディスク上の実際のフォルダとして存続します。さらに、C＃コードを含むプロジェクトフォルダはプロジェクトの 名前空間 。これにより、ナビゲーションが非常に自然になります。 ReSharperルールを有効にして、このような不一致を警告することもできます。
ネーミング
命名に関連して適用する推奨ルールはいくつかあります。
- 使用する キャメルケース 。
- プロジェクト名は、その出力アセンブリ名と一致する必要があります。
- 自動テストを含むプロジェクトには、接尾辞
.Testsを付ける必要があります。 - すべてのプロジェクト名には、
Company.Productのような共通のプレフィックスを付ける必要があります。
合理的なルールもいくつかあります。常識（そしてもちろん英語の文法）に基づいて、いつそれらを適用するかを自分で決める必要があります。
- コンテナ（プロジェクトまたはフォルダ）に同じ種類の複数のインスタンスが含まれている場合は、複数形でサブジェクトを使用します（例：
TestsまたはSystem.Collections）。 - コンテナ全体に単一のエンティティに関するすべてのコードが含まれている場合は、単一の形式を使用します（System.Collections.ObjectModel`など）。
- 短い略語の場合は、
System.IOのような大文字を使用しますします。 - 長い略語の場合は、
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でこれらのファイルを手動で編集するには、次の手順を実行する必要があります。
- ソリューションエクスプローラービューでプロジェクトを右クリックします。
- 選択する プロジェクトのアンロード 。
- もう一度右クリックしてアクションを選択します xyz.csprojを編集する 。
- 完全な編集。
- プロジェクトをもう一度右クリックして、 プロジェクトのリロード 。
または、お気に入りのテキストエディタでプロジェクトファイルを開き、編集して保存することもできます。 Visual Studioウィンドウに戻ると、変更したプロジェクトを再読み込みするように求められます。
警告制御
高品質のソフトウェアをビルドするには、ビルドの警告を決して無視しないでください。したがって、最大警告レベルを有効にし、警告をエラーとして扱う必要があります。デバッグやリリースなど、使用しているすべてのビルド構成に対してこれを行う必要があることに注意してください。これを行う最良の方法は、共通のプロパティグループに次の設定を書き込むことです。
4 true また、他のプロパティグループに同じ設定がないことを確認してください。それ以外の場合は、共通グループの対応するプロパティを上書きします。
FxCop
FxCopの実行は、すべてのビルドで実行するのが実際的です。ほとんどのチームは、重大なエラーが発生していないことを確認するために、時々（通常はリリース前に）FxCopを実行することを好みます。ただし、すべてのビルドで最終的なチェックを実行する場合は、次のオプションを追加します。
true FxCopには、StyleCopと同様に、ルートフォルダーに配置してソース管理に追加できる独自の設定があることに注意してください。これらの設定は、CIサーバーでFxCopを実行するときに使用される可能性があります。
ドキュメンテーション
この部分はXmlDocについてです。パブリックAPIを構築している場合は、APIドキュメントを作成して維持する必要があります。ほとんどの開発者はAPI開発（実際のコーディング）から始め、リリースの直前にプロジェクト設定を有効にしますBuild / XML documentation file。当然、次の再構築後、XmlDocが欠落しているとビルドエラーが発生するため、多数のエラーが表示されます。これを回避するには、最初に上記のオプションを有効にする必要があります。
適切なドキュメントを書くのが面倒な場合、またはテキストを入力しすぎたくない場合は、次のようなこのプロセスを自動化する機器を試してください。 Ghostdoc 。
コード契約
コード契約 はMicrosoftResearchの優れたフレームワークであり、実行時チェック、静的分析、およびドキュメント化のために、コード内で前提条件、事後条件、およびオブジェクト不変条件を表現できます。私はこれを多くの重要なプロジェクトで使用しましたが、非常に役立ちましたので、ぜひお試しください。
コードコントラクトを使用する場合は、新しいプロジェクトを作成した直後にコントラクトを有効にすることが重要です。開発の途中でコントラクトを追加することは可能ですが、連絡先を相互に一致させるには、多くのクラスで変更する必要があります。したがって、必要なすべての設定（少なくともCodeContractsEnableRuntimeChecking）を有効にし、これらの設定が共通のプロパティグループに表示されることを確認することを忘れないでください。
StyleCopエンフォースメント
以前、開発時のStyleCop構成について説明しました。ただし、プロジェクトがCIサーバー上に構築されている場合、ReSharperはそこで効果がないため、MSBuildでStyleCop検証を実行できるようにする必要があります。
これは通常、プロジェクトファイルを手動で変更することによって行われます。 Visual Studioでプロジェクトをアンロードし、プロジェクトファイルを編集してから、プロジェクトを再度ロードする必要があります。
false 設定StyleCopTreatErrorsAsWarningsそれが言うことをします：それはどんなStyleCopルール違反でもあなたのビルドを壊します。 MSBuildがStyleCopタスクをビルドチェーンに追加するには、インポート要素が必要です。
Program Filesへのパスに気づいたかもしれません。開発者は異なるStyleCopバージョンをインストールしている可能性があるため、同じStyleCopインストールのプライベートコピーをソース管理下に置くことを好むチームもあります。この場合、パスは相対パスになります。これにより、StyleCopをローカルにインストールする必要がないため、CIマシンのセットアップも簡単になります。
AssemblyInfo
VisualStudioウィザードによって作成されたすべての.NETプロジェクトにはAssemblyInfo.csがあります。ファイルは自動的に入力されます（を参照） プロパティ サブフォルダー）Assemblyの一部が含まれています属性が、すべてのAssemblyを埋めることができるウィザードはありませんあなたのための属性。少なくとも次の属性が入力されていることを確認してください。
AssemblyTitleAssemblyDescriptionAssemblyCompanyAssemblyProductAssemblyCopyrightAssemblyVersion
Twitterからデータを抽出する方法
この最低限の要件は、配布するすべてのアセンブリに必要です。この背後にある実用的な理由はNuGetです。選択したアセンブリファイルからNuGet仕様の自動作成を使用している場合、このツールはこれらのプロパティから必要な情報を取得します。
最初にもう1つのプロパティを設定することもできます。
InternalsVisibleTo このプロパティにより、内部クラスとインターフェイスが指定されたアセンブリから見えるようになります。これは通常、プロジェクト用に作成する自動テストに使用されます。
接続文字列
管理する方法 接続文字列 スタックオーバーフローで非常に人気のある質問です。問題は、接続文字列をすべての開発者またはCIジョブに対して一意にする方法であり、ソースコードの公開中に接続の詳細を公開しないようにする方法です。
App.configで（デスクトップアプリケーションの場合）またはWeb.config （Webアプリケーションの場合）ロードする次の設定を行いますuser.config実行時のファイル。これをソース管理下に置いてください：
user.configどうやら、.gitignoreファイルはソース管理から除外する必要があり、すべての開発者はこのファイルのローカルコピーを持っている必要があり、接続文字列のプライバシーを保護します。
.gitignore.gitignore
Gitをソース管理として使用する場合は、いくつかのファイルパターンをREADMEに追加することが重要です。ファイル。ただし、スマートコミュニティでは、一般化されたファイルがすでに作成されています。このファイルは次の場所にあります。 github.com/github/gitignore/blob/master/VisualStudio.gitignore 。
参照として使用する必要がありますREADME.mdファイルを作成し、さらに必要になる可能性のあるカスタム除外を追加するだけです。
ブラックベリーの電話に何が起こったのか
GitHubバッジ
[](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/)) [](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))に見栄えの良いバッジが表示されているのを見たことがあるかもしれません。プロジェクトのページ。プロジェクトをで公開している場合 GitHub 、次の目的でプロジェクトを公共サービスに接続することを検討してください。
- ビルド：ビルドが失敗または成功していることを示します。
- テスト：テストカバレッジとテスト実行ステータスを表示します。
- 公開：最新のNuGetパッケージバージョンを表示します。
バッジと関連サービスの完全なリストは、にあります。 shields.io 。オープンソースプロジェクトに適した興味深いバッジがたくさん見つかるかもしれません。
選択したサービスにプロジェクトを登録すると、画像へのリンクと完全なマークダウン構文リンクが表示され、.csprojに追加できます。ファイル。ちなみに、これはあなたがマークダウンを好むべき理由の1つです Readme ファイル。
Roslynプロジェクトからのサンプルマークダウンバッジ：
MyCompany.MyProduct
自動ソリューション構造検証
この記事で説明したすべての設定を設定したとしても、遅かれ早かれ、開発者の1人がそれらを変更して、ソース管理に変更をコミットする可能性があります。これは誤って発生する場合があり、コードレビュー中にこれらの変更が検出されない場合がよくあります。これらの事故以外に、次の一般的なエラーに注意する必要があります。
- 悪い参照 ：誰かが他の人が持っていない可能性のあるローカルアセンブリを参照している場合、または誰かがディスクからファイルを削除したときに、そのファイルへのリンクが
Install-Package SolutionInspectorに残っている場合ファイル。これは確かにビルドを壊しますが、変更がプッシュされ、他の人がそれをプルすると、遅すぎる可能性があります。これは、ビルド中に検証できない静的Webファイルにとって特に重要です。 - 命名の一貫性 ：StyleCopなどのツールはC＃ソースコードを制御できますが、プロジェクトファイルやアセンブリプロパティのルールを適用できるツールはありません。良い例は次のとおりです。出力アセンブリ名と一致するようにプロジェクトに名前を付け、プロジェクト名に
](http://www.w3.org/2001/XMLSchema-instance' xmlns:xsd='http://www.w3.org/2001/XMLSchema'>) 12.00 12.00 true MyCompany.MyProduct. true AVerySpecialProject1; AVerySpecialProject2; true true true true StyleCop.MSBuild.Targets true falseのような共通のプレフィックスを付けます。
コードレビューでこれらのエラーを監視することはエラーが発生しやすく、自動化する必要があることがわかりました。そこで、ソリューションの一貫性を検証するために、これらのチェックや他の多くのチェックを実行する簡単なツールを作成しました。会う SolutionInspector 。これはオープンソースであり、MITライセンスの下で配布されています。ソースコードからビルドするか、NuGetからインストールできます。
MinSolutionFormatVersionこのツールは、ソリューション構造全体をウォークスルーし、多くの検証ルールを適用します。ルールはXMLファイルによって構成され、他のソリューションファイルと一緒に配置されます。プロジェクトごとに設定を制御するには、設定が異なる同じファイルを対応するプロジェクトフォルダに追加するだけです。
デフォルトでは、構成ファイルは必要ありません。この場合、ツールは使用可能なすべてのルールを適用し、すべての問題をコンソールに生成します。
構成ファイルの例を次に示します。
MaxSolutionFormatVersion設定はかなり説明的ですが、それらのいくつかを説明します。
DetectMissingFiles/AllowBuildEvents開発者がVisualStudioのバージョンを切り替えるのを防ぎます。Propertiesソリューションまたはプロジェクトに追加された静的Webコンテンツまたはその他の非コードファイルに非常に役立ちます。|_+_|
不要なことを行う可能性のあるカスタムビルドイベントの追加を防ぐことができます。|_+_|
は最も柔軟な要素です。既知のプロパティであるかカスタムであるかに関係なく、任意のプロパティを目的の値と照合できます。
結論
新しいプロジェクトを開始するときに適用できるいくつかの標準的な方法、構成ファイル、およびプロジェクト設定を確認しました。これを最初に行うと、将来の技術的負債が減り、製品のソースコードが見栄えが良くプロフェッショナルになります。オープンソースプロジェクトの場合、これは特に重要です。なぜなら、貢献者はソリューション構成とプロジェクトファイルを調べることであなたの期待を知ることができるからです。
関連： .NETCore-ワイルドでオープンソース化。マイクロソフト、どうしてそんなに時間がかかったの？
