msbuild EXE 项目的构建和部署自动化

发布于 2024-10-21 16:05:14 字数 513 浏览 5 评论 0原文

我正在进行一些自动构建更改,并且对构建/打包 EXE 应用程序的最佳方法有一些疑问。

从概念上讲,有两个脚本。第一个构建所有内容,并将生成的二进制文件放在共享上,以便它们可用于部署。第二组脚本各自负责从该构建结果复制和配置某些应用程序。

第一个脚本构建整个解决方案,通过覆盖 msbuild 输出路径将构建结果复制到已知的拾取位置。这会导致所有二进制文件都被放入同一文件夹中(Web 应用程序除外,其中每个项目都位于 _PublishedWebsites 下自己的网站中)。这是有问题的,因为当我为单个 EXE 项目构建安装程序时,我只想包含 EXE 和该 EXE 的依赖项。然而,由于所有项目输出都位于同一文件夹中,因此不清楚各个应用程序需要哪些输出。

鉴于构建已将所有可执行文件的二进制文件放在一个文件夹中,我如何构建一个仅包含特定 EXE 所需的二进制文件的 MSI?

我使用 psake/powershell 作为构建脚本,使用 msbuild 编译解决方案文件。我正在使用 WixSharp 从命令行应用程序(不是 CSC)构建安装程序。

I'm working on some automated build changes and have some questions as to the best approach for building/packaging EXE applications.

Conceptually, there are two scripts. The first builds everything at puts the resulting binaries on a share so they are available for deployment. The second set of scripts are each responsible for copying and configuring some application from that build result.

The first script, which builds the entire solution, copies the build result to known pickup location by overriding the msbuild output path. This causes binaries for all to be dropped in the same folder (except web applications, where each project is in its own website under _PublishedWebsites). This is problematic as when I build an installer for a single EXE project, I only want to include the EXE and dependencies of that EXE. However since all project outputs are in the same folder then it is not clear which are needed by the individual application.

Given that the build has put the binaries for all the executables in one folder, how can I build an MSI that only includes the binaries needed for a particular EXE?

I am using psake/powershell for the build scripts, using msbuild to compile the solution files. I am using WixSharp the build the installer from a command-line app (not CSC).

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

薄荷梦 2024-10-28 16:05:14

摘要

由于 Wix# 实际上是在您“运行”它创建的 .exe 时构建 MSI,并使用 WiX 工具包,因此您需要将 Wix# + WiX Toolkit 创建的可执行文件输出到您的放置文件夹中。然后确保 WiX 工具包可执行文件位于您的 PATH 或输出文件夹中,并创建在放置文件夹中调用 Wix# 可执行文件的 Powershell 脚本。一种简单的方法是为每个单独的“产品安装程序”创建一个 Wix# 项目,并将这些 Wix# 可执行文件输出到您的放置文件夹,以便下游 Powershell(或其他)进一步处理/生成 MSI 文件脚本。

我正在使用集成到 VS2013 IDE 中的 Wix#,所以我的答案应该在这种情况下解释。我的 Wix# 安装程序只是我的整体解决方案中的几个项目之一。

VISUAL STUDIO 解决方案中单个 Wix# 项目的示例

因此,举例来说,如果您的 Wix# 项目代码文件在 VS 中设置为名为 MyWebsiteSetup 的项目,并且 Wix# 代码文件是 MyWebsiteSetup.cs,则您的 Wix#可执行文件将位于 \MyWebsiteSetup\bin\debug\MyWebsiteSetup.exe。

让构建将此 MyWebSiteSetup.exe 文件放置在放置文件夹中,并将 Wix# 的其他文件放置在 bin\debug 文件夹中。然后让第二组脚本运行 MyWebsiteSetup.exe 程序,这将生成 MSI。我相信您可能还需要将 Wix# 代码所需的安装组件文件部署到放置文件夹以及预期的文件夹结构中。 Wix# 似乎将它需要的所有其他支持文件放在 bin\debug 文件夹中,因此只需将所有文件从 Wix# 项目的 bin\debug 复制到 drop 文件夹就可以满足您的需要。

使示例适应多种产品(多个 Wix# 项目)

现在,您的问题是如何对所有文件都放置在同一个放置文件夹中的多个网站执行此操作。有多种方法可以解决此问题,但我建议的方法是在 Visual Studio 中为每个单独的产品创建一个单独的 Wix# 项目,并将每个项目的 Wix# 输出文件与产品一起部署到放置文件夹中文件。如果您的单独产品名为 MyWebSiteSetupA、MyWebSiteSetupB 和 MyWebSiteSetupC,它们将生成可执行文件 MyWebSiteSetupA.exe、MyWebSiteSetupB.exe 和 MyWebSiteSetupC.exe。您只需让第二组脚本依次调用每个脚本即可。当然,这些项目的每个 Wix# 代码文件(.cs 文件)都将被编码为知道运行时需要获取哪些文件,并且当运行生成的 exe 时,它​​将获取所需的文件,前提是您已按预期提供它们,并为每个产品的安装程序构建单独的 MSI。

当然,还有许多其他方法可以实现此目的,例如 PowerShell 等灵活的工具,每种方法都有优点和缺点,但我希望这可以帮助您开始使用一种方法,然后可以根据您的需求进行定制。

SUMMARY

Since Wix# actually builds the MSI when you "run" the .exe it creates, and uses the WiX toolkit, you would need to output the executable Wix# + WiX Toolkit creates to your drop folder. Then make sure the WiX toolkit executable files are either on your PATH or in your output folder, and create Powershell script(s) that invoke your Wix# executable(s) in the drop folder. One straightforward approach would be to have one Wix# project for each separate "product installer", and have each these Wix# executables be output to your drop folder, for further processing/generation of the MSI files by your downstream Powershell (or other) scripts.

I am using Wix# integrated into the VS2013 IDE, so my answer should be interpreted in that context. My Wix# installer is simply one project of several in my overall solution.

EXAMPLE FOR A SINGLE Wix# PROJECT IN A VISUAL STUDIO SOLUTION

So, for example, if your Wix# project code file is set up in VS as a project named named MyWebsiteSetup, and the Wix# code file is MyWebsiteSetup.cs, your Wix# executable will be located at \MyWebsiteSetup\bin\debug\MyWebsiteSetup.exe.

Have the build place this MyWebSiteSetup.exe file in the drop folder, along with the other files Wix# places in bin\debug folder. Then have your second set of scripts run the MyWebsiteSetup.exe program, which will generate the MSI. I believe you may need to have the installation component files the Wix# code requires be deployed to the drop folder as well, and in the expected folder structure. Wix# seems to place all the other support files it needs in the bin\debug folder, so just having all the files copied from the Wix# project's bin\debug to the drop folder should get you what you need.

ADAPTING THE EXAMPLE TO MULTIPLE PRODUCTS (MULTIPLE Wix# PROJECTS)

Now, your question was how to do this for multiple websites where all the files are placed in the same drop folder. There are several ways to approach this, but the one I suggest is to have a separate Wix# project in Visual Studio for each separate product, and have the Wix# output files for each of those projects deployed to the drop folder along with the product files. If your separate products were named MyWebSiteSetupA, MyWebSiteSetupB, and MyWebSiteSetupC, they will generate executables MyWebSiteSetupA.exe, MyWebSiteSetupB.exe, and MyWebSiteSetupC.exe. You would simply have your second set of scripts invoke each of those in turn. Each of the Wix# code files (.cs files) for those projects of course will have been coded to know what files it needs to pick up when it runs, and when the resulting exe is run, it will get the files it needs, provided you've made them available where expected, and build the individual MSI's for each product's installer.

There are of course, numerous other approaches for this, with flexible tools like PowerShell, each approach with pros and cons, but I hope this helps get you started with an approach you can then tailor to your needs.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文