应用程序是否依赖于编译环境? [英] Are applications dependent on the environment where it was compiled?

问题描述

我们的MSI安装程序中有一个System.BadImageFormatException.我已经阅读了有关目标框架的信息，但是我们已经检查过了，它的目标是正确的框架(与我们的质量检查机器相同.NET Framework 4.5.)

We are having a System.BadImageFormatException in our MSI installers. I have already read about the target frameworks, but we already checked and it's targeting the correct framework (.NET Framework 4.5 same with our QA machines).

我们具有完全相同的源代码，但是由构建团队"编译的msi安装程序的结果失败，但是由我们"dev"编译的msi安装程序有效.问题是，构建和编译应用程序的环境是否会影响输出(例如:msi安装程序)?

We have exactly the same source codes, but the results of the msi installer compiled by our 'build team' fails, but the msi installer compiled by us 'dev' works. Question is, does the environment where an application was built and compiled affects the output (example: msi installers)?

推荐答案

一些建议的调试步骤

是触发这些错误的是真正的MSI文件，还是安装后触发了应用程序?

Some Suggested Debugging Steps

So it is the actual MSI file which triggers these errors, or the application after installation?

以下是尝试调试此类问题(无特定顺序)时要考虑的一些想法和问题. 我的赌注在第一个列表中的第3个问题上:

Below are some thoughts and questions to consider when trying to debug issues such as these (in no particular order). My bet is on issue 3 in this first list:

1. 在运行 MSI本身(或者是setup.exe?)时，还是在尝试启动应用程序后，是否会发生此异常?安装?只是为了验证-我假设是MSI.

1. Does this exception occur as you run the MSI itself (or is it a setup.exe?), or as you try to launch the application after installation? Just to verify - I assume the MSI.

设置中是否有自定义操作?如果您在MSI中具有托管代码自定义操作，那么您在构建中要针对哪些平台? Any CPU我想吗?请验证.我认为这里的COM-interop存在一些问题，但是我对此细节感到困惑.有时您可能必须选择特定的平台.在这种情况下，您会收到此类错误消息(错误图像). 有关托管代码和部署的完整内容"，请参见下面的"托管代码"部分，以及可能导致的一些问题.

Do you have custom actions in the setup? If you have managed code custom actions in your MSI, what platforms do you target in your build? Any CPU I would presume? Please verify. I think there are some issues with COM-interop here, but I am fuzzy on the details. Sometimes you may have to pick a specific platform. In this case you can get such error messages (bad image). See section "Managed Code" below for a whole "rant" about managed code and deployment - and some problems that may result.

无论如何，在您的WiX源文件中，Product element中Platform attribute的值是什么?可能的值:x86，x64，intel64，intel，arm，ia64.请报告(并尝试使用其他值进行测试-例如x86，x64).这会影响MSI的平台设置.如果不使用WiX，请打开已编译的MSI文件，并检查摘要流中的Platform设置.使用Orca，这是View => Summary Information...-查找Platform.

Regardless of the above, in your WiX source file, what is the value of the Platform attribute in the Product element? Possible values: x86, x64, intel64, intel, arm, ia64. Please report (and try to test with other values as well - x86, x64 for example). This affects the MSI's platform setting. If you don't use WiX - open the compiled MSI file, and check the summary stream for the Platform setting. Using Orca this is View => Summary Information... - look for Platform.

您是否有用于MSI编译和/或安装在生成计算机上的任何恶意软件扫描程序，安全软件或其他潜在阻止程序"?还是在您尝试安装的测试系统上? (我们必须经常提到这些问题-即使我们不这样做，人们也会浪费几天的时间-即使它似乎很少是唯一的问题.)

Do you have any malware scanners, security software or other "potential blockers" for MSI compilation and / or installation on your build computer? Or on the test system where you try to install? (We must always mention these issues - people can waste days if we don't - even if it rarely seems to be the only issue).

这是使用亚洲字符的本地化MSI 吗? (或阿拉伯语，或其他复杂字符集?).我刚刚提到了这一点-坦率地说，我看不到它与100％的相关性，但是我想针对您的情况澄清这个变量"(即我们可以消除它作为潜在的错误源).我相信这通常会导致运行时错误，而不是System.BadImageFormatException问题.

Is this a localized MSI using Asian characters? (or Arabic, or any other complex character sets?). This I just mention - frankly I don't see how this is 100% relevant, but I want to clarify this "variable" for your scenario (i.e can we eliminate this as a potential error source). It would generally cause runtime errors, not System.BadImageFormatException issues - I believe.

我认为不同的MSI文件的比较可能不起作用，因为其中一个文件是"错误的图像"?你试过了吗?也许它仍然是有效的COM结构化存储文件-但是msiexec.exe引擎无法处理它?如果是这样，那么工具也许可以很好地读取文件中的内容-我不知道，请尝试一下.

I assume a compare of the different MSI files may not work because one of the files is a "bad image"? Did you try? Maybe it is still a valid COM structured storage file - but the msiexec.exe engine can't handle it? If it is, then tools may be able to read the content inside the file just fine - I don't know, give it a try.

• 针对您的情况:我最初认为，一个经过编译的MSI在不同位置(环境)的行为会有所不同-因此建议检查是否有任何运输途中的损坏(网络问题，samba问题，存储问题，恶意软件问题等)，方法是对不同位置的副本执行 binary diff (二进制比较)(位级别比较).由于您似乎从相同的来源编译了两个(或多个)MSI文件，因此这种二进制比较显然是没有意义的.差异是肯定的.

• For your scenario: I initially thought a single, compiled MSI behaved differently in different locations (environments) - and hence suggested to check for any damage in transit (network issues, samba issues, storage issues, malware issue, etc...) by doing a binary diff on the copies in the different locations (bit-level comparison). Since you seem to compile two (or more) MSI files from the same sources, such a binary compare is obviously meaningless. Differences are certain.

但是，"内容比较"可能会告诉您一些信息-这会比较MSI内部表/流中的实际内容.我想我将添加有关如何比较可从此处链接到的MSI文件的Q/A(添加:

However, a "content compare" could tell you something - this compares actual content in the tables / streams inside the MSIs. I think I will add a Q/A on how to compare MSI files that I can link to from here (added: How can I compare the content of two (or more) MSI files?). This presumes that the MSI is readable - even if it is not runnable. Only way to know is to try.

我希望并相信上面的列表应该可以帮助您解决问题.

I hope and believe that the above list should help you sort out your problem.

我在下面关于管理代码问题的悬崖上写下自己.这个想法是要描述几个要检查的问题，但这引起了漫长的讨论.我可能会删除下面的所有内容，并可能在其他地方将其复活.它可能与您完全无关.整个主题是托管代码，以及托管代码如何以新的和有趣的"方式崩溃:

I wrote myself off a cliff below on the subject of managed code issues. The idea was to describe a couple of issues to check, but it became a long discussion. I may delete all the stuff below and perhaps resurrect it elsewhere. It may not be relevant for you at all. The overall topic is managed code and how it can crash in new and "interesting" ways:

这是一发不可收拾的答案之一.一世 认为它仍然有价值，把它留在里面.

This is another one of those sprawling answers that got out of hand. I think it still has value, leaving it in.

关于 .NET自定义操作(托管代码)的其他两个问题.我不是这个问题的专家，因为我像瘟疫一样避开了他们(目前-这可能会随着时间而改变).

A couple of further issues with regards to .NET custom actions (managed code). I am far from an expert on this topic, since I shun them like the plague (for now - this may change over time).

出于您的目的，其中有些话题偏离了主题-但我将其保留为MSI使用托管代码的一般注释.

Some of this veered quite a bit off topic - for your purpose - but I will leave it in as general comments on managed code for MSI use.

MSI专家 Chris Painter 就是这个话题的人-他承担了这个潜在的痛苦世界"，并且似乎也从此类自定义操作中受益，但是这些由管理的自定义操作似乎通常被认为是有问题的-如果您以幼稚的方式对待它们.务实，权衡好处，以应对下面列出的潜在问题.

MSI expert Chris Painter is the man for this topic - he has taken on this potential "world of pain" and seem to benefit from such custom actions too, but these managed custom actions seem generally accepted to be problematic - if you approach them in a naive way. Be pragmatic and weigh benefits against potential problems listed below.

一条友好的建议:对于全球范围的发行，到目前为止，我永远不会使用托管代码-尽管它变得越来越安全"-我们必须承认这一点.使用此类自定义操作的大规模分发MSI软件包存在太多潜在的错误源(家庭用户可能会卸载.NET，企业用户可能会看到.NET版本被禁用，以及下面的全部问题，我担心赶上22 卸载问题比什么都重要-下文对此有完整说明，等等.)

A friendly piece of advice: for worldwide distribution I would never use managed code as of now - though it is "getting safer" - we have to admit that. There are too many potential error sources for a large scale distribution MSI package using such custom actions (home users may uninstall .NET, corporate users may see versions of .NET disabled, and the whole list of problems below, and I fear "catch 22" uninstall problems more than anything - a whole section on this below, etc...).

正如我所说，我不是专家，但是存在很多严重问题.如果现在分类"，克里斯也许可以纠正我. DTF框架(与WiX一起分发)具有支持将托管代码自定义操作dll嵌入常规Win32 DLL包装器中的功能.这有助于提高可靠性. 我将在此处挖掘一些链接以供参考.克里斯一直是这里的先驱和早期采用者.

As I said, I am not an expert, but there are many, and serious problems. Maybe Chris can correct me if they are "sorted" by now. The DTF framework (distributed along with WiX) features support for embedding a managed code custom action dll inside a regular win32 dll wrapper. This helps reliability. I will dig up a few links here for reference. Chris has been a pioneer and early-adopter here.

用于自定义操作的部分托管代码问题:

Partial list of managed code problems for custom action use:

1. .NET框架可能丢失，已禁用或已损坏(完全或处于代码所要求/需要的版本中) ).现在，如果您所有的3000个公司软件包都带有嵌入了托管代码的.NET dll，该怎么办?在这种情况下，他们甚至无法卸载-更少的升级.下文第5期有更多内容.

1. The .NET framework may be missing, disabled or corrupted (entirely or in the version requested / needed for your code). Now, what if all your 3000 corporate packages have a .NET dll with managed code embedded in them? They can't even uninstall in this case - much less upgrade. More below in issue #5.

使用不同的自定义操作定位.NET运行时的不同版本时，所有加载相同的CLR版本. 所以他们告诉了我(在阅读时我无法相信它-请阅读！).我足够去山上奔跑了:-).我听到自己的想法是:"这可能以多种方式爆炸".相应地应用合适的妄想症！万物的邪恶再次抬起了丑陋的头-等等...认真地说，不要听偏执狂，但要警惕严重的问题.这个问题可以解决吗?我猜-我不得不说是，但是忽略不成问题.许多不同的OS和.NET版本都需要认真的UAT/QA.本机dll会做得更好吗?我想是这样.

When targeting different versions of the .NET runtime with different custom actions, all will load the same CLR version. So they tell me (I could not believe it whilst reading it - please read it!). Enough for me to run for the hills :-). "This can blow up in any number of ways" is what I hear myself think. Apply suitable paranoia accordingly! The resident evil of all things rears its ugly head again - etc... Seriously, don't listen to paranoia, but be on alert for serious problems. Is this problem managable? I guess - I would have to say yes, but it is not a problem to ignore. Serious UAT / QA needed on many different OS and .NET versions. Would a native dll do better? I think so.

安装到 GAC 的组件不能用作您在设置中管理的自定义操作(我想是鸡肉还是鸡蛋)的依赖项.这与 Fusion / MSI 的提交模型有关.

Components installed to the GAC can not be used as dependencies for your managed custom actions in the setup (chicken or the egg - I suppose). This has to do with the commit models of Fusion / MSI.

• 博客).我认为这几乎适用于所有情况，但不适用于公司应用程序包方案(我有经验)或永远不会在生产中使用的即席测试(快速而简单).
  • 我在这里描述了这个原因(实用问题):
  • 并为将来:将嵌入托管代码的一种好用法 直接在MSI中以可检查(可重复使用)的形式-制作自定义操作的白框-嵌入了完整的源代码并具有完整的
  • Bob Arnson has commented on this - check it out (he is on the core WiX team). I don't know if this still is his top issue with managed code - along with rollback.
  • Small digression: I have read Arnson stating that VBScript actions are worse than managed code (Painter certainly agrees, and definitely the WiX boss himself Rob Mensching - blog). I think this is true for just about all cases, but not for corporate application package scenarios (which I have experience with) - or ad-hoc testing that will never be used in production (quick and easy).
    • I describe the reasoning behind this here (pragmatic issue): Windows Installer fails on Win 10 but not Win 7 using WIX (essentially anything compiled adds a source control problem in the real, chaotic world - and corporate packagers have to pick up each other's work on the fly and a fully embedded, transparent source file in the MSI saves the day - all the time, and there is a skill set issue as well, and there is more...).
    • I do not recommend VBScript for anything but corporate use in controlled environments (standardized workstations). VBScript is not good enough for public, worldwide MSI releases in any shape or form. They can work for read-only custom actions returning no error codes and set to ignore all runtime errors, but no - there are better ways.
    • UPDATE: I can add that in a snag I would use VBScript in read-only custom actions in the GUI sequence (just a property setter script) in order to get rid of the .NET framework as a dependency altogether. The time will come when the .NET framework is on all target machines, but it is not quite there yet (and even if it is there it could be broken. Windows now actively fixes ActiveScript to always be running - and MSI hosts its own ActiveScripting runtime - scripts will run, but you could easily mess up the code yourself to make the custom actions horrendous still).
    • I should add that my recommendation to use Javascript over VBScript in the link above will be removed soon. Javascript has proved just as bad as VBScript in practical use, with some added snags that are too detailed to go into. The enhanced exception handling offered by Javascript does not make up for the fact that the MSI API seems to have been tested with VBScript during its development. Javascript was probably not, and hence has a few clunky issues when working with the MSI API that are not immediately apparent. I have wasted costly time on this - I would recommend you don't waste yours.
    • I also use scripting for testing, prototyping and debugging my MSI packages (to debug property settings, app searches, override command lines for testing, etc...). I find this the quickest way (who wants to compile something ad-hoc for this?). Just don't roll with your script test code for release! If using Installshield I use Installscript for such "scripting".
    • And for the future: one good use for managed code would be embedded directly in the MSI, in inspectable (and reusable) form - making custom actions white box - with full source embedded and with full code access security too, making them unable to run with freebasing elevated rights. Just thinking about what could come - let us see what you are doing in this custom action of yours?

    为详细说明问题1，托管代码可能会硬编码某些不可用的.NET运行时版本.我想这可能是更容易解决的问题?如果我错了，请纠正我克里斯.我只是这个的涉水者.设置最新版本"仍然可能会导致问题...

    To elaborate issue 1, managed code may hard-code a certain .NET runtime version that is not available. I guess this is probably the easier problem to deal with? Correct me if I am wrong Chris. I am just a dabbler with this. Setting "lastest version" could still cause issues though...

    让我也添加一下我的话:如果托管的自定义操作由于.NET框架损坏(或其他任何原因-专注于托管代码)而在卸载过程中失败问题-例如Windows更新中Windows本身的设计/安全更改)-您无法卸载，因此不能(主要)升级现有安装.我认为严重的捕获22 .如果您要管理3000个实时软件包和数千个桌面，并且该DLL嵌入在每个MSI中，请尝试此操作...

    Let me add a pet peeve of mine as well: if a managed custom action fails during uninstall due to a corrupt .NET framework (or for any other reason - focused on managed code issues - for example a design / security change in Windows itself from Windows Update) - you can't uninstall and thereby not (major)-upgrade your existing installation. A serious catch 22 in my opinion. Try this if you have 3000 live packages and thousands of desktops to manage and the dll is embedded in each MSI...

    • 创建任何会在卸载/升级时触发错误的自定义操作代码也是制作C ++自定义操作dll时的最大担心-因此，它并不是托管代码所独有的.一个典型的错误是在InstallFinalize之后或在UI序列中将自定义操作设置为检查退出代码"-返回的琐碎错误会导致重大升级的全部回滚.经典的"catch 22"-现在，您必须先解决旧产品的卸载顺序中的问题，然后才能升级.

    • Creating custom action code of any kind that trigger errors on uninstall / upgrade was my big fear when making a C++ custom action dll as well - so it is not unique to managed code. A classic error is to set custom actions after InstallFinalize or in the UI sequence to "check exit code" - and a trivial error returned causes full rollback of a major upgrade. A classic "catch 22" - now you can not upgrade without fixing the problem in the old product's uninstall sequence.

    尽管这是所有自定义操作代码的普遍问题，但我认为托管代码的风险大大提高了.如果对.NET框架进行一些怪异的策略更改，导致大型公司中的所有软件包都嵌入了相同的有问题的自定义操作dll，那么它们将无法卸载且无法升级该怎么办?或更糟糕的是，这是Windows设计更改，您无法回滚?

    Despite this being a general problem for all custom action code, I feel the risk is heightened quite a bit with managed code. What if some weird policy change to the .NET framework makes all packages in a large corporation un-uninstallable and un-upgradeable since they all have embedded the same problematic custom action dll? Or worse yet, it is a Windows design change that you can't roll-back?

    • 在这种情况下，应该有应急计划.这就是我完全不使用托管代码的核心原因-我更喜欢扎根-更少的依赖层.最小的依赖关系，最小的纠缠(无帝国纠缠).如果最小依赖项C ++ dll无法运行，则Windows的内核通常会损坏，并且无论如何在大多数情况下都需要重新构建系统.对于.NET自定义操作，您至少需要修复.NET框架(这可能比我想的要容易-就我所知，尽管如此，还是不​​这么认为).

    • A contingency should be available in such cases. This is the core reason I stay away from managed code entirely - I like down to the wire better - fewer layers to depend upon. Minimal dependencies, minimal entanglements (no imperial entanglements). If a minimal dependency C++ dll does not run, then the core of Windows is generally broken and the system needs a rebuild in most cases anyway. For .NET custom actions you would minimally have to fix the .NET framework (which might be easier than I think - for all I know - don't think so though).

    我一直在研究使DLL成为必备程序包中所有公司程序包外部的方法(理想情况下，在安装程序本身中也包含最小的基准嵌入式DLL-如果缺少外部DLL/未找到).这样的想法是，外部DLL一旦可用就被优先使用，并且可以通过单个更新的必备软件包"对所有软件包进行升级. 所有3000个固定包-一次全部?

    I was looking at ways to make the DLL external to all corporate packages in a pre-requisite package (ideally with a minimal, baseline, embedded DLL in the setup itself as well - if the external DLL is missing / not found). The idea being that an external DLL is preferred once available, and upgradable for all packages by a single, updated "prerequisite package". All 3000 packages fixed - all at once?

    我从没有确定这种技术的可行性.忍受我，我出于您的目的而离开话题.如果WiX家伙正在阅读-那么您头顶上的技术可能性是什么?本质上，我希望听到不可能"的声音，然后我就结束了.考虑这一点时，我正在准备亚洲和阿拉伯地区的嵌入式DLL的潜在问题(由于Unicode/代码页问题而可能导致的严重，意外和致命的运行时故障)，以及Windows中的任何意外安全更改(我们保留可见-Windows 10勒索软件保护，当前会间歇性地触发安装到用户配置文件文件夹或

    I never got around to determining the technical feasibility of this. Bear with me, I am getting off topic for your purpose. If the WiX guys are reading - what are the technical possibilities here off the top off your head? Essentially I am expecting to hear "impossible" - and then I am done with it. When thinking about this I was preparing for potential problems with the embedded DLL in Asian and Arabic locations (potentially serious and unexpected and fatal runtime failures due to Unicode / code page issues), and also for any unexpected security changes in Windows (that we keep seeing - Windows 10 ransomware protection which currently intermittently triggers runtime failure for files installed to userprofile folders, or the sudden need for admin rights for MSI repair - kb2918614 which appeared out of the blue on Vista, and whatever else they keep changing unexpectedly...). I did not want to sit with thousands of un-upgradable, un-uninstallable packages - already deployed to tens of thousands of machine.

    我在企业中使用的"不得已"的意外情况是使用本地生成的"修补程序EXE对本地超级隐藏的MSI高速缓存文件夹中的所有高速缓存MSI文件进行黑客修补".由修补程序包部署.通常在所有方面都很疯狂，但从技术上看似乎是可能的(直到数字签名关闭了可能性?).对我来说，我是唯一可以接受的最后手段"，如果成千上万的交易大厅机器突然遭受灾难袭击.

    My "last resort" contingency for corporate use was to "hack patch" all cached MSI files in the local, super-hidden MSI cache folder using a "home grown" patcher EXE deployed by a hotfix package. Generally insane in every way, but it looked technically possible (until digital signatures shuts off the possibility?). And for me the only acceptable "last resort" I could think of if tens of thousands of trading floor machines were hit by disaster suddenly.

    我可以想到至少两个其他选项-其中一个是对受影响的程序包进行较小的升级(很多工作，更清洁，保证可以工作).最后一个选项将不会被提及:-)-(Voldemort，"

    I can think of at least two other options - one of which is to minor upgrade affected packages (lots of work, cleaner, guaranteed to work). The last option will not be mentioned :-) - (Voldemort, "those we do not speak of", etc...).

    我的意外事件列表中还包含用于次要升级补丁程序的自动生成功能，该补丁程序用于修补嵌入式自定义操作dll-次要升级程序仅修补该dll-没有其他更改.然后可以逐个包地处理问题.当指向需要修补的实时MSI软件包时，单击按钮即可获得该修补程序.一个嵌入式自定义操作dll修补程序".绝对不应该使用的东西.应急性的解决方案"很少.

    An auto generation feature for minor upgrade patches to patch the embedded custom action dll's was also on my list of contingencies - the minor upgrade would only patch the dll - no other changes. Then problems could be handled on a package-by-package basis. This patch should be available at the click of a button when pointing to a live MSI package in need of patching. An "embedded custom action dll hotfixer". A thing that should not ever be used if at all possible. Contingency "solutions" are rarely pretty.

    我的两分钱:我可以想到几种方案，其中最小的依赖性比MSI中的嵌入式自定义操作更重要.它必须在任何计算机，任何状态，任何语言，任何位置和理想的安装方式(此处为catch 22)，完全没有任何非标准的依赖关系.出于这个原因，我静态链接了C ++代码.对于全球发行，我觉得这是目前唯一足以满足要求的东西-静态链接的C ++代码-(可能是Installshield的Installscript例外-Installshield-现在显然没有依赖项运行了-嵌入式运行时?我不知道他们是怎么做的-在过去，安装脚本语言所需的运行时先决条件存在传奇性的问题.自Installshield 12版起应该解决此问题.

    My two cents: I can think of few scenarios where minimal dependencies are more important than for an embedded custom action in an MSI. It must work on any machine, in any state, in any language, in any location in any installation mode (and uninstall is the catch 22 here) ideally without any non-standard dependencies at all. I statically link C++ code for this very reason. For worldwide distribution I feel this is the only thing that is currently good enough - statically linked C++ code - (with the possible exception of Installscript - from Installshield - which is now running without dependencies apparently - embedded runtime? I don't know how they do it - in the olden days there were legendary problems with the required runtime pre-requisite for the Installscript language. It should be fixed since version 12 of Installshield).

    这不是完整的列表.这是我的山丘之路":-).

    This is not a complete list. It is my "run for the hills list" :-).

    • 尽管如此，请不要担心-只需了解所有内容，并使用托管代码的好处(如果它们对您而言足够多)，但是不要指望我能完全顺畅地航行.对于这些潜在的陷阱，我将与我的经理先行，而听起来并不像是一个完全的，偏执的疯子.一个好的经理人将能够根据需要出售"任何应急计划，这样您就可以花时间进行工作，甚至可以迅速进行演示(相信我，这里的关注时间很短-它必须是有史以来最快的演示).最大的问题是您是要处理一个程序包，还是要像我们在企业部署中一样处理数千个程序包.后者的情况发生了很大变化.对于所有已部署的程序包中嵌入的所有功能，必须将风险降到最低.

    • No fear though - just be aware of it all - and use the benefits of managed code if they are substantial enough for you, but don't expect entirely smooth sailing is my take on it. I would be upfront with my manager about these potential bear traps, without sounding like a total, paranoid lunatic. A good manager will be able to "sell" any contingency plans as necessities, that you can get time to work on and even demonstrate quickly (believe me, attention span here is short - it has to be the quickest demo ever). The big question is whether you have one package to deal with, or thousands like we do in corporate deployment. Things change a lot for the latter. Risk must be minimized for all features that are embedded in all deployed packages.

    如果我是100％诚实的人，那么托管代码并没有以前那么糟糕.使用DTF和其他框架有所帮助.但是，有关卸载问题的潜在运行时问题令人担忧.公司.NET框架的全局更改-您所有的软件包都无法卸载了?还是.NET框架的较新版本在自定义操作中发现了未知错误，而该错误在部署时未找到?在尝试卸载/升级时，它可能会突然显示自身".可管理，但您会诅咒自己...

    If I am 100% honest, it is not as bad with managed code as it used to be. Using DTF and other frameworks have helped. But the potential runtime issues for uninstall problems are worrying. A global change to the .NET framework in the company - and all your packages can no longer uninstall? Or a newer version of the .NET framework reveals unknown bugs in the custom action not found when it was deployed? It may suddenly "manifest itself" on attempted uninstall / upgrade. Managable, but you will curse yourself...

    我将为上述托管代码问题准备您的支持人员-他们应该了解这些问题并真正了解.NET的含义.

    I would prepare your support guys for the above managed code issues - they should know about the issues and really understand what .NET is about.

    " 我们从未见过托管代码自定义操作的任何问题 "-老实说-

    "We have never seen any problems with our managed code custom actions" - famous last words - to be honest.

    • 如果您的目标计算机是统一且标准化的(SOE环境)(这对公司而言是正常的)，则您的程序包可能看起来比实际情况更好(现在对于带有脚本的程序包也是如此).只需等待基于新操作系统的下一个SOE版本...我会尽早对所有套件中的套件进行试点测试.

    • If your target computers are uniform and standardized (SOE environment) - which is normal for corporations - then your packages may appear better than they really are (now this is true for packages with scripts too). Just wait for the next SOE version based on a new operating system... I would pilot test early with all packages in the package estate.

    您仍然可以讽刺所有目标计算机都以完全相同的方式开始发生故障(Windows Update中的Windows设计更改，触发干扰的安全软件更新，某些位置失败的SOE更新等). ).

    You could still face the irony that all target computers start failing in exactly the same way (Windows design changes in Windows Updates, security software updates that trigger interference, SOE updates that fail for some locations, etc...).

    对于全球发行而言，情况大不相同，而且往往会以许多难以调试，修复甚至根本无法解决的方式失败.通常，对于初学者来说，您根本无法访问问题系统.也许在这里的"部署的复杂性"部分中阅读了更多评论:

    For worldwide distribution things are quite different and things tend to fail in any number of ways that are hard to debug and fix or even work out at all. You normally have no access to the problem system at all - for starters. Maybe read some further comments in "The Complexity of Deployment"-section here: Windows Installer and the creation of WiX.

    因此，除非您要交付非常特定的产品并且比正常情况更详细地了解目标机器的性质，否则我绝不会使用托管代码来进行复杂程序包的全局分发.成本/收益.

    So I would never use managed code for global distribution of a complex package - unless you are delivering a very specific product and know the nature of your target machines in more detail than normal. Cost / benefit.

    如果许多计算机受到无法预料的死锁"触发器(例如无法卸载/升级)的影响，我将采取应急措施.在这种情况下有些偏执，但并非不可能.愚蠢的战争游戏".风险由您的经理来管理，而技术上则由您来处理.

    I would have a contingency for what to do if many machines are affected by unforeseen triggers of "deadlocks" such as not being able to uninstall / upgrade. Some paranoia in this scenario, but not impossible. Silly "war games". Risk is for your manager to manage, and for you to handle technically.

    从旧版本上的 installsite.org 添加到已过期但仍有效的FAQ条目的链接.托管自定义操作及其问题的主题:如何在以下位置创建自定义操作托管语言，例如C#?.

    Adding a link to an aging, but still valid FAQ entry from installsite.org on the topic of managed custom actions and their problems: How can I create Custom Actions in Managed Languages, like C#?.

    并且首先怀疑任何自定义操作！

    • 托管代码只会增加自定义操作的波动性.自定义操作非常复杂，一开始就很难正确执行.他们假冒或在错误的上下文中无意中运行，他们意外地运行两次，在预期的情况下完全不运行，他们在错误的安装模式下运行，它们由于缺少依赖项而崩溃，它们由于编码错误而导致异常，导致升级和卸载失败 strong>通过触发回滚，您硬编码对本地化文件夹的引用，因此您的安装程序在非英语计算机上崩溃，您将其命名为...

    • Managed code just adds to custom action volatility. Custom actions are complex and difficult to get right in the first place. They run impersonated or in the wrong context unintentionally, they run twice unexpectedly, they don't run at all when expected to, they run in the wrong installation mode, they crash due to missing dependencies, they cause exceptions due to bad coding that fail upgrades and uninstalls alike by triggering rollback, you hard code references to localized folders so your setup crashes in non-English machines, you name it...

    MSI本身中的内置结构，或WiX等框架中的预编写自定义操作(具有回滚支持)或诸如Installshield和Advanced Installer之类的商业工具已经通过了数千，数百万甚至数十亿的测试( ！)的用户-他们是由最好的部署专家编写的.即使对于这些组件，仍然会发现错误-这就说明了一切. 您认为自己可以做得更好吗?始终喜欢现成的，经过测试和维护的解决方案-如果有的话.

    Built-in constructs in MSI itself, or pre-written custom actions (with rollback support) in frameworks such as WiX or commercial tools such as Installshield and Advanced Installer have been tested by thousands, millions or even billions (!) of users - and they are written by the best deployment experts available. Even for these components, bugs are still found - which says it all. Do you think you could do it better on your own? Always prefer ready-made, tested and maintained solutions - if available.

    关于自定义操作的问题的一般说法:

    A whole rant about the problems with custom actions in general: Why is it a good idea to limit the use of custom actions in my WiX / MSI setups?

    ---

    来源"

    某些其他链接(某些内容可能现在已经显示了其年龄，但是这些都是值得信赖的资源-不容忽视-

    ---

    "Sources"

    Some further links (some of this content may be showing its age by now, but these are trustworthy sources - not to be ignored - Mensching is the WiX benevolent dictator):

    • Don’t use managed code to write your custom actions!
    • Link to more details about the dangers of managed code custom actions in an MSI.
    • Managed Code CustomActions, no support on the way and here's why.

    这篇关于应用程序是否依赖于编译环境?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！