MSI Build 卸载 - 安装目录未删除 [英] MSI Build uninstall- Installed directory not removing

查看:31
本文介绍了MSI Build 卸载 - 安装目录未删除的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我为我们的应用程序创建了 MSI 构建包.安装完成后,我们在安装程序类的提交事件中在单独的进程中触发了另一个依赖驱动程序软件,如下所示,

Process.Start(驱动软件路径")

我们面临一个问题,安装目录(它是空的)文件夹在卸载时没有删除.其实和安装一样,我们通过覆盖installer类的Uninstall方法,在单独的过程中触发了依赖驱动软件的卸载.

任何人,请帮我解决这个问题?如何删除已安装的目录?

我无法更改安装程序,因为我们知道当另一个安装/卸载程序正在进行时,我们无法处理另一个安装/卸载程序.

解决方案

您正在 MSI 中运行非 MSI 驱动程序安装 EXE?正确吗? 或者它可能是包含在 EXE 中的 MSI?

您有Installshield Premier吗?您能否使用套件项目并在 MSI 安装之前(或之后)通过引导程序安装 EXE?老实说,我从未使用过此功能,但按顺序运行设置就是它的用途.MSI 文件中嵌入的自定义操作启动 EXE 文件是出了名的不可靠.这是 - 在我看来 - 如果您也使用托管代码运行(我认为您是)尤其如此.

从长远来看,托管代码可能会产生更安全的自定义操作代码(安全方面基于

<小时>

或者,您可以尝试提取用于驱动程序设置的 setup.exe 文件并将驱动程序安装为常规 MSI 组件并运行 DPinst.exe 安装/卸载驱动程序(工具来自 DIFx).也很笨重 - 特别是当您需要包括卸载时.

您的驱动程序设置可能已经使用了 DPInst.exe.我会检查您是否可以从 EXE 中提取 MSI 并使用它而不是 EXE 来包含在套件项目中.关于如何处理 setup.exe 文件(提取、运行时参数等)的一些提示:从 EXE 中提取 MSI.

WiX 在它的一个中具有 Driver 元素处理驱动程序安装的扩展.我从来没有机会测试它.

I created the MSI build package for our application. After this installation, we triggered another dependent driver software in the separate process in a committed event of Installer class like below,

Process.Start (" Path of driver software ")

We are facing an issue, installed directory ( It's empty ) folder is not removing while un-installing the same. Actually like installation, we triggered the un-installation of dependent driver software in the separate process by overriding the Uninstall method of installer class.

Anyone, please help me to overcome this issue? How could I remove the installed directory?

I can't change the installation procedure, since we are aware that we can't process another installation/un-installation when another one is going.

解决方案

You are running a non-MSI driver install EXE from within your MSI? Correct? Or maybe it is an MSI wrapped in an EXE?

Do you have Installshield Premier? Could you use a suite project and install the EXE via the bootstrapper before (or after) the MSI install? I have honestly never used this feature, but running setups in sequence is what it is for. Embedded custom actions in MSI files kicking off EXE files are notoriously unreliable. This is - in my opinion - especially true if you are running with managed code as well (which I think you are).

In the long run managed code may yield safer custom action code (security-wise based on CAS), but for now it seems to cause unwanted runtime dependencies - especially for very large-scale distribution (global distribution) targeting diverse Windows versions (Vista, 7, 8, 10).

I am told it takes a while to get used to Installshield's suite feature, but maybe it is better for you? You can run EXE files, MSI files, patches and zips in sequence. Some fiddling to define uninstall and upgrade behavior I guess and lots of testing. I am pretty sure corporate application packagers would be happy to see a suite rather than an MSI with lots of strange stuff embedded in it.

UPDATE: Once you have compiled a suite setup.exe file it can be extracted as described here: Regarding silent installation using Setup.exe generated using Installshield 2013 (.issuite) project file


Alternatively you could try to extract the setup.exe files for the driver setup and install the drivers as regular MSI components and run DPinst.exe to install / uninstall the drivers (tool from DIFx). Also quite clunky - especially when you need to include uninstall.

Your driver setup likely uses DPInst.exe already. I would check if you can extract an MSI from the EXE and use it instead of the EXE to include in the suite project. Some hints for how to deal with setup.exe files (extraction, runtime paramenters etc...): Extract MSI from EXE.

WiX has the Driver element in one of its extensions to deal with driver installs. I have never had the chance to test it.

这篇关于MSI Build 卸载 - 安装目录未删除的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆