0

基本MSI(installshield 2014)で新しいカスタムアクションを作成しています。プロジェクト。私は、管理された.Netアセンブリでパブリックメソッドを呼び出す必要があります。これは、製品配備の一部として展開されます。 abc.dllは、セットアップデザインのfeature1フィーチャーの一部であるcomponent1という名前のコンポーネントの一部です。.netクラスライブラリのdllファイル(.exeファイルの製品展開と依存関係の一部)がカスタムアクションから参照できません

カスタムアクション作成ウィザードでそのアセンブリを参照しようとすると、そのLocationInstalled with the productとなります。しかし、カスタムアクションの作成ウィザードでAction Parametersステップに私は、私はそれを見ていない展開パスでabc.dllを閲覧しようとすると:

enter image description here

でそれを閲覧している間、私はabc.dllを見ることができるよが、以下のスナップショットに示すようにabc.dllは、製品の%programfiles%に展開されるcomponent1の一部として存在します。一方

enter image description here

以下のスナップショットに示したように、私はカスタムアクションの作成ウィザードで(別のコンポーネントcomponent2の一部としてデプロイされる)pqr.exeファイルを見ることができます:

enter image description here

これはなぜ起こっているのかもしれないのですか?

答えて

0

最後に私の解決策に問題がありました。それは、InstallShieldが.Netアセンブリのパッケージングとその依存関係をどのように扱うかにまで及ぶ。

あなたは、例えば、メインプロジェクト出力を追加するたびに:.NETのexeファイルとその依存関係はInstallshieldのによって参照される方法間の

違い私の場合はpqr.exeになり、コンポーネントに追加されます。コンポーネントを参照すると、installshield環境の標準的な既知の変数の観点から、Link To列のexeのソースパスが表示されます。 [InstallDir]\ComponentName\など

これで、installshieldで.Netアセンブリを配備するためのMSIパッケージを作成する必要がある場合。私のケースではpqr.exeも、デプロイメントのために依存関係をパッケージ化しようとしています。私の場合、prq.exeabc.dllに依存していました。しかし、注意点は、installshieldは.Netアセンブリの依存関係のリストを静的にそれ自身の*.ISMインストーラプロジェクトファイルの中に保持しないということです。

したがって、abc.dllもコンポーネントに表示されていましたが、そのパスはISMファイルが構築されていたディスク上の完全修飾パスとなります。 D:\mywork\MSIProject\。これは、abc.dllが実際にISM insatallerプロジェクトファイルの一部ではないためです。実際、ISMファイルのxml形式をテキストエディタで開き、abc.dllを検索しようとしましたが、それはまったくありませんでした。したがって、abc.dllは、ISMインストーラ定義ファイル内に展開するアセンブリとして存在しません。しかし、ISMファイルを作成する間だけ、すべての依存関係を* .exeファイルと共にパッケージ化しようとします。

すべての依存関係は、* .exeファイルが存在するのと同じルートディレクトリに存在する必要があります。そうしなければ、installshieldはそれらをパッケージ化できません。純exeファイルとその依存関係は、InstallShieldのでパッケージされているかとの

違い:

違いのもう一つのポイントに注意することは、ディスク・パスからpqr.exeを削除する場合ISMファイルは、その後ISMファイルを構築してきているところということですビルドに失敗しますが、abc.dll(ISM定義ファイルの物理的な部分ではないため参照/依存関係のみ)を削除すると、ISMファイルは正常に構築されます。あなたが一部で、カスタムアクションでのみのアセンブリを参照することができます限り、私の実際の問題が行くよう

、:どのように純exeファイルとその依存関係は、InstallShieldのでカスタムアクションで参照されている間

違い直接的な方法でコンポーネントの論理的にはコンポーネントの一部のようにしか見えない(依存関係のような)アセンブリを参照することはできませんが、管理された.Net EXEファイルの依存関係であるため現実にそこに表示されます。

0

InstallShieldは、これらのバイナリをカスタムアクションとして呼び出すことができると検証しています。実行可能ファイルはカスタムアクションとして実行できるので、それが表示されます。 Dllは、必要な署名を持つエントリポイントをエクスポートしない限り、任意に呼び出すことはできません。おそらくInstallShieldはVisual Studioインストーラプロジェクトを呼び出すためにC++シムを呼び出すようになっています。それ以外の場合はC++のDLLは、この署名を持っている必要があります:

UINT__stdcall CustomActionEntryPoint(MSIHANDLE hInstall)ここ

例:

https://www.simple-talk.com/dotnet/visual-studio/visual-studio-setup-projects-and-custom-actions/

https://www.codeproject.com/Articles/570751/DevMSI-An-Example-Cplusplus-MSI-Wix-Deferred-Custo

そして、私はIS月のバージョン、言ったようにDllを呼び出すための他の記述の下でマネージコードDllを呼び出すことをサポートしています(「標準のWindows Installerカスタムアクトn ")。

+0

いくつかのパブリックメソッドを持つシンプルなC#dllファイルを作成し、それをディスクに置いてカスタムアクションで参照することは可能です。 dllはバイナリテーブルに格納され、カスタムアクションを使用できます。私がここで言及しているdllは、単純なクラスライブラリプロジェクト( 'main'メソッドを持たない)です。では、バイナリテーブルに格納されたdllファイルは、%programfiles%ディレクトリにインストールされているコンポーネントの一部であるdllとどう違うのでしょうか。私は管理されたdllファイル( 'main'メソッドを持たない)に存在するパブリックメソッドを、デプロイされたコンポーネントの一部であっても呼び出すことができます。私はここに何かを逃していますか – RBT

+0

Visual Studioにあるように、Managed Codeカスタムアクションへの呼び出しをラップするためのInstallShieldのサポートがあるかもしれませんが、マネージコードCAを直接呼び出すネイティブサポートはありません。そのため、たとえば、http://www.advancedinstaller.com/user-guide/qa-c-sharp-ca.htmlとhttps://www.firegiant.com/wix/tutorial/を呼び出すためのDTFがありますイベントとアクション/管理方法/ – PhilDW

+0

私は私の質問にもっと明確に加え、私が自分の問題を解決できる答えを加えました。それは、instatallshieldが.Net exeとその依存関係を構成要素の一部として構築する際に、異なった方法でそれを管理する方法に関係していました。 – RBT

関連する問題