先决条件验证和安装 C#
我开发了一个自定义安装程序应用程序,因为 Visual Studio 安装项目的可定制性不足以满足我的需求。 我为 .NET 框架、SQL Server 等先决条件开发了一个验证器和安装程序,但我无法使用 Process.Start 启动一些可执行文件,例如 .NET 框架中的可执行文件。
我想知道是否有一个针对先决条件的自定义验证器和安装程序,或者是否有一种不同于我自己开发的先决条件安装和验证的方法:)。
提前致谢。
保罗
I developed a custom installer application because the Visual Studio Setup Projects is not sufficient customizable to fit my needs.
I developed a validator and an Installer for Prerequisites like .NET framework, SQL Server, but I'm unable to start some executables like the one from .NET framework using Process.Start.
I wonder to know if there is a custom validator and installer for prerequisites or a way to do the prerequisites installation and validation different from develop one myself :).
Thanks in advance.
Paulo
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
我强烈建议您查看http://nsis.sourceforge.net/Main_Page。这是一个开源安装工具,我已经用它来完成您正在寻找的任务,并且拥有一个重要的社区。
I strongly suggest you have a look at http://nsis.sourceforge.net/Main_Page. This is an open source installation tool which I've used for exactly the tasks you're looking for, and has a significant community.
为什么 Process.Start() 不适合你?由于缺乏这些知识,我只能描述我在尝试启动 .NET 安装程序时遇到的情况。
如果出现 UAC 对话框,请求管理员权限,则无法避免要求用户单击它。任何非提升安装过程(包括专业的第三方解决方案)在尝试启动 .NET 安装程序时都会遇到 UAC 对话框。这是因为 .NET 安装程序需要提升的管理员令牌才能运行。你无法回避这个问题。
处理后台 UAC 对话框是我遇到的情况。它会默默地闪烁,并被用户忽略,他们可能认为安装程序已经冻结并完全放弃了它。我刚刚花了两周时间研究这个问题。仅当用户在安装程序启动和出现 UAC 对话框之间单击安装程序窗口外部时才会发生这种情况。这样做会让 Windows 认为用户想要处理其他事情,并保持他单击的窗口处于活动状态。 Windows 旨在抑制“焦点窃取”,因此没有任何官方方法可以为您的窗口“夺回”焦点(即,对于您的进程启动的 UAC 对话框)。
可以安全地假设用户单击的窗口不属于您所有,因此官方 Windows 方法(让具有焦点的窗口向您的进程授予获取焦点的权限)不适用于这种情况。如果 msiexec.exe 能够保持其窗口顶层,那就太好了。
因此,在这一点上,如果您遇到了我所遇到的情况,那么据我所知,没有任何简单且 Microsoft 支持的解决方案。
但也许你遇到了其他事情?再次,请更新您的问题并提供更多详细信息,以便我们为您提供更好的答案。
正如另一位用户所建议的,更改安装 IDE,无论目标 IDE 有多好,都是一大进步。尽管我不建议使用 Visual Studio 来开发 MSI 文件,但只有当您在完成想要完成的任务时继续遇到问题时,我才会考虑迁移到另一个 IDE。但到目前为止,您仅描述了需要解决的局部问题,并且使用其他工具可能无法解决该问题。
Why exactly is Process.Start() not working for you? In the absence of that knowledge, I can only describe the situation I encountered when trying to kick off the .NET installer.
If a UAC dialog is appearing, requesting admin privileges, there is no way to avoid requiring your user to click it. Any non-elevated installation process, including a professional third-party solution, will encounter the UAC dialog when attempting to start the .NET installer. This is because the .NET installer requires an elevated administrator token to run. You can't get around that.
Dealing with a background UAC dialog was what I encountered. It would blink silently and be overlooked by users who probably thought the installer had frozen and gave up on it entirely. I just spent 2 weeks working on this issue. It only happened if the user clicked outside the installer window between the installer starting and the UAC dialog appearing. Doing so makes Windows think the user wants to work on something else, and keeps the window he clicked on active. Windows is designed to inhibit "focus stealing", so there aren't any official ways of "grabbing" focus back for your window (i.e. for the UAC dialog your process started).
It's safe to assume that the window your users click on aren't owned by you, so the official Windows methods (having the window with focus grant permission to your process to grab focus) won't work for this situation. This is where it would be nice if msiexec.exe had the ability to keep its windows top-level.
So at this point, if you are encountering what I encountered, then there aren't any simple and Microsoft supported solutions to it of which I am aware.
But perhaps you are running into something else? Again, please update your question with more details so we can give you a better answer.
Changing installation IDEs, as another user suggested, no matter how good the target IDE, is a big step. And as much as I cannot recommend using Visual Studio to develop MSI files, I would consider moving to another IDE only if you should continue encountering problems doing what you want to accomplish. So far however you have described only a localized problem to resolve, and one that may not be resolved by using another tool.