InstallShield CustomAction : How to load the managed dependency assemblies

后端 未结 4 1429
春和景丽
春和景丽 2020-12-21 02:51

I have a basic MSI InstallShield installation with a managed EXE custom action running from the Binary table. I tried a simple test that just runs a console and that works

相关标签:
4条回答
  • 2020-12-21 03:18

    Please add your DLL as a dependency in 'isclrwrap' binary table. You can find that binary table from direct editor. This will solve your problem.

    0 讨论(0)
  • 2020-12-21 03:21

    Custom Actions only extract a single file to a temporary location under a temporary name. For the dependency on the .dll to work, they need to both be extracted, and at least the .dll must have the expected name. Typically this is easiest to do by adding both to "setup files" and referencing [SUPPORTDIR]\your.exe for the custom action.

    0 讨论(0)
  • 2020-12-21 03:30

    Well, I'll add the details w.r.t. Installshield 2014 on how it works today. Other answers can be equally correct w.r.t. other installshield versions. I can see that Michael's answer is from year 2012 and lot has changed since then. Let's see.

    There can be two types of dependencies for your .Net assembly:

    1. Managed (written in C# or VB.Net language. OP has this particular case)
    2. Unamanaged or Native (e.g. C++ dlls called through p/invoke). You do not reference such assemblies in your C# project but they are loaded at run-time using DllImport attribtue and a well-defined assembly searching mechanism.

    Let's understand OP's problem which is the case of dependency on managed assemblies:

    Just for everyone's information that installshield internally has a database of its own. So, when ever you add a custom action (in your installshield basic MSI project) which calls a method present in a managed assembly then all the attributes of the custom actions are put as records in the ISClrWrap table of internal database as shown below:

    Now installshield doesn't provide any user interface or direct mechanism where we can define the dependencies of your managed assemblies (the ones you added as reference in your C# project in Visual Studio). But you can update this database table to reflect the same. You need to add one record for every new dependency in this table. For name column you should choose Dependency0 for the first dependency, Dependency1 for the second dependency and so on. Have a look at the snapshot below on how I've done it after pressing new button at the top for adding a new record:

    After you have added all your managed dependency assemblies the table starts looking like this:

    That's it. You are done from here. Leave the rest to installshield. Now methods present in MyManagedAssembly.dll will be able to call methods present in MyManagedDependencyAssembly1.dll or MyManagedDependencyAssembly2.dllduring the installation process.

    Notes:

    1. You do not have to add the managed dependency assemblies into Support Files(whose path is represented by [SUPPORTDIR] property). How installshield manages the copying of managed dependency assemblies during the installation process is its internal implementation detail.
    2. The dependencies of your C# project (used in custom action) on core .NET assemblies which are part of .NET framework FCL e.g. System.dll, Systen.Core.dll etc. need not be added into this table. They are loaded by default when InstallShield loads CLR to execute your managed code.
    0 讨论(0)
  • 2020-12-21 03:31

    I couldn't find a decent way to use .Net custom actions that allowed me to do what I was trying to do. I ended up using the DTF (Deployment Tools Foundation) section of WiX to create the assembly and it worked great.

    0 讨论(0)
提交回复
热议问题