使用C#Winforms而不是Installer工具创建Windows安装程序 [英] Creating a Windows installer using C# Winforms instead of Installer tool
问题描述
我以前使用过InstallAware和InstallShield，它们很难一起使用，当出现问题时，很难找到并解决问题.
I have used InstallAware and InstallShield before, and they are pretty difficult to work with and when something goes wrong it is very difficult to find and resolved the issue.
我的问题是为什么我们不能使用用C#编写的Windows应用程序来执行此操作.我知道.net框架可能未安装在目标计算机上，所以我想知道为什么没人使用过这种体系结构:我将使用IntallSiheld(或任何其他类似工具)创建一个简单的安装程序，以仅安装.Net Framework，然后解压缩并运行我自己的Windows应用程序，该应用程序是我使用C#在提升模式下编写的.我的应用程序将运行带有后退"和下一步"按钮的向导，我将处理其中的所有内容(复制文件，创建和启动Windows服务，添加注册表值，创建防火墙扩展等).有没有人做过这件事，并且有什么阻止人们这样做的事吗?
My question is why can't we use a Windows application written using C# to do this. I understand that .Net framework may not be installed on the destination computer, so I wonder why no one has ever used this architecture: I will create a simple installer using IntallSiheld(or any other similar tool) to just install .Net Framework and after that extracts and runs my own Windows application which I have written using C# in elevated mode. My application will run a Wizard with Back and Next button and I will take care of everything in it (copying files, creating and starting Windows Services, adding registry values, creating firewall extensions etc.) Has anyone ever done this, and is there anything that prevents people from doing this?
推荐答案
本质上 :请勿尝试重新发明轮子.使用现有的部署工具来完成您的日常工作:-).有许多可用的此类工具.请参阅下面的链接.
In essence: don't try to re-invent the wheel. Use an existing deployment tool and stay with your day job :-). There are many such tools available. See links below.
及以下，长时间重复的沉思:
And below, prolonged, repetitive musing:
Redux :恕我直言，在所有应有的尊重下，我可能会这样说，制造自己的安装程序软件正在彻底改造轮子，我担心这绝对没有任何收益.我相信您会重新发现"其他人发现的复杂性，他们在创建自己的安装程序软件时发现了部署过程中遇到的困难，并发现该软件可以快速制作，但很难完美实现.在此过程中，您将花费大量精力来尝试整理内容-并且"最后一米很长"，因为您诅咒自己处理琐碎小事，而琐碎小事却浪费了您的时间，否则会支付账单.整理出任何工具包中的错误，无论采用哪种技术功能，都可能需要数年甚至数十年的时间.不，我没有弥补.这是所有部署软件供应商都在处理的问题.
Redux: IMHO and with all due respect, if I may say so, making your own installer software is reinventing the wheel for absolutely no gain whatsoever I am afraid. I believe you will "re-discover" the complexities found by others who have walked the path that is involved in deployment as you create your own installer software and find that software can be quick to make, but very hard to perfect. In the process you will expend lots of effort trying to wrap things up - and "the last meter is very long" as you curse yourself dealing with trifles that take up your time at the expense of what would otherwise pay the bills. Sorting out the bugs in any toolkit for whatever technical feature, can take years or even decades. And no, I am not making it up. It is what all deployment software vendors deal with.
许多现有工具 :已经有许多现有工具实现了这种部署功能-这些工具不基于Windows Installer( Inno Setup ， NSIS ， DeployMaster 以及其他一些鲜为人知的工作):
Many Existing Tools: there are many existing tools that implement such deployment functionality already - which are not based on Windows Installer (Inno Setup, NSIS, DeployMaster and heaps of other less known efforts):
- There is a list of non-MSI installer software here.
- There is another list of MSI-capable software here.
我的2美分-如果您不喜欢MSI，请选择一种免费的非MSI部署工具. 如何创建Windows Installer .
My 2 cents - if you do not like MSI, choose one of the free, non-MSI deployment tools. How to create windows installer.
企业部署 :最重要的一点(对我而言)是，企业部署依赖于标准打包格式(例如MSI)来实现允许对软件的部署进行可靠的远程管理.自己制作安装程序不会给任何系统管理员或公司部署专家留下深刻的印象(至少要等到您解决了多年的错误和缺陷之后).他们想要知道如何处理的标准化格式(这并不意味着它们对现有部署技术印象深刻). 使用标准化的部署格式进行部署可以使您的软件获得公司的批准 .如果您制定了一种奇怪的部署格式，该格式在安装时执行了不常见的事情而又难以轻松地进行大规模捕获和部署，那么您的软件在任何大公司中都是首屈一指的.不怜悯-真实.这些都是繁忙的环境，对于您不寻常的解决方案，您将几乎一无所知.
Corporate Deployment: The really important point (for me) is that corporate deployment relies on standardized packaging formats - such as MSI - to allow reliable, remote management of your software's deployment. Making your own installer will not impress any system administrators or corporate deployment specialists (at least until you sort out years of bugs and deficiencies). They want standardized format that they know how to handle (that does not imply that they are that impressed with existing deployment technology). Doing your deployment with standardized deployment formats can get you corporate approval for your software. If you make a weird deployment format that does unusual things on install that can't be easily captured and deployed on a large scale your software is head-first out of any large corporation. No mercy - for real. These are busy environments and you will face little understanding for your unusual solution.
文件推送器" :我们这些以文件为生的人知道部署领域充满了愚蠢在其他工作中迅速失去工作效率的问题-使您在领域中脱颖而出的问题-您的日常工作.部署是 高姿态，低状态的尝试 -我们没有抱怨.事实就是如此:一种必需品比您想象的要难处理.我会得出结论，只是更明智地度过您的时间.
"File-Pushers": Those of us who push files around for a living know that the field of deployment is riddled with silly problems that quickly kill your productiveness in other endeavors - the ones that make you stand out in your field - your day job. Deployment is a high profile, low status endeavor - and we are not complaining. It is just what it is: a necessity that is harder to deal with than you might think. Just spend your time more wisely is what I would conclude.
复杂度 :也许在此处略过" 部署的复杂度 "部分:Windows Installer和WiX的创建.处理部署中发生的所有愚蠢错误令人惊讶.尽管可能很容易想到它，但它不仅是文件副本.而且，如果恰好只是文件副本，那么可以使用现有的工具来完成这项工作.也免费.请参阅上面的链接.而且，如果您认为部署通常只是文件复制，那么请略过此任务列表，该部署任务应能够支持:
Complexity: Maybe skim the section "The Complexity of Deployment" here: Windows Installer and the creation of WiX. It is astonishing to deal with all the silly bugs that happen in deployment. It is not just a file copy, though it might be easy to think it is. And if it happens to be just a file copy, then there are existing tools that do the job. Free ones too. See links above. And if you think deployment is only file-copy in general, then please skim this list of tasks a deployment task should be capable of supporting: What is the benefit and real purpose of program installation?
您自己生产的包裹会处理以下情况吗?(只是一些随意的想法)
Will your home-grown package handle the following? (just some random thoughts)
- 韩国的一台受恶意软件感染的终端服务器PC上是否有Unicode字符?
- 符号链接和NTFS交接点路径?
- 一台笔记本电脑由于电池没电而在文件副本的中间自行关闭了?
- 磁盘空间不足的情况?磁盘错误呢?并复制超时?
- 重启要求如何?由于使用中的文件或其他原因.如何处理它们?如果系统处于重新启动挂起状态，并且您需要在开始安装之前检测到该怎么办?
- 您将如何可靠地安装，配置以及启动和停止服务?
- 您将如何支持应用程序的卸载和清理?
- 可将未知，无法识别，非标准软件包标记为安全威胁并对其进行隔离的安全软件?您将如何开始处理呢?您要与谁联系以获取公认的二进制"高程的好地方?
- 非标准NTFS许可(ACL)和NT特权?当您被拒绝权限时，如何检测到它并优雅地降级?(无论出于何种原因).
- 部署必要的运行时以使您的应用程序正常工作吗?(之前已经有很多其他人做过).如果您的嵌入式运行时已过时，请下载最新的运行时吗?等等...
- 提供一种从安装二进制文件中提取文件的标准化方法吗?
- 为尝试使用二进制设置的用户提供帮助和支持吗?
- 等等...这只是很快想到的所有内容的随机列表.显然有很多问题.
对于您的要求来说，这有点过头了，但是请不要误以为部署是您可以在几个小时内解决一个问题的方法.绝对不要承担保证这样做的工作-如果这正是您的要求.只是我的两分钱.
This was a bit over the top for what you asked, but don't be fooled to think deployment is something you can sort out a solution for in a few hours. And definitely don't take the job promising to do so - if that is what you are being asked. Just my two cents.
上述问题以及许多其他问题是人们发现创建部署软件时必须处理的问题-除最琐碎的部署之外的所有部署.不要浪费时间-使用一些已建立的工具 .
The above issues, and many others, are what people discover they have to handle when creating deployment software - for all but the most trivial deployments. Don't waste your time - use some established tool.
交易 :如果您在公司工作，并且只需要将文件提交给测试人员，则可以使用批处理文件进行部署-如果您愿意.但是您必须支持它，我保证您会花费很多时间.当批处理文件由于网络错误而中途失败时，您的测试人员正在测试不一致的文件，该怎么办?对于此类轻量级任务，未来的部署技术可能会更好. 部署工具的最大功能可能是报告部署是否成功完成，并记录错误并在出现故障时将计算机恢复到稳定状态 >.Windows Installer可以为您完成很多工作.
Transaction: If you are working in a corporation and just need your files to your testers, you can deploy using batch files for that matter - if you would like to. But you have to support it, and I guarantee you it will take a lot of your time. What do you do when the batch file failed half-way through due to a network error, and your testers are testing files that are inconsistent? Future deployment technologies may be better for such light-weight tasks. Perhaps the biggest feature of a deployment tool is to report whether the deployment completed successfully or not, and to log the errors and to roll the machine back to a stable state if something failed. Windows Installer does a lot of this work for you.
分发 :很多人认为他们可以" 只需将我的构建文件夹复制到用户的计算机 ".这里涉及的复杂性很多.涉及网络，永远不能假设网络是可靠的，在这里您需要处理大量错误.然后是事务问题:什么时候知道计算机处于稳定状态并且应该停止复制.仅按需复制多久一次?您如何处理少数无法复制的计算机.您如何告诉用户? 这些是发行问题 .公司拥有诸如SCCM之类的强大工具来处理所有这些错误情况.尝试重新实现所有这些检查，日志记录和功能将花费很长时间. 最后，您将重新创建一个现有的分发系统 .完整的循环.又由于仅运行批处理文件或脚本而没有注册安装产品时，如何库存计算机?而且，如果您开始复制很多软件包，那么您将扫描每个文件多少次以确定它们是否是最新的?您要创建多少网络流量?它在哪里结束?答案是:我认为必须使用完整的日志记录，错误跟踪和回滚来实现事务. 然后您就可以像我上面提到的那样分发系统，以及受支持的软件包格式 .
Distribution: A lot of people feel they can "just replicate my build folder to the user's computers". The complexities involved here are many. There is network involved, and network can never be assumed to be reliable, you need lots of error handling here. Then there is the issue of transactions: when do you know when the computer is in a stable state and should stop replicating. How often do you replicate, only on demand? How do you deal with the few computers that failed to replicate. How do you tell the users? These are distribution issues. Corporations have huge tools such as SCCM to deal with all these error conditions. Trying to re-implement all these checks, logging and features will take a long time. In the end you will have re-created an existing distribution system. Full circle. And how do you do inventory of your computers when there is no product registered as installed since only a batch file or script ran? And if you start replicating a lot of packages, how many times do you scan each file to determine if they are up to date? How much network traffic do you want to create? Where does it end? The answer: I guess transactions must be implemented with full logging and error tracking and rollback. Then you are full circle to a distribution system like I mentioned above and a supported package format as well.
这个" 只是将我的构建文件夹复制到我的用户 "的想法以某种方式使我想起了该列表:
This "just replicate my build folder to my users" ideas somehow remind me of this list: https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing. Not a 100% match, but the issues are reminiscent. When networking is involved, things start to become very unpredictable and you need logging, error control, transactions, rollback, network communication, etc... We have re-discovered large scale deployment - the beast that it is.
网络 :假设您要将构建文件夹复制到企业中的 10000台台式机.您如何开始复制?您是否立即开始所有复制，并降低了银行的交易场所，因为文件复制像 DDOS攻击一样占领了整个网络?抱歉-它已经不复存在了手动-请原谅这种轻率的做法-但是，这种复制方法对于大规模部署是可行的，这确实令人不安.内置的Windows功能可能会有所帮助，但仍需要进行正确的测试.您需要 scheduling ， queueing ， caching ，区域分布共享，日志记录，<代码>报告/库存，上帝知道打包/部署系统还为您提供了什么.并且重新实现它将是一堆需要处理的新bug的痛苦之路.
Network: and let's say you want to replicate your build folder to 10000 desktop machines in your enterprise. How do you kick off the replication? Do you start all replications at once and take down the trading floor of the bank as file replication takes over the whole network like a DDOS attack? Sorry - it is getting out of hand - please pardon the flippancy - but it really is upsetting that this replication approach is seen as viable for large scale deployment. Built-in Windows features could help, but still need to be tested properly. You need scheduling, queuing, caching, regional distribution shares, logging, reporting / inventory, and God knows what else that a packaging / deployment system gives you already. And re-implementing it will be a pain train of brand new bugs to deal with.
也许我们有一天会看到基于自动生成软件包的自动输出文件夹复制，该复制实际上是通过智能的交易系统进行的.许多公司团队正在尝试，并且通过使用现有工具，他们与所使用的标准程序包格式更加接近.我猜想当前的云部署系统正在通过在线存储库和简单的交互式安装朝这个方向发展，但是我们仍然需要智能地打包软件.看看在云时代，未来会怎样，打包和分发会带来什么新问题将是很有趣的.
Maybe we one day will see automatic output folder replication based on automatic package generation which really works via an intelligent and transacted distribution system. Many corporate teams are trying, and by using existing tools they get closer with standard package formats used. I guess current cloud deployment systems are moving in this direction with online repositories and easy, interactive installation, but we still need to package our software intelligently. It will be interesting to see what the future holds and what new problems result for packaging and distribution in the age of the cloud.
当我们按需直接从在线存储库中提取文件时，会看到很多新问题吗?恶意软件，欺骗和注入?(已经存在问题，但可能会变得更糟).删除远程文件而不会发出警告(以摆脱不应该再使用的易受攻击的发行版，使用户陷入困境)?证书和签名有问题吗?防火墙与代理问题?带有不幸错误的自动魔术更新会立即并意外地打击每个人?与上述相关的网络谬论和其他因素.打败我.我们将会看到.
As we pull files directly from online repositories on-demand we will see a bunch of new problems? Malware, spoofing and injection? (already problematic, but could get worse). Remote files deleted without warning (to get rid of vulnerable releases that should no longer be used - leaving users stranded)? Certificate and signature problems? Firewalls & proxy issues? Auto-magic updates with unfortunate bugs hitting everyone immediately and unexpectedly? And the fallacies of the network and other factors as linked to above. Beats me. We will see.
好吧，它像往常一样变成了咆哮-上一段充满了猜测(有些问题已经适用于当前部署).对于那个很抱歉.但是，请设法获得管理人员的批准，以使用现有的包装和包装.部署解决方案是我唯一的建议.
OK, it became a rant as usual - and that last paragraph is heading over board with speculation (and some of the issues already apply to current deployment). Sorry about that. But do try to get management approval to use an existing packaging & deployment solution is my only advice.
Stefan Kruger的Installsite.org Twitter提要: https://twitter.com/installsite
最近的一些亮点:
- https://twitter.com/SurjKhera/status/980531378692468737
- https://twitter.com/TimothyMangan/status/947853348430143488
选择部署工具:
- 如何创建Windows Installer
- 要使用哪种安装产品?InstallShield，WiX，Wise，Advanced Installer等
- Windows Installer和WiX的创建
- WiX快速入门提示
- 更多在dark.exe(略微向下移动页面)上
这篇关于使用C#Winforms而不是Installer工具创建Windows安装程序的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
