InstallShield CustomAction : How to load the managed dependency assemblies

后端 未结 4 1437
春和景丽
春和景丽 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: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.

提交回复
热议问题