Пользовательское действие в С#, используемое через WiX, с ошибкой 1154

Я использую WiX 3.5.1930 в Visual Studio 2010, ориентируясь на .NET Framework 3.5. (Позже еженедельные сборки WiX кажутся очень сломанными по отношению к их шаблону пользовательских действий, по крайней мере на данный момент. 1930 - это самая последняя сборка, которая, похоже, создает встроенный С# CA с рабочими ссылками.)

У меня есть две сборки пользовательских действий, написанные на С#. Один из них отлично работает. Другая ошибка со следующей ошибкой:

CustomActionnNameHere returned actual error code 1154 (note this may not be 100% accurate if translation happened inside sandbox)

Я сравнил файлы .csproj и .wixproj, и насколько я могу сказать, что различия являются подходящими (например, список включенных файлов .cs). Я изменил неработающие .wxs для вызова рабочего пользовательского действия вместо неработающего пользовательского действия, и он работает как epxected.

Что еще я могу посмотреть, чтобы заставить это работать?

Изменить: просто для того, чтобы быть полным 1154 относится к недопустимой DLL - net helpms переводит его (на английском языке) на "Один из файлов библиотеки, необходимых для запуска этого приложения, поврежден".

Второе редактирование: выполнялось перевернутое против dll (захватили копию из \windows\installer во время работы установщика), и он говорит, что все в порядке в dll. DLL имеет только пользовательский метод действий с "успешным возвратом", поэтому нет возможности проверить его, но он подтверждает, что DLL не повреждена.

Третье редактирование: Код в сломанном пользовательском действии следует:

using Microsoft.Deployment.WindowsInstaller;

namespace Framework.Installer.Database {
    public class CustomActions {

        [CustomAction]
        public static ActionResult RunMigration(Session session) {

            return ActionResult.Success;
        }

    }
}

Не так много. Соответствующие части .wxs выглядят следующим образом:

<InstallExecuteSequence>
  <Custom Action="DotNetMigratorCustomActionPreviousUp" After="SetMigrationPropertiesPreviousUp"><![CDATA[(&Database = 3)]]></Custom>
</InstallExecuteSequence>

<Binary Id="DotNetMigratorCustomActionDll"
        SourceFile="$(var.Framework.Installer.Database.CustomActions.TargetDir)\SoftwareAnswers.Framework.Installer.Database.CustomActions.dll" />

<CustomAction Id="DotNetMigratorCustomActionPreviousUp"
              Return="check"
              BinaryKey="DotNetMigratorCustomActionDll"
              DllEntry="RunMigration"
              Execute="deferred" />

Ответ 1

Похоже, вы используете DTF. Если вы видите:

using Microsoft.Deployment.WindowsInstaller;

то вы, безусловно, знаете. Обязательно прочтите следующие сведения о том, как все это работает:

Управляемые пользовательские действия с инструментами развертывания (DTF)

Также вы найдете справочную команду DTF в стартовом меню в разделе WiX.

В основном мне кажется, что вы подключаете сборку .NET в установщик вместо dll без изменений. Прочитайте вышеприведенную статью для обзора того, как ее посмотреть в зависимости от того, как ее искать и знать, чего ожидать. WiX | Проект С# Custom Action должен выводить Foo.dll и Foo.CA.dll. Вы хотите позже в своем установщике.

Для людей, которые приземляются на этой странице в будущем (ответ был первоначально для плаката), есть целый список вещей, которые нужно проверить:

Вы ссылаетесь на правильную DLL в двоичной таблице?
Вы ссылаетесь на правильное имя экспортируемой функции?
Является ли ваш класс общедоступным?
Используется ли ваш метод с использованием правильной подписи? То есть это:
Отмечено с правильным атрибутом CustomAction
Отмечено как общедоступное?
Отмечено как статический?
Возврат ActionResult?
Возьмите сеанс как аргумент?
Убедитесь, что вы используете тип проекта WiX С# Custom Action, чтобы гарантировать, что событие postbuild вызывается для создания собственной DLL-оболочки. (См. № 1).

Любой из них может вызвать ошибку 1154. Именно по этой причине я написал всеобъемлющую статью в блоге по этому вопросу и связан с ней в этом ответе. Важно полностью понять, как управляемый код представлен неуправляемой службе установщика Windows и знать, как использовать Depends для проверки того, что публичный статический метод экспортируется как функция stdcall в полученной в результате .CA.dll, которую производит WiX/DTF.

Ответ 2

Я только что нашел ту же проблему (, используя правильный файл .CA.dll), и в моем случае это было потому, что я не использовал статический метод. У меня было это:

public ActionResult MyMethod(Session session)

Вместо этого:

public static ActionResult MyMethod(Session session)

После изменения метода он работал нормально.

Надеюсь, что это поможет кому-то.

Ответ 3

Если вы создаете свое собственное действие в Visual Studio (Votive), убедитесь, что вы создали проект Wix Custon Action, а не библиотеку классов, иначе вам придется использовать инструмент MakeSfxCA для упаковки вашего пользовательского действия.

Ответ 4

Я натолкнулся на еще одну очень простую (и глупую) причину ошибки 1154: ошибка написания имени записи DLL в элементе CustomAction...

Сравнивая различные причины, которые обнаружили другие люди, мне кажется, что ошибка 1154 в большинстве случаев означает "запись в DLL не найдена".

Ответ 5

Другая причина, по которой я видел эту ошибку, заключалась в том, что я забыл добавить атрибут [CustomAction] к имени моей функции С#.

Ответ 6

Попробуйте ввести свой вызов в

<InstallExecuteSequence/>

в надежде получить лучшее сообщение об ошибке. Я получил разные сообщения об ошибках в зависимости от того, как было вызвано действие. Кроме того, попробуйте использовать fuslogvw.exe. Это может дать вам довольно приятное сообщение об ошибке.

Ответ 7

В моем случае это была длина имени функции. Это было 27 символов, и мы получили ошибку. Мы изменили имя функции на 24 символа, и она сработала.