3

複数の .sln ファイルを使用するコード プロジェクトがあり、それぞれにプロジェクトが含まれています (一部のプロジェクトは異なるソリューションで共有されています。つまり、複数のソリューションに存在します)。

私たちの問題は、プロジェクト参照を使用する場合、実際のプロジェクトも同じソリューションに存在する必要があることです。

これらのプロジェクトはすべて、ビルド サーバーで MSBuild を使用してビルドされています。

すべてのプロジェクトを単一の MSBuild プロジェクトに何らかの方法で「インポート」する MSBuild スクリプトを作成できるかどうか疑問に思っています。これにより、実際にはすべてのプロジェクトが同じ Visual Studio .sln ファイルの下にある場合と同じになります。

たとえば、次のスクリプトに似たものが必要です。

<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">

    <!-- Builds all *.sln files under this repository. -->
    <ItemGroup>
        <SolutionFiles Include="**/*.sln" />
    </ItemGroup>

    <Target Name="Build">
        <MSBuild Projects="@(SolutionFiles)" Targets="Rebuild" />
    </Target>

</Project>

これは、MSBuild がすべてのプロジェクトのインメモリ "マスター プロジェクト" を構築し、プロジェクト参照の問題を解決するということですか?

4

5 に答える 5

2

上記の構文を使用して csprojs を直接ビルドしてみませんか? 

<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">

<!-- Builds all *.*proj files under this repository. -->
<ItemGroup>
    <!--SolutionFiles Include="**/*.sln" /-->
    <ProjectFiles Include="**/*.*proj"/>

</ItemGroup>

<Target Name="Build">
    <MSBuild Projects="@(ProjectFiles)" Targets="Rebuild" />
</Target>

</Project>

MSBuild は、コマンド ライン モードのときに sln ファイルがない場合でも、既定でプロジェクト参照をビルドします。プロジェクト参照を省略したい場合 (つまり、順番に順番にビルドしている場合) は、 /p:BuildProjectReferences=false... を使用できます。

于 2012-12-31T20:30:56.553 に答える
1

私は似たようなことをしましたが、同じフォルダーに複数の .sln ファイルがあり、そのすべてがプロジェクトの一部またはすべてを参照していました。私の場合、ビルドのフレーバー (CI、ナイトリー、リリースなど) ごとに .sln ファイルがありました。

したがって、たとえば、合計で次のプロジェクトがあるとします。

  • Webサイト
  • ウェブサイト単体テスト
  • 共通図書館
  • 共通ライブラリ単体テスト
  • データ アクセス ライブラリ
  • データ アクセス ライブラリの単体テスト
  • Web サイト受け入れテスト (例: Selenium webdriver テスト)
  • ストレステスト

次の解決策があります。

  1. CI ソリューション(コミット時に実行)。これは、単体テスト プロジェクトとそのターゲットを参照します。

  2. 毎晩のソリューション(毎晩実行)。これは、ストレスおよび受け入れテスト プロジェクトを参照します。

  3. リリース ソリューション(リリースのオンデマンドで実行)。これは、Web サイト、共通およびデータ アクセス プロジェクトを参照します (つまり、テスト プロジェクトはありません)。

これは単なる例ですが、お役に立てば幸いです。このソリューション/プロジェクト構造がセットアップされると、それを変更する必要はあまりありませんが、新しいプロジェクトが追加された場合は、関連するソリューションに追加するだけの簡単な作業です.

于 2012-12-30T08:20:19.050 に答える
0

すべてのソリューション ファイルを検索してビルドする小さなコンソール アプリケーションを作成できます。適切な MSBuild バージョンも選択されます。

c# コンソール アプリケーションの作成

Microsoft.Build への参照を追加し、次のコードを使用します

  static void Main(string[] args)
  {
     string[] files = Directory.GetFiles(args[0], "*.sln", SearchOption.AllDirectories);

     foreach (string path in files)
     {
        RunMsBuild(path);
     }
  }

  public static void RunMsBuild(string SrcDir)
  {
     ProjectCollection pc = new ProjectCollection();
     Dictionary<string, string> GlobalProperty = new Dictionary<string, string>();

     //GlobalProperty.Add("Configuration", "Debug");
     //GlobalProperty.Add("Platform", "x86");
     //GlobalProperty.Add("OutputPath", "c:\\src");

     BuildRequestData buidlRequest = new BuildRequestData(SrcDir, GlobalProperty, null, new string[] { "Build" }, null);
     BuildResult buildResult = BuildManager.DefaultBuildManager.Build(new BuildParameters(pc), buidlRequest);
     if (buildResult["Build"].ResultCode == TargetResultCode.Success)
     {
        Console.WriteLine("Build Success");
     }
     else
     {
        Console.WriteLine("Build Fail");
     }
  }

その後、ソリューション ファイルを検索するパスを引数として渡すコンソールまたはスクリプトから実行できます。

于 2012-12-30T17:55:07.297 に答える
0

** 気にしないでください。プロジェクトにコマンドライン モードが含まれているため、以下の回答を見逃していました **

これは簡単でもきれいでもありません。しかし、以下の #4 は、あなたが求めているように、ビルドの自動化と管理のルートをより「完全に」進めたい場合に、どのように改善し始めるかを示しています。

1) OP の例では、スクリプトとして MSBuild を使用します。この例では、これは、MSBuild プロジェクトのトリックを実際に取得するよりも、シェルまたはバッチ ファイルを使用するのと同じように、より多くの自動化です。.sln ルールについては #2 を参照してください。また、これがもっとやりたいと思っていたことについては #3 を参照してください。

2）「メモリのみ」の.sln質問について: 基本的に、MSBuild で .sln ベースのプロジェクト参照を解決するために必要な .sln を使用する場合、それを「影響ゼロ」または「メモリのみ」の状態にすることはできず、フラッシュするか、フラッシュする必要があります。ディスクに保存されます。これは、プロジェクト システム自体を所有している場合でも当てはまります。MSBuild は参照を解決するためにファイル自体を調べ、それが別のプロセスで実行され、独自の心でファイル システムにあることを期待するからです。したがって、.sln ファイルを使用する場合は、実際の .sln ファイルが必要です。したがって、.sln ファイルのクラフトを使用しない .sln アプローチへの期待は的中しています。VS を実行して msbuild を実行すると、これらが生成され、MSBuild が開始される前にそれらをディスクにフラッシュする必要があります。そこでは、ビルドまで「影響なし」の状態のままになります...完全に冗長で明確にするためです。

3）「import .proj」の質問について：私があなたの目的のために知っている同様のオプションの1つ<Import Project="my/proj/path/mine.csproj"/>は、ファイルの一括インクルードとまったく同じであり、それらのファイルをその外部プロジェクトの一部であるかのように扱い、コンパイルしますそのアセンブリ。内部で microsoft によって頻繁に使用されます。この方法で使用されるインポートは、インポートされた .proj ファイル内の内容の多くを無視し、基本的に、外部プロジェクトに含まれる他のファイルと同様に、含まれるファイルを探します。したがって、とにかく同じアセンブリでそれらすべてを構築するつもりがない限り、これで先に進むとは思いません。その場合、含まれている .proj ファイルをこの意図で構造化し、外部を悪用/構造化して、すべてに必要な参照などを含める必要があります。

4）その参照定義。参照に関する多くのオプションがあり、それらがコピーされるか、GAC に配置されると想定されるか、または「実行時にアプリ ドメインの検索パスに存在することを何もせずに信頼してください」. そのcr * pのほとんどをオフにすることができます。その場合、唯一の依存関係はビルドと言語コンパイラであり、参照されたアセンブリをそのタイプとwhatnbotで解決できるため、すぐにコンパイルしようとしている依存アセンブリをコンパイルできます。 . 考えてみると、自分でビルドしないで、ビルドがピックアップしてコンパイルに使用する参照が他にもたくさんあります。したがって、本当の問題は、「コンパイルした依存関係が機能し、他の参照のように見える状態で自動ビルドを取得するにはどうすればよいか」ということかもしれません。

ビルドを制御できるので、DLL の配置を制御でき、ビルド順序を担当できます。そして...参照を制御できます。

残りの古典的な問題は次のとおりです。設計時に、参照が .sln プロジェクトを指している場合、ビルドしなくても外部アセンブリから型の設計時ルックアップを取得できます。プロジェクトを不可知論的に変更すると、次のようになります。コンパイルする。条件付きの.projファイルを含む多くの行に沿ってトリッキーなことを行うことができます。これは、開発者に負担をかけ、場合によっては手作業で編集して同期を維持するか、スクリプトを介して.projファイルフィルターを事前に構築して参照を修正するか、作成しますそれらを非 sln 参照にし、開発者に依存関係を構築して型を解決するように強制します。そこでは、使用する環境がビルドと一致していることを確認する必要があります。

したがって、問題は参照がどのように定義されるかに要約されます。はい、VS 自体に関係なく、MSBuild が機能するためには、MSBuild に必要なすべてのクラフトをディスクに書き込む必要があります。問題は、参照を同時に両方の方法で定義できないことであるため、毒を選択する必要があります。これは、古典的なビルド管理の問題です。あなたは一人ではありません。

于 2013-01-03T21:05:01.927 に答える