12

いくつかの Windows サービスのインストーラーをビルドする VS2008 展開プロジェクトがあります。

各サービスは、いくつかの異なるプロジェクトを参照します。

CustomerName.MailSendingService
 -> CustomerName.Network
 -> CustomerName.Data
 -> 顧客名.セキュリティ

CustomerName.ProductIntegrationService
 -> CustomerName.Core
 -> 顧客名.セキュリティ

Windows サービス プロジェクト、それらが参照するプロジェクト、および展開プロジェクトはすべて、同じ VS2008 ソリューションにあります。

展開プロジェクトのファイル システム エディターで、Windows サービス プロジェクトからのプライマリ出力を追加しました。

Windows サービス プロジェクトの主要な出力には、参照されているプロジェクトからの DLL が含まれることを期待しています。ただし、展開プロジェクトがビルドされると、参照されているプロジェクトの 1 つからの DLL が見つかりません。（CustomerName.ProductIntegrationService欠落していCustomerName.Securityます）

驚くべきことに、Windows サービスによって参照される他のプロジェクトの DLL が存在します。1 つのプロジェクトの出力だけが欠落しています。

(編集) 参照プロパティ ウィンドウで、参照が [ローカルにコピー] に設定されていることを確認しました。参照プロジェクトの DLL は Windows サービス プロジェクトのbin\Releaseフォルダーに配置されますが、展開プロジェクト用にビルドされた MSI ファイルにはパッケージ化されません。

(編集 2) Joseph Daigle の提案に従って、依存関係がプライマリ出力の依存関係リストにあり、「除外」とマークされていないことを確認したため、この問題の原因ではないようです。

1 つのプロジェクトの出力だけが失われるのはなぜですか?

4

8 に答える 8

5

同じ疑わしい msi 欠陥を再現した後、追加することがいくつかあります。

1) 検出された同じ依存関係を共有する 2 番目のプロジェクト出力をインストーラーに追加すると、依存関係が自動的に追加されませんでした。両方のプロジェクト出力を削除し、逆の順序で追加し直しました。追加された 2 番目のプロジェクト出力は、検出された依存関係を追加しませんでした。これにより、プロジェクトの構成またはコードの問題、および参照の追加方法が除外されます。失敗するのは常に2番目のものです。

2) 私のチームは、「検出されたアセンブリを手動で追加する」回避策を使用した後、実際に 2 番目の問題に遭遇しました。最初に、'\Program Files\xxx' の場所から依存関係を追加しましたが、64 ビット マシンで同じ依存関係が '\Program Files (x86)\xxx' フォルダーにあるビルドの問題に遭遇しました。参照をピックアップするときにこの問題を処理します。

  • アセンブリを手動で追加する適切な方法は、bin フォルダーに移動し、ローカルにコピーされたアセンブリを追加することです。これにより、正しいアセンブリが x86 または x64 マシンに存在することが保証されます。
于 2010-07-06T19:35:22.580 に答える
3

これが私たちにとっても問題であることを確認できます。展開プロジェクトのバグだと思います-依存プロジェクトの出力を1つの場所に追加するだけです（おそらくCOM dllだと思いますか？）

欠落している dll のプライマリ出力を手動で追加することは、実行可能な回避策のようです。

于 2009-03-09T03:08:40.977 に答える
0

Visual Studio 2008はまだ使用していませんが、2005年に、プロジェクトで欠落している参照のCopyLocalプロパティがtrueに設定されていることを確認する必要があります。

これにより、欠落しているファイルが出力ディレクトリにコピーされます。

于 2008-09-25T17:37:02.097 に答える
0

Microsoft SMO オブジェクトの使用に関して同様の問題がありました。自分で作成したこれらの Microsoft SMO オブジェクトを使用するバイナリ コンポーネント (X.dll) があります。X.dll をコンパイルした後、X.dll (コードではなく) を使用して別の EXE プロジェクトで参照します。添付されたインストーラー プロジェクトは、Microsoft SMO オブジェクトが必要であることを検出し、それらがマシン上の SQL Server インストールに対してローカルであることを検出します。

SMO オブジェクトを使用するコンポーネント X.dll は、共有ドライブに保持しているローカルの「Externals」フォルダを介して Microsoft SMO オブジェクトを参照します。すべてのモジュールはそれらを参照してコンパイルされますが、EXE プロジェクトを含む私のインストール プロジェクトは、SQL Server インストールからのものを検出します。

このため、SMO オブジェクトを含む「Externals」フォルダを持つ別のマシンがありますが、SMO オブジェクトが externals モジュールにあることに気付いていないため、インストール プロジェクトは「検出された依存関係」から SMO オブジェクトを見つけることができません! 検出された依存関係ファイルを検索する場所はわかりませんが、X.dll が最初にそれらを取得した場所や、おそらく EXE フォルダーも調べていません...

于 2011-02-02T09:03:26.370 に答える
0

最初に展開プロジェクトを作成した後で、このアセンブリ依存関係を追加しましたか? その場合は、[検出された依存関係] フォルダーを右クリックし、[依存関係の更新] を選択する必要がある場合があります。前回これを行った後に追加された新しいものはすべて取得されます。

于 2008-11-21T19:24:01.080 に答える
0

hectorsqの応答に加えて、依存関係が展開プロジェクトの依存関係リストにあること、および問題の DLL が含まれるようにマークされていることを確認します。

于 2008-09-25T17:44:33.513 に答える
0

リフレクターで dll を調べて、実際に他の dll に依存しているかどうかを確認してみましたか? VS は、実際にそれを使用していないことがわかる場合、参照されたアセンブリを含めないほどスマートです。

それに加えて、たとえあなたがそれを使っていると思っていても、VS はあなたの使用を最適化することができます - これは限界のケースですが、私はそれを見てきました:

たとえば、これを含む「定数」アセンブリがある場合:

public const string LockPanelUrn = "ApplicationRack.LockPanel";

VS は、文字列を参照コードに直接貼り付けます。

それ以上に、インストール ソリューションを削除して再構築することをお勧めします。

于 2008-09-30T08:55:28.163 に答える
0

これをチェックしてください-おそらくこれはその理由を説明していませんが、少なくともいくつかの回避策を提供します:)

http://lo-sharpdevs.blogspot.com/2009/07/vs-2008-disappearing-dependencies.html

于 2009-07-03T00:34:48.883 に答える