通过 WiX 使用 C# 中的自定义操作失败并出现错误 1154

发布于 2024-09-15 11:51:10 字数 1729 浏览 4 评论 0原文

我在 Visual Studio 2010 中使用 WiX 3.5.1930,针对 .NET Framework 3.5。 (后来的 WiX 每周构建在其自定义操作模板方面似乎非常糟糕,至少现在是这样。1930 是最新的构建,似乎可以使用工作引用创建可构建的 C# CA。)

我编写了两个自定义操作程序集在 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 将其(英文)翻译为“运行此应用程序所需的库文件之一已损坏”。

第二次编辑:对 dll 运行 peverify(在安装程序运行时从 \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" />

I am using WiX 3.5.1930 in Visual Studio 2010, targeting the .NET Framework 3.5. (Later weekly builds of WiX seem to be very broken with respect to their custom action template, at least for now. 1930 is the most recent build that seems to make a buildable C# CA with working references.)

I have two custom action assemblies written in C#. One of them works fine. The other fails with the following error:

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

I have compared the .csproj files and .wixproj files, and as best I can tell the differences are appropriate (e. g. list of included .cs files). I have changed the non-working .wxs to call the working custom action instead of the non-working custom action and it works as epxected.

What else can I look at to get this working?

Edit: Just to be complete 1154 refers to an invalid DLL - net helpmsg translates it (in English) to "One of the library files needed to run this application is damaged."

Second edit: ran peverify against the dll (grabbed a copy out of \windows\installer while the installer was running) and it says everything is fine in the dll. The DLL only has the custom action method with a "return success" so there's not a lot for it to verify, but it does confirm the DLL is not corrupt.

Third edit: The code in the broken custom action follows:

using Microsoft.Deployment.WindowsInstaller;

namespace Framework.Installer.Database {
    public class CustomActions {

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

            return ActionResult.Success;
        }

    }
}

Not much to it. The relevant parts of the .wxs are as follows:

<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" />

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(8

情深已缘浅 2024-09-22 11:51:10

听起来您正在使用 DTF。如果您看到:

using Microsoft.Deployment.WindowsInstaller;

那么您肯定是。请务必阅读以下内容,了解其工作原理:

部署Tools Foundation (DTF) 管理的自定义操作

此外,您还可以在 WiX 下的开始菜单中找到 DTF 帮助 chm。

基本上,在我看来,您正在将 .NET 程序集连接到安装程序中,而不是未管理的包装器 dll 中。阅读上面的文章,了解如何在 Depends 中查看它并了解会发生什么。维克斯| C# 自定义操作项目应输出 Foo.dll 和 Foo.CA.dll。您希望安装程序中包含后者。

对于将来登陆此页面的人(答案最初是针对海报的),需要检查一整套事情:

  1. 您是否在二进制表中引用了正确的 DLL?
  2. 您是否引用了正确的导出函数名称?
  3. 你的班级是公立的吗?
  4. 您的方法使用正确的签名吗?即:
  5. 用正确的 CustomAction 属性标记
  6. 标记为公共?
  7. 标记为静态?
  8. 返回动作结果?
  9. 将 Session 作为参数?
  10. 确保您使用的是 WiX C# 自定义操作项目类型,以确保调用构建后事件来创建本机 DLL 包装器。 (参见 #1)

其中任何一项都可能导致 1154 错误。这就是我写了一篇关于该主题的综合博客文章并在此答案中链接到它的原因。充分理解托管代码如何呈现给非托管 Windows Installer 服务以及了解如何使用 Depends 来验证公共静态方法是否作为 WiX/DTF 生成的结果 .CA.dll 中的 stdcall 函数导出非常重要。

It sounds like you are using DTF. If you see:

using Microsoft.Deployment.WindowsInstaller;

then you certainly are. Be sure to read the following for how it all works:

Deployment Tools Foundation (DTF) Managed Custom Actions

Also you'll find a DTF help chm in the start menu under WiX.

Basically it sounds like to me you are wiring the .NET assembly into the installer instead of the unmanged wrapper dll. Read the above article for an overview of how to look at it in Depends and to know what to expect. The WiX | C# Custom Action project should output Foo.dll and Foo.CA.dll. You want the later in your installer.

For people who land on this page in the future (the answer was originally for the poster ) there is a whole list of things to check:

  1. Are you referencing the correct DLL in the Binary table?
  2. Are you referencing the correct exported function name?
  3. Is your class public?
  4. Is your method using the correct signature? I.e. is it:
  5. Marked with the correct CustomAction attribute
  6. Marked as public?
  7. Marked as static?
  8. Return ActionResult?
  9. Take Session as an Argument?
  10. Make sure you are using the WiX C# Custom Action Project type to ensure the postbuild event is called to create the native DLL wrapper. (See #1)

Any one of these can cause an 1154 error. This is the reason I wrote a comprehensive blog article on the subject and linked to it in this answer. It's important to fully understand how managed code is presented to the unmanaged Windows Installer service and to know how to use Depends to validate that the public static method is exported as a stdcall function in the resulting .CA.dll that WiX/DTF produces.

最单纯的乌龟 2024-09-22 11:51:10

如果您在 Visual Studio (Votive) 中创建自定义操作,请确保您创建的是 Wix Custon Action 项目而不是类库,否则您必须使用 MakeSfxCA 工具来打包您的自定义操作。

If you create your custom action in Visual Studio (Votive) be sure that you created a Wix Custon Action project and not a class library, otherwise you have to use MakeSfxCA tool to pack your custom action.

瑕疵 2024-09-22 11:51:10

我刚刚发现了同样的问题(使用正确的 .CA.dll 文件),就我而言,这是因为我没有使用静态方法。我有这个:

public ActionResult MyMethod(Session session)

而不是这个:

public static ActionResult MyMethod(Session session)

改变方法后它工作得很好。

希望它能帮助某人。

I just found the same issue (using the correct .CA.dll file) and in my case it was because I wasn't using a static method. I had this:

public ActionResult MyMethod(Session session)

Instead of this:

public static ActionResult MyMethod(Session session)

After changing the method it worked just fine.

Hope it helps someone.

樱花坊 2024-09-22 11:51:10

我偶然发现了错误 1154 的另一个非常简单(且愚蠢)的原因:在 CustomAction 元素中拼错了 DLL 条目名称...

比较其他人发现的各种原因,在我看来,错误 1154 在大多数情况下意味着“DLL 条目不存在”成立”。

I hit upon another very simple (and stupid) cause for error 1154: misspelling the DLL entry name in the CustomAction element...

Comparing various causes other people have found it seems to me that error 1154 means in most cases, "DLL entry not found".

浮生未歇 2024-09-22 11:51:10

我的回答与这个问题没有直接关系。但就我而言,我陷入了相同的错误代码 1154,因为我在同一个类中创建了另一个函数,但没有将该函数标记为 [CustomAction]

我的代码看起来像

namespace VerifyUserInfo {
    public class CustomActions {

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

            return ActionResult.Success;
        }

        public static ActionResult RegisterDevice(Session session) {

            return ActionResult.Success;
        }

    }
}

但后来我修复了在新函数上方添加了 [CustomAction] 并解决了问题

namespace VerifyUserInfo {
    public class CustomActions {

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

            return ActionResult.Success;
        }

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

            return ActionResult.Success;
        }

    }
}

My answer is not directly related to this question. But in my case, I got stuck in the same error code 1154, because I created one more function in the same class but not marked that function as [CustomAction]

My code was looking like

namespace VerifyUserInfo {
    public class CustomActions {

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

            return ActionResult.Success;
        }

        public static ActionResult RegisterDevice(Session session) {

            return ActionResult.Success;
        }

    }
}

But then I fixed with the [CustomAction] added just above the new function and issue resolved

namespace VerifyUserInfo {
    public class CustomActions {

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

            return ActionResult.Success;
        }

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

            return ActionResult.Success;
        }

    }
}
独自←快乐 2024-09-22 11:51:10

我看到此错误的另一个原因是我忘记将 [CustomAction] 属性添加到我的 c# 函数的名称中。

Another reason I saw this error was because I forgot to add the [CustomAction] attribute to the name of my c# function.

‘画卷フ 2024-09-22 11:51:10

就我而言,这是函数名称的长度。它是 27 个字符,我们收到了错误。
我们将函数名称更改为 24 个字符,并且成功了。

In my case it was the function name length. It was 27 characters, and we were getting the error.
We changed the function name to 24 characters, and it worked.

南街九尾狐 2024-09-22 11:51:10

尝试放入自定义操作调用,

<InstallExecuteSequence/>

希望获得更好的错误消息。根据操作的调用方式,我收到了不同的错误消息。另外,尝试使用fuslogvw.exe。它也可能会给你一个非常好的错误消息。

Try putting your custom action call in

<InstallExecuteSequence/>

in hopes of getting a better error message. I have received different error messages depending on how the action was called. Also, try using fuslogvw.exe. It might give you a pretty nice error message too.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文