TFS には、一般的な拡張メソッド、ユーティリティ クラスなど、社内のすべてのチームと共有できる汎用コード専用の TeamProject があります。ある意味では、.Net フレームワーク自体の拡張機能のように機能します。
現在、チームが機能の一部を必要とするときに、毎回依存関係の束をドラッグする必要がないように、領域ごとに区切られた多数のプロジェクトがあります。これらのプロジェクトの命名規則は、形式に従います[OurCompany].Framework.[Equivalent .Net Namespace]。
ソリューションに含まれる dll の例をいくつか示します。
- Mobiltec.Framework.dll
- Mobiltec.Framework.Web.dll
- Mobiltec.Framework.Data.dll
- ...
異なるプラットフォームで同じ拡張機能を作成しようとすると、問題が発生します。たとえば、Silverlight をターゲットとする Mobiltec.Framework.dll と、WindowsMobile プラットフォーム用のものがあります。ソリューションがビルド サーバーでビルドされると、すべての出力が同じフォルダーに移動し、最後にビルドされた同じ名前の dll のみが残ります (以前にビルドされたものは上書きされます)。これは明らかに、上書きされたファイルに依存する次のすべてのプロジェクトで発生するエラーにつながります。
dll 名でプラットフォームを指定しないことは良い習慣であり、サード パーティのライブラリや .Net フレームワーク dll の標準でもあるようです。Nugetパッケージもそれを奨励しているようです（log4netが思い浮かびます）。異なるバージョンは、動作するプラットフォーム/.netバージョンを示すフォルダーで区切られていますが、dll名自体は同じです。
各プラットフォームおよび/またはこのフレームワークの各 .Net バージョンに対して異なるソリューションを作成する必要がありますか? Visual Studio 2012 はスマート デバイス プロジェクトをサポートしていないため、現在 2 つのソリューションがあります。Windows Mobile SDK を対象とするすべてのプロジェクトを含む Framework.Legacy.sln ファイルと、他のすべてのプロジェクト (デスクトップ、Silverlight など) を含む別のファイルがあります。
理想的には、同じソリューションでできるだけ多くのプロジェクトを共有したいと考えています。これは、リファクタリング タスクがはるかに簡単になるためです (一部の機能は、リンクされた .cs ファイルによってプラットフォーム間で共有されます)。
TFS でこのプロジェクトのビルドを作成したばかりなので (したがって、問題を認識しただけです)、別のソリューションでフレームワークの Silverlight バージョンを分離し、ビルド定義で「ソリューション固有のビルド出力」オプションを「true」に設定しました。現在、3 つのソリューションがあります (1 つは WindowsMobile 用、もう 1 つは「通常の .Net4」用、もう 1 つは Silverlight 5 用)。現時点では、すべてが意図したとおりに機能しているように見えますが、リファクタリングの可能性が失われていると感じており、これを解決するためのより良い方法があるかどうか疑問に思っていました。近いうちにさらに別のバージョン (たとえば Windows RT 用) を追加できる可能性があることを考慮してください。将来。
私が知りたいのは、これをどのように正しく管理すれば、TFS ビルド システムと連携しながら簡単に保守できるようになるかということです。同じ問題に対処しなければならなかった他の人がいると確信しています。どのように対処しましたか？