0

msbuild と Visual Studio は、プロジェクトの依存関係を異なる方法で解決しているようです。ソリューション ファイルには、メインの実行可能ファイルのプロジェクトと、実行可能ファイルが依存する dll のいくつかのプロジェクトが含まれています。これらの dll プロジェクトの 1 つは、ソリューションの一部ではない別のプロジェクトに依存しています。

この場合の主なプレーヤーと、それを再現する簡単な方法を示すためだけに: ソリューションには ExeProject と MainDllProject が含まれています。ExeProject は MainDllProject の MainDllProjectClass1 に依存します (そのクラスは SubDllProject に依存しません。MainDllProjectClass2 のみが SubDllProject に依存しますが、ExeProject や MainDllProjectClass1 では使用されません):

Solution
    ExeProject
        Form1 (depends on MainDllProject.MainDllProjectClass1)
    MainDllProject
        MainDllProjectClass1
        MainDllProjectClass2 (depends on SubDllProject.SubDllProjectClass)
Not part of the solution
    SubDllProject
        SubDllProjectClass

Visual Studio 2010 でソリューションをビルドすると失敗します: SubDllProject が見つからないため、MainDllProject をビルドできません。

msbuild を使用してソリューションをビルドすると、ビルドは成功します。奇妙なことに、SubDllProject のデバッグ バージョンは、パラメーター /p:Configuration=Release にもかかわらずビルドされます。

msbuild のログ ファイルは 374 kB ほどありますが、分析方法のヒントはありますか? SubDllProject をまったくビルドする理由、デバッグ バージョンである理由、および参照されていないときにビルドされないようにする方法を最終的に理解したい (参照されているすべてのプロジェクトをソリューションに含める必要があり、依存関係が忘れられた場合、私はエラーメッセージを表示したい)。

注: このケースはVisual Studio build non-dependent projects in solutionに似ていますが、まったく逆です... http://blogs.msdn.com/b/visualstudio/archive/2010/12/21から理解しています/incorrect-solution-build-ordering-when-using-msbuild-exe.aspx では、msbuild が sln ファイルを独自の形式に変換しますが、sln.metaproj ファイルには SubDllProject への参照も表示されません。

4

1 に答える 1