5

C# ソリューションのインストーラー プロジェクトをセットアップしていますが、依存関係の問題が発生します。

私のソリューションでは、4 つの独立したプロジェクト出力 (1 つの Windows サービスと 3 つの実行可能ファイル) があり、それらすべてがいくつかの参照を共有しています。

ソリューションを機能させるには、4 つすべてをインストールするインストーラーが必要です。

[ターゲット マシンのファイル システム] ダイアログの [アプリケーション フォルダー] の下に各プロジェクト出力のインストール フォルダーを設定し、そのフォルダーに Windows サービスのプロジェクト出力を正常に追加しました。しかし、実行可能ファイルのプロジェクト出力をフォルダーに追加しようとすると、既に Windows サービス フォルダーに運ばれているアセンブリは実行可能フォルダーに運ばれず、インストール後、実行可能ファイルは依存関係がないため実行されません。

不足しているアセンブリを実行可能ファイルのフォルダーに手動で追加できますが、これは行うべき方法ではないようで、不足しているものがあります。

何か案は?

4

2 に答える 2

1

私は最初に説明された問題だと思うものを抱えていました。Winform アプリとコンソール アプリケーションを 2 つの別々のプロジェクトとして持っていますが、1 つのセットアップ プロジェクトで両方を処理します。

Winform アプリとコンソール アプリの両方が同じ 2 つの外部アセンブリを使用します。1 つはソリューションの一部ではなく (フォルダー内のファイルへの参照)、もう 1 つは C# クラス プロジェクトから (プロジェクトへの参照)。

私が見つけたのは、インストーラーは、プロジェクトの出力がすべてインストール マシン上の 1 つのフォルダーにまとめられていると想定していることです。したがって、すべての共通アセンブリも、それらを必要とする実行可能ファイルと共存します。したがって、最初の実行可能ファイルからプロジェクト出力をフォルダーに追加すると、その依存関係がすべて表示され、2 番目のプロジェクト出力が追加されると、まだ追加されていないアセンブリのみが表示されます。

アプリケーション フォルダーの下にサブフォルダーを作成しても問題ありません。プロジェクト出力 (exe、dll、および res) に関する限り、Visual Studio はアプリケーション フォルダーを 1 つの単位として扱うように見えます。

これを解決するには 2 つの方法があります。1 つ目は、実行可能ファイルごとに個別のインストール プロジェクトを作成することです。大規模なプロジェクトでは、これは多くのセットアップ プロジェクトになる可能性があります。

すべてを 1 つのインストールに保持する場合は、共有アセンブリに GAC を使用することをお勧めします。これについては、別のスタック オーバーフロー記事で説明されています。

MSIは仕事を成し遂げることができます。[ターゲット マシンのファイル システム] を右クリックし、[追加]、[GAC] の順にクリックします。追加したフォルダーを右クリックし、[追加]、[プロジェクト出力] を選択します。これにより、アセンブリが確実に gac-ed になります。

後でアセンブリに変更や拡張を加えた場合、アセンブリは .NET レイヤーによって管理されるため、GAC は私の考えではより良いソリューションです。.NET の利点の 1 つは、Win 98 および以前のバージョンの Windows にあった古い「DLL 地獄」の問題を排除することです。一般的なコードに使用することを強くお勧めします。

于 2012-07-15T23:42:37.680 に答える