バイナリテーブルから実行されるマネージドEXEカスタムアクションを使用した基本的なMSIInstallShieldインストールがあります。コンソールを実行するだけで正常に動作する簡単なテストを試しました。.DLLアセンブリ参照をEXEに追加すると、DLLが見つかりません。InstallShieldにこの参照されたアセンブリを認識させてEXEでロードできるようにするにはどうすればよいですか?
4 に答える
カスタムアクションは、一時的な名前で一時的な場所に1つのファイルのみを抽出します。.dllへの依存関係が機能するには、両方を抽出する必要があり、少なくとも.dllには予期された名前が付いている必要があります。通常、これは「セットアップファイル」に追加することと[SUPPORTDIR]\your.exe
カスタムアクションを参照することの両方で行うのが最も簡単です。
さて、今日の仕組みについて、Installshield2014の詳細を追加します。他の回答は、他のinstallshieldバージョンと同じように正しい可能性があります。マイケルの答えは2012年からのものであり、それ以来多くが変わっていることがわかります。どれどれ。
.Netアセンブリには、次の2種類の依存関係があります。
- 管理対象(C#またはVB.Net言語で記述されています。OPにはこの特定のケースがあります)
- 管理されていないまたはネイティブ(たとえば、p/invokeを介して呼び出されるC++dll)。C#プロジェクトでこのようなアセンブリを参照することはありませんが、
DllImport
属性と明確に定義されたアセンブリ検索メカニズムを使用して実行時に読み込まれます。
管理されたアセンブリへの依存の場合であるOPの問題を理解しましょう:
installshieldが内部に独自のデータベースを持っているというすべての人の情報のために。したがって、マネージアセンブリに存在するメソッドを呼び出すカスタムアクションを(installshield基本MSIプロジェクトに)追加すると、以下に示すように、カスタムアクションのすべての属性がISClrWrap
内部データベースのテーブルにレコードとして配置されます。
現在、installshieldは、管理対象アセンブリ(Visual StudioのC#プロジェクトで参照として追加したもの)の依存関係を定義できるユーザーインターフェイスや直接メカニズムを提供していません。ただし、同じことを反映するようにこのデータベーステーブルを更新できます。このテーブルの新しい依存関係ごとに1つのレコードを追加する必要があります。Dependency0
名前列には、最初の依存関係、 2番目の依存関係などを選択する必要がありますDependency1
。新しいレコードを追加するために上部の新しいボタンを押した後、私がどのようにそれを行ったかについて、以下のスナップショットを見てください。
管理対象の依存関係アセンブリをすべて追加すると、テーブルは次のようになります。
それでおしまい。ここから完了です。残りはinstallshieldに任せてください。これで、に存在するメソッドは、インストールプロセス中またはインストールプロセス中にMyManagedAssembly.dll
存在するメソッドを呼び出すことができるようになります。MyManagedDependencyAssembly1.dll
MyManagedDependencyAssembly2.dll
注:
- 管理対象の依存関係アセンブリをサポートファイル(パスはプロパティで表され
[SUPPORTDIR]
ます)に追加する必要はありません。installshieldがインストールプロセス中に管理対象依存関係アセンブリのコピーを管理する方法は、その内部実装の詳細です。 System.dll
.NET Framework FCLなどの一部であるコア.NETアセンブリへのC#プロジェクト(カスタムアクションで使用)の依存関係をSysten.Core.dll
このテーブルに追加する必要はありません。InstallShieldがCLRをロードしてマネージコードを実行すると、デフォルトでロードされます。
自分がやろうとしていたことを実行できる.Netカスタムアクションを使用するための適切な方法を見つけることができませんでした。最終的にWiXのDTF(Deployment Tools Foundation)セクションを使用してアセンブリを作成しましたが、うまく機能しました。
'isclrwrap'バイナリテーブルに依存関係としてDLLを追加してください。そのバイナリテーブルは、ダイレクトエディタから見つけることができます。これはあなたの問題を解決します。