新しいアップデート：
他の回答で報告されているように、短命の機能ブランチには問題ない回避策を見つけましたが、実際にはうまく機能しませんでした。それ以来、私は問題に戻ってきましたが、完全な解決策はとてつもなく単純です。
TFSBuild.proj では、パスは $(BuildProjectFolderPath) に基づいていました。このパスは、ローカル パス (D:\ServerBuildFolder\Main) ではなく、$/Main のようなサーバー側(ソース管理パス) に解決されます。
残念ながら、歴史的な理由から、ソース コードは複数のチーム プロジェクトに分割されています。つまり、1 つの「ブランチ」が、ソース管理の複数の分岐フォルダー ($/Main/Code および $/Libraries/Code など) に断片化されています。 $/Main および $/Libraries を含むブランチ)。したがって、ワークスペース マッピングを使用して、これらの異種フラグメントをソース管理から一貫した階層に再構築する必要があります。
これは、Richard が的確であったことを意味します。TFSBuild.proj ファイルから .sln ファイルへの相対パスが正しくありませんでした。これは、MSBuild/TFS が .sln が同じチーム プロジェクトおよびソース管理階層内にあると想定しているためです (したがって、 $/Libraries/Libraries.sln の代わりに $/Main/Libraries.sln)。
解決策は簡単です: $(BuildProjectFolderPath) をファイルのローカル パス (例: D:\ServerBuildFolder\Main) に置き換えて、相対参照が "ローカル空間" で解決されるようにしました (マッピングが適用された後)。 MSBuild がスムーズに実行されるようになりました。
この話の教訓: 1) コードベース間で何らかの参照が必要になる可能性がある場合は、決して複数のチーム プロジェクトを使用しないでください。新しいチーム プロジェクトが、アプリケーションとライブラリの間のある種の痛みのない論理的な区別を提供すると思い込まないでください。余分なプロジェクトは、管理上の悪夢であることが証明されています。まったくメリットがないのに、余分な問題が山ほどあります。(ボンネットの下にある 1 つの大きな共有パイルなので、すべての作業項目とソース管理フォルダーはすべてのプロジェクトで引き続き表示されます (!) が、プロジェクト間のリンクを非常に問題にするレンガの壁がいくつか追加されます)。
2) チーム プロジェクトのソース管理にルート レベルのフォルダーを常に 1 つ作成し、他のすべてをそのフォルダーの下に配置します。たとえば、プロジェクト「$/Main」の場合、「$/Main/Root」を作成し、ソース階層のすべてをルート内に配置します。
これらのルールに従うことで、将来、単一の「ルート」フォルダーを分岐できるようになり、単一の分岐と単一の追加のワークスペース マッピングのみが必要になります。これにより、早期脱毛を防ぐことができます。
(私の弁護では、最初からこのようにしていただろう - 私はレガシー セットアップで作業しています。レガシー セットアップの弁護では、理論的には良さそうに思えますが、Microsoft がサポートするアプローチではありません!)