如何构建作为单个独立文件/实体（无安装程序）分发的 .Net 应用程序？
目前，我有一个 VBScript“应用程序”支持发送给客户端运行，然后客户端发回一个包含结果的 HTML 文件。从角度来看，输出本质上与 Absolute Dynamics 除了我的是单个 .vbs 文件并且没有“比较”功能。
问题：对该支持工具的要求不断变化，其范围/用途也越来越大——我发现，VBScript 太大了，不再是合适的工具。理想情况下 - 我的新工具应该有一个定制机制。例如，我不必对所有需求/要查找的内容进行硬编码，而是可以有一个配置文件（例如 App.config），或者更好的是，有一个带有我自己的标记架构的 XML 文件，该文件可以是根据每个客户的需求作为应用程序的一部分提供。注意：我要求“无安装”，因为这会不断变化，安装程序会使其敏捷性大大降低；我们不会在每次发送此文件时都要求客户进行安装。
我想要的解决方案：我需要迁移到更通用的平台。 .Net 是理想的选择，因为我们已经是一家 .Net 商店。虽然如果使用 .Net，我无法想出一个以与当前 VBScript（单个实体）相同的方式进行分发的解决方案，那么如果提到其他通用编程框架，我将考虑它们。
我尝试过的：
DotNetZip，感谢 Cheeso 对这个问题的帮助：从压缩的“zip”文件运行 .Net 应用程序。我能够使用它来发送带有支持 DLL 和 App.config 的 .Net EXE，所有这些都包含在自解压 ZIP 中。不幸的是，这在 Windows XP 中不起作用，除非我遗漏了一些东西。编辑：确认这是 Windows XP 和 Windows Vista 的限制，而不是 DotNetZip。我需要我的解决方案在 XP 上工作（许多客户拥有 XP 或 Windows 2003 Server 场）
7Zip - 确实不能满足我的需求，因为在“构建”解决方案后我无法将 .config 添加到 .7z 存档中。我能够将文件添加到在 DotNetZip 中创建的 SFX，只需将其重命名为“.zip”，添加新的 .config，然后删除 .zip 扩展名。
NBox 将不起作用，因为任何配置文件（例如 app.config）的打包都需要成为我构建过程的一部分。我需要一个配置，我可以在构建过程之后/之外的任何时候简单地“插入”，并将其作为交付的最终产品的一部分
Coffee Cup 的 Zip Wizard 无法在没有用户干预的情况下解压文件。也不允许在解包后运行 EXE
NirSoft 的 Zip 安装程序。不满足我的要求，因为它仍然提示最终用户在哪里安装文件。
ZIP 2 安全 EXE。不幸的是，这也没有成功，尽管我不记得缺点是什么
纳尔。这不起作用，因为它需要运行安装。除此之外，它可能会成功。
问题：
- 根据我的要求，这可能吗？如果是这样，我应该从哪里开始，例如与上面提到的第三方或我错过的第三方合作？
- 有没有人遇到过与我类似的情况，但选择了除单个文件/实体应用程序之外的不同路线，并愿意分享？
要求：
- 必须是单个实体（例如 EXE 或 ZIP），
- 必须能够支持至少一个配置文件，支持 DLL 等。一个“健壮”的应用程序。编辑：例如，在构建我的代码后，可以将其压缩为自解压 ZIP。任何人都可以通过 XML 配置“自定义”它，然后将 .exe 重命名为 .zip，放入其配置并发送。
- 必须在 XP 及更高版本中工作。编辑：我们假设 .Net 运行时已安装（至少 v3.5）
Currently I have a VBScript 'application' for support to send to clients to run, and then the client sends back an HTML file with the results. To put it into perspective, the output is similar in nature to Syscomp.exe from Absolute Dynamics except mine is a single .vbs file and there is no 'comparison' feature.
The problem: requirements for this support tool are constantly changing and its scope/purpose is getting larger - too large, I am finding, for VBScript to be the right tool anymore. Ideally - my new tool would have a mechanism for being customized. For example, instead of me having to hard-code all of the requirements / what to look for, there could be a configuration file such as an App.config, or better yet, an XML file with my own markup schema, which can be shipped as part of the application on a per-client needs basis. Note: I require "no installation" because this will constantly be changing, and an installer will make it much less agile; we're not going to ask clients to install every time we send this out.
my desired solution: I need to move to a more general purpose platform. .Net is ideal because we're already a .Net shop. Although if with .Net I cannot come up with a solution to distribute in the same manner as I already am with the current VBScript (a single entity), then I will consider other general purpose programming frameworks if they are mentioned.
What I have tried:
DotNetZip, thanks to Cheeso's help on this SO question: Running a .Net application from a compressed “zip” file. I was able to use this to ship a .Net EXE with supporting DLL's and an App.config, all wrapped up in a self-extracting ZIP. Unfortunately, this doesn't work in Windows XP, unless I'm missing something. EDIT: confirmed this is limitation of Windows XP and Windows Vista, not of DotNetZip. I need my solution to work on XP (many clients have XP or farms of Windows 2003 Server)
7Zip - does not meet my needs because I cannot add a .config to a .7z archive after I have "built" my solution. I was able to do add files to SFX's created in DotNetZip just by renaming it to ".zip", adding the new .config, then removing the .zip extension.
NBox will not work because the packing of any config file (e.g. app.config) would need to be part of my build process. I need a config that I can simply 'drop in' after/outside of the build process at any point and have that be part of the end product that gets shipped
Coffee Cup's Zip Wizzard Does not have a way to unpack the files without user intervention. Also doesn't allow to run an EXE post-unpack
Zip Installer by NirSoft. Does not meet my requirements because it still prompts the end user where to install the files.
ZIP 2 Secure EXE. Unfortunately, this didn't work out either, although I cannot recall what the shortcoming was
NAR. this didn't work because it requires an installation to be run. Other than that, it probably would work out.
the questions:
- Is it possible, given my requirements? If so, where do I start e.g. with a third-party such as one mentioned above, or maybe one I missed?
- Has anyone encountered a similar situation that I'm in, but chose a different route other than a single file/entity application, and would like to share?
Requirements:
- must be a single entity (e.g. EXE, or ZIP)
- must be able to support at least one configuration file, supporting DLL's, etc. A 'robust' application. Edit: for example, after my code is built, it can be zipped as a Self Extracting ZIP. Anyone can 'customize' it via an XML config, then rename the .exe to .zip, drop in their config, and send it along.
- Must work in XP and forward. Edit: We assume .Net runtime has been installed (v3.5 at least)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
从根本上讲，如果没有一些外部“东西”，您就无法使用 .net 应用程序支持 XP - XP 没有标准安装任何版本的 .net，因此您可能需要要求用户安装 .net 运行时，然后您的应用程序才能运行。从好的方面来说，如果您使用 .net 4.0，那么当您运行该程序时，它会告诉用户他们需要 .net 4 运行时，而不是像早期的 .net 应用程序那样简单地崩溃。
如果我们假设预安装 .net 一次就可以了，那么有很多选择：
您可以将所有代码放入一个项目中，从而构建一个独立的程序集 (.exe)
或者，如果您有许多 dll，您可以在发布之前，使用 ILMerge 之类的工具将它们全部合并到一个 .exe 中，或者您可以将 dll 作为数据资源嵌入到 .exe 中，然后使用应用程序的 AssemblyResolve 事件来允许您从以下位置加载 dll 数据：系统需要的资源。或者将 dll 作为数据文件嵌入，然后“自动安装”它们（将它们保存到 .exe 旁边的磁盘或 GAC 中），作为程序在调用以此方式提供的任何 dll 之前执行的第一件事。
另一部分是您的应用程序必须是独立的 - 它所需的任何设置/首选项/资源都需要由应用程序本身设置 - 例如，您可以从注册表中读取首选项设置，如果它不存在，使用默认值。如果您有 XML 配置文件，则将其嵌入为资源，并直接从资源中读取它，或在启动时自动安装它，以便您的应用程序是“自安装”且完全独立的。
Fundamentally you can't support XP with a .net application without some external "stuff" - XP does not come with any version of .net installed as standard, so you might have to require users to install .net runtimes before your app can work. On the plus side, if you use .net 4.0 then when you run the program it will tell the user they need the .net 4 runtime, rather than simply crashing as earlier .net applications did.
If we assume that pre-installing .net once is ok, then there are many options:
You can put all your code into a single project and thus build a single standalone assembly (.exe)
Alternatively, if you have many dlls, you can use a tool like ILMerge to merge them all into a single .exe before you ship it, or you can embed the dlls as data resources within the .exe and then use the Application's AssemblyResolve events to allow you to load the dll data from resources as it is needed by the system. Or embed the dlls as data files and then "auto install" them (save them to disk next to your .exe or in the GAC) as the first thing your program does before it makes calls to any of the dlls it ships in this way.
The other part of it is that your application must be standalone - any settings/preferences/resources needed by it need to be set up by the application itself - for example, you can read a preference setting from the registry and if it is not present, use a default value. If you have an XML config file, then embed it as a resource and either read it directly from the resources, or auto-install it on startup, so that your application is "self installing" and totally self contained.