Wix Toolset:如何在卸载时还原替换的文件 [英] Wix Toolset: How to restore replaced file on uninstall
问题描述
我有两个产品-产品A和产品B.
I have two products - product A and product B.
产品A包含版本1.0.0的文件A.dll.或任何其他类型的文件(带有文本1.0.0的.config). 产品B更新文件A.dll的版本为2.0.0(或配置为文本2.0.0).
Product A contains file A.dll with version 1.0.0. Or any other type of file (.config with text 1.0.0). Product B updates file A.dll with version 2.0.0 (or config with text 2.0.0).
卸载产品B后，它将删除A.dll. 如果我将产品B中的A.dll标记为"rermanent"，则不会将其删除.
After uninstallation of Product B, it removes A.dll. If I mark A.dll in product B as "rermanent" it will not be removed.
但是在卸载产品B之后，我需要恢复1.0.0版的A.dll.
But I need to restore A.dll version 1.0.0 after product B has been uninstalled.
作为一种可能的解决方法，我可以在还原"安装模式下运行产品A.
As a possible workaround, I can run Product A in "restore" installation mode.
还有其他解决方案吗?
Is there any other solution?
P.S:案例示例: 产品A已发布，并且由于某些错误，产品B紧随其后是必需的热修复程序(在程序和功能"列表中具有其他条目). 产品B(修补程序)将A.dll替换为较新的版本. 我想支持产品B(修补程序)的卸载，并使其恢复安装之前的状态(版本1.0.0的A.dll).
P.S: Case example: Product A has been released, and due to some bugs, required hot-fixes come next as a Product B (to have additional entry in Programs and Features list). The Product B (hot-fix) replaces A.dll with newer one. I want to support uninstallation of Product B (hot-fix) and return to state before it is installed (A.dll with version 1.0.0).
推荐答案
注意:此答案是在OP修改其问题之前写的.
NOTE: this answer was written before the OP modified his question.
我认为这表明应用程序设计中存在错误.您正在处理的是两个不同版本所需的共享文件-看起来如此吗?产品A可以使用2.0.0版的dll还是绝对需要 1.0.0版?
In my opinion this indicates an error in application design. What you are dealing with is a shared file that is required in two different versions - or so it seems? Can product A use version 2.0.0 of the dll or does it absolutely require version 1.0.0?
简短答案:
-
可以将您现在共享的dll作为私有dll 安装在主应用程序的安装文件夹中(对于每种产品，它们需要的版本)，或者...
Either install the dll that you have shared now as a private dll in the main application's installation folder (for each product, in the version they require), or...
确保两种产品都可以在共享位置使用最新更新的dll(共享部署，要求完全向后兼容).
Make sure both products can use the most updated dll in the shared location (shared deployment requiring full backwards compatibility).
您还可以并排(在.NET程序集的 GAC 中或 WinSxS 中)安装两个dll版本. strong>(用于Win32文件)或磁盘上其他两个应用程序都可以访问它们的位置(它们加载所需的文件-并在卸载时保留另一个版本).哪个版本加载取决于应用程序清单(某些人发现将清单弄乱了是dll-hell的第二次出现-加载了错误的东西).
You can also install the two dll versions side-by-side (in the GAC for .NET assemblies, or in WinSxS for Win32 files) or somewhere else on disk where both applications can access them (they load the one they need - and leave the other version alone on uninstall). Which version loads depends on the application manifest (some find messing up the manifest to be the second coming of dll-hell - the wrong stuff is loaded).
最后，您可以静态链接该dll到您的主要可执行文件中(我是大型公司部署中我最不喜欢的选项-详细信息如下). .NET中的静态链接与本地Win32二进制文件略有不同:
Finally you can statically link the dll's into your main executable (my least preferred option for large corporation deployment - details below). Static linking in .NET is a little bit different from native, Win32 binaries: Static Linking of libraries created on C# .NET. I am not sure of the performance implications of static .NET linking (I only ever do Win32 static linking).
作为经验法则，共享文件必须相当稳定且几乎没有更新，才能真正用作共享.它们通常是库".在开发过程中，我可能会选择部署一段时间的私有副本，直到达到更稳定的状态并切换到共享文件(并排或全局)为止.
As a rule of thumb shared files must be rather stable with few updates to really be useful as shared. They are typically "libraries". I might chose to deploy private copies for a while during development until I reach a more stable state and switch to shared files (side-by-side or global, whichever fits).
如果您正在处理COM，则该技术的整体全局注册性质"使得必须保持向后兼容性(始终共享文件)，或者可以尝试使用"
If you are dealing with COM, then the technology's overall "global registration nature" makes it necessary to maintain backwards compatibility (files are always shared) or you can try "registration-less COM" - essentially COM with the registry information embedded in manifest files and local copies of all files in the main application installation directory - everything happens in one folder in an "isolated" fashion. COM is old, but since it is used for .NET via COM Interop it will continue to be a headache for everyone for years to come.
下面是对这些选项的更详细的讨论.有点混乱-就像您刚写下头顶时一样.一旦与它保持一定距离，我将尝试对其进行清理，并可以更清楚地了解问题所在.
Below is a more elaborate discussion of these options. It got a little messy - like it gets when you just write off the top of your head. I will try to clean it up as soon as I get some distance to it and can see clearer what is wrong with it.
如果产品A可以使用2.0.0版，则您在应用程序之间具有基本共享文件，而正常的安装方式是
If product A can use version 2.0.0, then you have a basic shared file between applications, and the normal way to install it would be a merge module included by both setups. You should have backwards compatibility so that product A can use any version of the file, including version 2.0.0. Product B should also be able to use any version of the shared dll, and you should be able to deploy an upgrade to the shared dll that both products can handle. A genuinely shared file. During product installation higher versions of the file should always be installed, and all products using the file should be able to handle the new version (backwards compatibility). Great if you have security hot-fixes that you want to deploy to many products quickly and reliably without rebuilding all products individually. This is obviously what shared files are for.
如果产品A不能使用DLL的2.0.0版本，则您可能具有并排安装方案(例如全局程序集缓存-同一程序集的不同版本)同时安装，并且应用程序会加载所需的内容).您应该将dll的两个版本安装在不同的位置(使用不同的文件名)，并且产品A和产品B应该加载它们所需的版本.或者，您应该安装到GAC-这就是GAC的用途(仅.NET程序集).普通Win32文件也有一个并行概念(
If product A can't use version 2.0.0 of the dll, then you likely have a side-by-side installation scenario (like the global assembly cache - different versions of the same assembly installed at the same time and applications load the one they need). You should install both versions of the dll in different places (with different file names), and your product A and product B should load the one they need. Or you should install to the GAC - this is what the GAC is for (.NET assemblies only). There is also a side-by-side concept for normal Win32 files (Windows side-by-side assemblies). You must never mess around in the WinSxS folder directly (the Windows assembly folder for Win32 dlls), see this excellent explanation from Advanced Istaller - just like for the GAC files are registered for installation to WinSxS). When you uninstall either product A or product B the dll needed by the other application is left untouched (there could also be other products using them). Side by side files can also be shared between products, but they won't be uninstalled if there are other products registered that need them on your product's uninstall and there are several different versions of the file to choose from so you crucially do not need to maintain backwards compatibility between the different "branches" (backwards compatibility must still be maintained for each branch - i.e version 1.0.1 must be compatible with 1.0.0 but not 2.0.0).
最明显的选择可能是将现在共享的DLL包含在产品的主应用程序文件夹中-使其成为从未尝试在其他应用程序/产品之间共享的"私有文件".这最适合Win32 dll或.NET程序集(不影响注册表或全局注册-除非.NET程序集已为COM Interop注册). COM文件已在系统范围内的注册表中注册，并且应安装到具有真正的向后兼容性的共享位置，或与旧版本并排发行(全新接口-很少使用)并以全新版本交付.如果需要并行部署，可以将.NET程序集并行安装在GAC中，也可以将它们作为程序集的私有副本"部署到主应用程序的目录中.
The most obvious option might be to include your now shared DLL in your product's main application folder - making it a "private file" that is never attempted shared between other applications / products. This works best for Win32 dll's or .NET assemblies (no registry impact or global registration - unless the .NET assembly is registered for COM Interop). COM files are registered system-wide in the registry and should be installed to a shared location with genuine backwards compatibility or delivered in a brand new versions side-by-side with the old one (with new interfaces - rarely done). .NET assemblies can be installed side-by-side in the GAC if you need side-by-side deployment, or you can deployed them into the main application's directory as "private copies" of the assembly.
因此，对于许多产品使用的文件，您具有共享文件，并排文件，在DLL中安装DLL的私有副本.应用程序的主安装文件夹，最后一个选项是静态链接-将dll编译到产品的主可执行文件中.只是提到这一点，因为有些人喜欢此选项.它不允许将更新部署到共享文件(或与此相关的文件的私有副本)中，但是对库的任何更新都需要完全重新编译和重新部署这两种产品(或我们正在谈论的许多产品)- 很多工作.人们最初可能会发现此选项很吸引人，但很快就厌倦了.这完全取决于将对您的应用程序和共享组件(现已静态链接)进行多少次更新.我们经常重复一遍:这取决于但确实如此.
So for files used by many products you have shared files, shared side by side files, installing private copies of the dll in the application's main installation folder and a final option is static linking - compiling the dll's into your product's main executable. Just mentioning this since some people prefer this option. It does not allow deployment of updates to the shared files (or your private copy of the file for that matter), but any updates to the libraries require a full recompile and redeployment of both products (or however many products we are talking about) - a lot of work. People may find this option appealing at first, but tire of it quickly. It all depends how many updates will be made to your application and the shared components (now statically linked). We repeat that too often: it all depends, but it does.
这全部取决于:-)取决于您如何设计应用程序以及要部署多少产品之间共享的文件，这些文件可以自行更新.在主应用程序exe旁边部署dll的私有副本(而不是静态链接)的最大好处是，您可以交付更新的dll，而无需重新编译整个应用程序exe(这可能会很大).您可以最大程度地减少在应用程序的其他部分中引入新错误的风险，并提供产品的少许修补程序"，而不是对所有需要进行的质量检查工作进行全面的重新编译.您有一个针对性的dll修复程序以及一个针对UAT/QA的新设置(如果操作得当，该设置也可以作为补丁提供).
It all depends :-) on how you have designed your application and how much you want to deploy files that are shared between products and that can be updated on their own. The great benefit of deploying a private copy of your dll next to your main application exe (instead of static linking) is that you can deliver an updated dll without recompiling your whole application exe (which could be huge). You minimize the risk of new bugs being introduce in other parts of the application, and you deliver "a little hotfix" of your product, and not a full blown recompile with all the QA work that entails. You have a targeted dll-fix and a new setup to UAT / QA (if you do it well, that setup can be delivered as a patch as well).
我(真正)喜欢共享文件的地方在于，我可以为它们提供单独的安装程序，这些安装程序可以自行更新，而根本不影响您主要产品的安装程序(当我说真的时)我指的是数十个应用程序使用的文件，而不仅仅是几个.这样可以很好地解耦，并且只需对共享文件进行热修复"，就可以对主应用程序进行一些QA/UAT.没有完整重新编译您的主要产品，也没有对其进行新的设置以进行质量检查/UAT的重新编译.如果您交付许多大型产品，这是非常重要的. 您的共享文件可能会遇到一些非常重要的安全修补程序，这些修补程序会被其他数十种应用程序使用.我在大型公司(例如银行)中看到了很多此类情况-您可能需要花费数周或数月的时间进行更新否则，数十种产品中都存在相同的问题.每个人的噩梦.
What I like about (genuinely) shared files is that I can deliver them with a separate setup that can be updated on its own, without affecting your main product's setup at all (when I say genuinely I mean files that are used by dozens of applications, not just a couple). This decouples things nicely and all that is needed is some QA / UAT of the main application after the shared files have been "hot-fixed". There is no full recompile of your main product AND a new setup for it to QA / UAT. If you deliver many large products this is very important. You could face some excruciatingly important security hot-fixes for your shared files that are used by dozens of other applications. I see this a lot in large corporations, for example banks - you could spend weeks or months updating the same problem in dozens of products otherwise. A nightmare for everyone.
我应该补充，这是我个人的观点，我不太喜欢合并模块.这是一个不错的概念，但就所有意图和目的而言，它相当于您的设置的静态链接.不完全是，但几乎是-我的意思是在编译时包含所有文件.不过，好消息是，只要升级的合并模块(在新设置中)具有更高版本的文件，合并模块的升级版本便可以包含在另一个安装程序中，该安装程序将升级相同的文件.因此，它不是完全静态链接"，但有点像.
I should add, and this is a personal opinion, that I don't really like merge modules that much. It is an OK concept, but for all intents and purposes it amounts to static linking for your setup. Not quite, but almost - all files are included at compile time is what I mean. The good news, however, is that an upgraded version of the merge module can be included in another setup that will upgrade the same files as long as you have higher version files in your upgraded merge module (in your new setup). So it is not quite "static linking", but it sort of feels like it.
我的个人喜好:如果共享文件确实有助于保持许多产品的更新和热修复，请使用共享文件.在大多数情况下，这些共享文件非常稳定，几乎没有更新，并且由于共享工作良好(您会在某种程度上感谢您-当某些事情确实达到安全性时).通过它们自己的安装程序部署共享文件，并将该安装程序设置为您自己的产品安装程序的先决条件.这对我来说已证明是最灵活且最完整的功能-特别是在大型公司(内部软件)中.您可以将它们与诸如WiX's Burn的引导程序链接在一起(在公司中，您将使用SCCM之类的部署系统来设置依赖项)，并且可以分别为共享文件和应用程序文件提供更新.如果您的应用程序很简单并且共享文件不太稳定，则只需在主安装目录中部署dll的私有副本即可(除非它是COM文件).我会避免过多的静态链接(我只喜欢在最小依赖方案中使用静态链接-就像为WiX设置创建自定义操作dll并希望其运行时一样在没有依赖项的任何机器上).
My personal preference: do use shared files if they really help keeping lots of products updated and hot-fixed. In most cases these shared files are very stable with few(er) updates, and because of this work well as shared (you will thank yourself at some point - when something really hits security-wise). Deploy the shared files via their own setup and set that setup as a prerequisite for your own product's setup. This is what has proved most flexible and feature complete for me - especially in large corporations (for in-house software). You can chain it all together with a bootstrapper like WiX's Burn (in corporations you would use a deployment system like SCCM instead to set up dependencies), and you can deliver updates separately for your shared files and your application files. If your application is simple and your shared files are not too stable, just deploy a private copy of the dll(s) in your main installation directory (unless it is a COM file). I would avoid too much static linking (I only prefer static linking for minimal dependency scenarios - like when you make a custom action dll for your WiX setup and you want it to run on any machines without dependencies).
良好的部署取决于良好的开发决策.都是凝聚力和耦合力.只有经验法则，没有适合所有人的方法.无论您做什么，都将需要大量工作，但要避免影响太多应用程序的微小更改，而这些应用程序需要完整的开发/部署发布周期，这是共享文件的总体目标.
Good deployment depends on good development decisions. It is all cohesion and coupling. There are only rules of thumbs and no way that is right for everyone. It will be a lot of work no matter what you do, but try to avoid small changes affecting too many applications requiring a full development / deployment release cycle for all of them - it is the overall goal of shared files.
这篇关于Wix Toolset:如何在卸载时还原替换的文件的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
