バックエンド
ブートストラップを使用して.NETプロジェクトを作成する方法
.NETプロジェクトを作成する
.NETプロジェクトを最初から作成するのは、使用するのと同じくらい簡単です。 VisualStudioウィザード 。そして、 File => New Project 、または Add New Project 既存のソリューションの場合。新しいプロジェクトが作成されたら、すぐにコーディングを開始できます。ただし、によって生成されるデフォルトのプロジェクト設定 ウィザード それらは一般的な品質を低下させるため、プロのチームにはほとんど受け入れられません。さらに、他にはありません ウィザード 特定の開発環境で実行する必要のある他の構成手順について知っている場合があります。
この記事では、新しいプロジェクトを作成するときに有効にする必要があるいくつかの重要な設定について説明します。これは、将来の技術的負債を最小限に抑えるために重要です。また、いくつかの一般的な慣行を確認します .NET開発者 ソリューションや新しいプロジェクトを構築するときに適用します。これらのアイデアの一部を適用していない場合でも、これらのチームのほとんどが行っていることの概要を学び、確認することは良いことです。
構造
複雑なプロジェクトでは、明確に定義された構造を持つことが不可欠です。これにより、チームに参加する新しいメンバーのログインエクスペリエンスが向上し、古いプロジェクトをサポートする際の作業も楽になります。優れた構造には2つの重要な指標があります。
- プロジェクトフォルダとソリューションフォルダを使用する
- 常に名前を付ける
記録
ソリューションフォルダ 、と呼ばれることもあります 仮想フォルダ 、プロジェクトをグループ化するための非常に便利なツールです。ビューで エクスプローラーソリューション 右クリックしてAgregar => Nueva Carpeta de Soluciónを選択し、既存のプロジェクトをこの新しいフォルダにドラッグアンドドロップします。これらのフォルダーのファイルシステムにはコピーがありません。これにより、物理構造を変更せずに維持できるため、プロジェクトをあるソリューションフォルダーから別のソリューションフォルダーに移動するときに、実際には物理的に移動されません。
プレフィックスをリストする必要はありませんが、ウィンドウにフォルダを配置する必要があります エクスプローラーソリューション 、 もしそれが。
Visual Studioは、モデルを活用することにより、複数のソリューションを同時に処理できます 独自のパーティションソリューション または マルチソリューション 。それらはめったに使用されないので、この記事ではそれらについては説明しません。
とは異なり ソリューションフォルダ 、 プロジェクトフォルダ 物理フォルダ構造をバインドするため、ディスク上の実際のフォルダとして存続します。さらに、C＃コードを含むプロジェクトフォルダは、 名前空間 。これにより、ナビゲーションが非常に自然になります。ルールを有効にできます ReSharper これらの非互換性について警告します。
名付ける
命名に関連する推奨ルールはいくつかあります。
- 用途 キャメルケース 。
- プロジェクト名は、出力アセンブリ名と一致する必要があります。
- 自動テストを含むプロジェクトには、接尾辞
.Testsを付ける必要があります。 - すべてのプロジェクト名には、
Company.Productなどの共通のサフィックスを付ける必要があります。
いくつかの合理的なルールもあります。常識（そしてもちろん文法）に基づいて、いつそれらを適用するかを自分で決める必要があります。
- コンテナ（プロジェクトまたはフォルダ）に同じタイプの複数のインスタンスが含まれている場合は、複数形でサブジェクトを使用します（例：
TestsまたはSystem.Collections）。 - コンテナ全体に単一のエンティティに関するコードが含まれている場合は、単一の形式を使用します（System.Collections.ModelObject`など）。
- 短い略語の場合は、
System.IOのように大文字にします。 - 長い略語の場合は、 キャメルケース as
Modules.Forex.。
固定された経験則：短い略語は3文字以内にする必要があります。
構成ソリューション
ソリューションのセットアップは、環境に必要なすべてのインフラストラクチャファイルを提供するのと同じくらい簡単です。それらのいくつかは後で追加できますが（CI統合ファイルなど）、最初はファイルが少ないはずです。
SQLのパフォーマンスを向上させる方法
ReSharper設定
プロの.NET開発者であれば、おそらくReSharperを使用します。 ReSharper 設定の管理は非常に柔軟です。チームリーダーとして、構成を作成および配布できます *チーム共有* それは他の開発者によって使用されます。構成 *チーム共有* 拡張子が.DotSettingsのファイルに保存されます。 ReSharper ファイル名がのソリューション名と一致する場合、これらの設定を自動的に選択します Visual Studio ：
MyCompany.MyProduct.sln MyCompany.MyProduct.sln.DotSettings このため、チーム全体にいくつかの設定を適用する場合は、最初にこのファイルを作成する必要があります。良い例は、キーvarを使用する（または使用しない）ルールです。設定ファイル チーム共有 このルールのみを持つことができますが、他のルールは開発者の好みです。設定と同じように言及する価値があります ReSharper 変更できないレガシーコードがある可能性があるため、プロジェクトごとに1つのレベルに設定できます（たとえば、キーを使用するように変更var）。
例に示すように、このファイルに正しく名前を付けた場合、 Visual Studio の新規インストールで ReSharper このファイルを自動的に選択し、ルールを適用します。このファイルをソース管理にコミットすることを忘れないでください。
StyleCopルール
設定と同じように ReSharper 、設定を共有できます StyleCop 。使用する場合 ReSharper 、次に統合プラグインをインストールする必要があります。これにより、 StyleCop オン ReSharper 。それにもかかわらず、 StyleCop その設定をSettings.StyleCopという名前のファイルに個別に保存します。同様に、このファイルをソリューションファイルおよびプロジェクトファイルと一緒に持つことができます。
使用している場合 StyleCop 、構成ツールを実行することを忘れないでください StyleCop 実行したくないチェックを無効にします。デフォルトでは、すべてのチェックが有効になっています。このファイルに新しい設定を保存し、それらをソースコードにコミットします。
テキストファイル
公開製品を構築していて、ソースコードを公開する場合は、次のファイルも作成してコミットすることを忘れないでください。
README.md LICENSE 私はフォーマットを使用することをお勧めします マークダウン README.mdファイルの場合、GitHubなどのパブリックソース管理サービスやBitBucket（旧Stash）などの内部サーバーによってサポートされる業界標準になったためです。
NuGetの仕様
NuGetギャラリーで配布されるライブラリを構築している場合は、MyProject.nuspecのような仕様パッケージファイルを作成する必要があります。これらのパッケージを手動で作成し、ソース管理にコミットすることを好みます。パッケージは通常、継続的インテグレーション（略してIC）ジョブの1つによって公開されますが、以下に示すように、いつでもコンソールから手動でパッケージをビルドおよび公開できます。
nuget.exe pack MyLibrary.nuspec このコマンドを実行する前に、パッケージのバージョンを増やすことを忘れないでください。
特定のICファイル
私たちは皆、異なるICサービスを使用しており、それらはすべて異なる構成および設定スクリプトを持っています。追加を検討できるいくつかの一般的な追加について説明します。
- 設定 NUnit 、特定のジョブに対してICサーバーで実行するテストを含むアセンブリを指定します。すべてのテストは、実際にはいくつかのカテゴリに分類されます。がある ユニットテスト 各構築で実行する必要があります、 パフォーマンステスト それは毎晩実行され、そして 統合テスト 起動するたびに実行されます。
- 設定 NCover 、テストカバレッジについて分析する必要があるテストアセンブリを指定します。
- 設定 SonarQube 、収集されるソフトウェアメトリックを決定します。
- 作業スクリプト NAnt、PowerShell、またはWindowsバッチファイルなど。
プロジェクトの構成
プロジェクトファイル、すなわち.csprojまたは.vbpro、によって使用されるすべての設定が含まれます Visual Studio およびMSBuild。ただし、すべてがウィンドウで使用できるわけではありません プロジェクトのプロパティ 。これらのファイルを編集するには Visual Studio 手動で、次のことを行う必要があります。
- ビュー内のプロジェクトを右クリックします ソリューションエクスプローラー 。
- 選択 プロジェクトのアンロード 。
- もう一度右クリックして、action_Editxyz.csproj_を選択します。
- 編集を完了します。
- プロジェクトをもう一度右クリックして、 プロジェクトのリロード 。
または、お気に入りのテキストエディタでプロジェクトファイルを開き、編集して保存することもできます。ウィンドウに戻ったとき Visual Studio 、変更したプロジェクトをリロードするように求められます。
制御警告
高品質のソフトウェアを構築するには、建設に関する警告を決して無視しないでください。このため、最大レベルの警告を有効にし、警告をエラーとして扱う必要があります。あなたが好きなすべてのビルド設定でこれを行う必要があることに注意してください デバッグ Y リリース 。これを行う最良の方法は、共通のプロパティグループに次の設定を書き込むことです。
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 そこでは効果がないため、StyleCop検証をMSBuildで実行できるようにする必要があります。
通常、これはプロジェクトファイルを変更することによって行われます。あなたはでプロジェクトをダウンロードする必要があります Visual Studio 、プロジェクトファイルを編集してから、プロジェクトを再度ロードします。
false StyleCopTreatErrorsAsWarningsそれはそれが言うことをします：それはStyleCopルールの違反のためにあなたのビルドを壊します。インポート要素は、ビルドチェーンにStyleCopテストを追加するためにMSBuildで必要です。
Program Filesへのパスに気づいたかもしれません。開発者は異なるバージョンのStyleCopをインストールしている可能性があるため、一部のチームは同じStyleCopインストールのプライベートコピーをソース管理下に保持することを好みます。この場合、パスは相対パスになります。これにより、StyleCopをローカルにインストールする必要がないため、CIマシンのインストールも簡単になります。
AssemblyInfo
によって作成されたすべての.NETプロジェクト ウィザード VisualStudioにはファイルがありますAssemblyInfo.cs自動的に入力されます（を参照） プロパティ サブフォルダー）いくつかのAssembly属性が含まれていますが、含まれていません ウィザード すべての属性を埋めることができますAssemblyあなたのために。少なくとも次の属性が入力されていることを確認してください。
AssemblyTitleAssemblyDescriptionAssemblyCompanyAssemblyProductAssemblyCopyrightAssemblyVersion
ブルームバーグターミナルの1か月あたりの費用はいくらですか
これは、配布するアセンブリに最低限必要なものです。この背後にある実用的な理由の1つは、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パッケージの最新バージョンを表示します。
バッジと関連サービスの完全なリストは、次のURLで確認できます。 shields.io 。オープンソースプロジェクトに適したバッジがいくつか見つかるかもしれません。
1株あたりのIPO価格の計算方法
特定のサービスでプロジェクトに登録すると、画像へのリンクと完全なマークダウン構文へのリンクが表示され、ファイルに追加できます.csproj 。ちなみに、これがファイルよりもマークダウンを好む理由の1つです Readme 。
Project Roslynのサンプルマークダウンバッジ：
MiCompañía.MiProducto
構造ソリューションの自動検証
この記事で説明したすべての設定をある時点で確立しましたが、一部の開発者はそれらを変更して、コントロールソースに変更を保存することができます。これは誤って発生することがあり、通常、コードを確認してもこれらの変更は見られません。これらの事故とは別に、次のエラーに注意する必要があります。
- 悪い参照 ：他の人が持っていないローカルアセンブラを参照する場合、または誰かがディスクからファイルを削除するときに、そのファイルへのリンクがファイル内に続く場合
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-ワイルドでオープンソース化。マイクロソフト、どうしてそんなに時間がかかったの？
