3

私は、クライアントアプリケーションに多くの便利な拡張メソッドを提供するクラスライブラリプロジェクトに取り組んでいます。このプロジェクトは、さまざまなプラットフォーム（.NET Frameworkのバージョン）で使用されることが期待されています。

そのために、それぞれが独自のプラットフォーム用に、いくつかの個別のVisualStudioプロジェクトを使用します。これらのプロジェクトには独自の外部依存関係がある可能性がありますが、「参照として追加」機能を使用してソースコードをプロジェクト間で共有します。このアプローチにより、他のプロジェクトにコピーすることなく、1つのファイルにコードを記述することで、すべてのプロジェクトの実装を変更できます。ターゲットフレームワークの違いを念頭に置いて、#ifコンパイラ指令を使用する必要があります。各プロジェクトの結果は、特定のバージョンの.NETFramework用のNuGetパッケージとして公開されます。

これが私が持っている2つの質問です：

  1. すべての新しいファイルをすべてのプロジェクトに追加する必要があります。そうしないと、ファイルがコンパイルされず、その中で定義されているすべてのクラスに特定のプラットフォームでアクセスできなくなります。ご存知のように、それを忘れるのは非常に簡単です。この種のファイル追跡を回避する方法はありますか？それを自動化することは可能ですか？
  2. どうすればインフラストラクチャ全体を改善できますか？プロジェクトでどのようなアプローチやソリューションを使用していますか？
4

2 に答える 2

5

そのために、それぞれが独自のプラットフォーム用に、いくつかの個別のVisualStudioプロジェクトを使用します。

あなたはそれをする必要はありません。同じプロジェクトに対して複数の構成を持つことができます。プロジェクトファイルを編集して処理する必要がありますが、それを行う必要があるのは1回だけです（または、少なくとも、新しいプラットフォームを追加する必要があるたびに1回）。各プロジェクト構成で定義された条件付きコンパイルシンボルを使用して、各ビルド構成でソースコードの特定のビットを除外できるようにします。

私はこれを数回前に行いました。これは、NodaTimeでPCLをビルドできるようにするために使用しているアプローチです。私は6つの構成になりました：

  • デバッグ
  • PCLをデバッグする
  • リリース
  • PCLをリリース
  • 署名されたリリース
  • 署名されたリリースPCL

明らかにあなたのニーズは（特に署名に関して）異なるかもしれませんが、今はうまく機能しています-そして、いくつかのプロジェクトファイルを手動で同期させるよりもはるかに良いと思います。

もう1つのオプションは、プラットフォームごとに「スケルトン」プロジェクトファイルと単一の「マスター」プロジェクトファイルを用意し、マスター以外のすべてのプロジェクトファイルを生成することです。したがって、新しいソースファイル参照をマスタープロジェクトファイルに追加してから、他のすべてを再生成します。これは、それを行うためのコードを書くことを意味します、気をつけてください...またはprotobuf-csharp-portに使用するプロジェクトを使用してください：csprojectprojector

于 2013-01-06T21:42:51.403 に答える
1

別のアプローチは、プロジェクトに個々のファイルを含める代わりにワイルドカードを使用することです。これには、プロジェクトファイルを手動で編集する必要もありますが、これは1回限りの作業になります。私はこのアプローチを使用したことはありませんが、他の人から言及されているのを見たことがあります。

http://msdn.microsoft.com/en-us/library/ms171454(v=vs.100).aspx

于 2013-01-14T06:11:24.877 に答える