Пользовательское действие в C #, используемое через WiX, завершается с ошибкой 1154 - PullRequest
Новая
       50

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

17 голосов
/ 24 августа 2010

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

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

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

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

Что еще можно посмотреть, чтобы это работало?

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

Второе редактирование: run peverifyпротив 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" />

Ответы [ 7 ]

46 голосов
/ 25 августа 2010

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

using Microsoft.Deployment.WindowsInstaller;

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

Управляемые настраиваемые действия в Deployment Tools Foundation (DTF)

Также вы найдете справку DTF chm в меню «Пуск» под WiX.

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

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

  1. Вы ссылаетесь на правильную DLL в двоичной таблице?
  2. Вы ссылаетесь на правильное имя экспортируемой функции?
  3. Ваш класс публичный?
  4. Использует ли ваш метод правильную подпись? То есть это:
  5. Помечено с правильным атрибутом CustomAction
  6. Помечено как общедоступное?
  7. Помечен как статический?
  8. Return ActionResult?
  9. Принимать сессию в качестве аргумента?
  10. Убедитесь, что вы используете тип проекта настраиваемого действия WiX C #, чтобы событие postbuild вызывалось для создания собственной оболочки DLL. (См. № 1)

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

6 голосов
/ 10 апреля 2011

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

public ActionResult MyMethod(Session session)

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

public static ActionResult MyMethod(Session session)

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

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

5 голосов
/ 30 сентября 2010

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

4 голосов
/ 31 января 2012

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

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

2 голосов
/ 26 января 2013

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

1 голос
/ 02 октября 2013

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

0 голосов
/ 25 августа 2010

Попробуйте ввести вызов с пользовательским действием в 

<InstallExecuteSequence/>

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

...