2

NUnit はマシンの "C:\Program Files\NUnit 2.4.8\" にインストールされていますが、統合サーバー (CruiseControl.Net を実行) では "D:\Program Files\NUnit 2.4.8\" にインストールされています。 . 問題は、タスクでパス「C:\Program Files\NUnit 2.4.8\bin\NUnit.Framework.dll」を使用して「 NUnit.Framework.dll' アセンブリですが、この同じビルド ファイルは統合サーバーでファイルをビルドできません (参照パスが異なるため)。統合サーバーと同じ場所に NUnit をインストールする必要がありますか? この解決策は私には制限が多すぎるようです。もっと良いものはありますか？この種の問題の一般的な解決策は何ですか?

4

6 に答える 6

4

通常、NUnit とその他の依存関係をプロジェクトと共に、共通の場所 (私にとっては最上位のlibsディレクトリ) に配布します。

/MyApp
  /libs
    /NUnit
    /NAnt
    /etc...
  /src
    /etc...

次に、アプリケーションからこれらのライブラリを参照するだけで、それらはプロジェクト ソリューションに対して常に同じ場所にあります。

于 2008-12-23T14:17:34.503 に答える
1

一般に、絶対パスへの依存は避ける必要があります。CI に関する限り、自動化されたスクリプトを介してソース コード管理で見つかったリソースのみを使用して、クリーンなマシン上でソリューションを完全にゼロから構築および実行できるはずです。

于 2008-12-23T14:19:24.110 に答える
1

「究極の」解決策は、ツールチェーン全体をソース管理に保存し、ビルドしたライブラリ/バイナリもソース管理に保存することです。正しくセットアップすると、出荷時とまったく同じように、任意の時点から任意のリリースを再構築できますが、さらに、これまでに生成したすべてのバイナリがソース管理されています。

ただし、そこにたどり着くのは大変な作業です。

于 2008-12-23T14:21:29.270 に答える
0

絶対パスが悪であることに同意します。それらを回避できない場合は、少なくともスクリプト内で NUNIT_HOME プロパティをデフォルトで C:... に設定し、CI サーバーでコマンド ラインで NUNIT_HOME プロパティを渡してスクリプトを呼び出すことができます。

または、NUNIT が機能するために NUNIT_HOME 環境変数の設定を要求するようにスクリプトを設定することもできます。ここで、実行するマシンの正確な場所に nUnit があることを要求する代わりに、スクリプトは nunit が存在し、環境変数で使用できることを要求します。

どちらの方法でも、ビルド スクリプトを変更せずに、使用している nunit のバージョンを変更できます。

于 2008-12-23T14:58:33.563 に答える
0

私は2つのアプローチを使用します：

1) 2 つの異なるステージング スクリプト (開発ビルド/統合ビルド) を異なるパスで使用します。

2) 必要なすべての実行可能ファイルをパス フォルダーに配置し、それらを直接呼び出します。

于 2008-12-23T14:18:09.137 に答える
0

ツール チェーン内のすべてのツールをバージョン管理下に置くというアイデアは、優れたアイデアです。しかし、そこにいる間に、いくつかの異なる手法を使用して、マシンごとに異なるパスを指定できます。

NAntでオーバーライドできるを定義し<property>ましょう-Dname=value。これを使用して、CI システムでオーバーライドする開発マシンのデフォルトの場所を設定できます。

を使用して環境変数の値を取得しenvironment::get-variable、マシンごとに場所を変更することもできます。

于 2008-12-23T15:31:59.533 に答える