Including resources/assets in installer
albertsgarde opened this issue · 4 comments
My project has a number of files that need to be placed in a specific location near the executable. Is it possible to get the installer to include these files?
I see that the Wix format has these capabilities, but you need XML for every file to include which seems very cumbersome, so I'm wondering if this utility has an easier way to do it.
This tool does not include a feature to automatically include a folder in an installer. If there are files other than the executable (exe) and license file that you wish to include, then you need to explicitly include them by modifying the WXS file (XML).
Note, the cargo wix init
command only needs to be executed once. This is a kin to the cargo init
command, and it will generate a WXS file. The WXS file can be added to version control and modified as needed to customize the installer. The WXS file should be treated just like the Rust files, i.e. a source file. So, if it is a relatively small number of additional files need to be included in the installer, the WXS file only needs to be modified once after it is initially generated. Then, every time afterwards, only the cargo wix
command needs to be executed.
If there are a relatively large number of files, then I would recommend investigating the Heat utility provided with the WiX Toolset, which is specifically designed to harvest and/or bundle folders of files into an installer. The StackOverflow question, Include all Files in Bin folder in Wix Installer, provides some excellent answers for using Heat and including whole folders in a WXS file.
Thank you very much. This is what I was looking for.
Great. I am glad I could help. I will be closing this issue as your question appears to have been answered.
I know this issue is long-closed, but I'd like you to consider a different perspective.
Some projects develop primarily on one platform, but target multiple platforms. An example is a Linux developer writing a tool for Linux, Windows, and OS X. Ideally, that developer can do all work on Linux, check in changes, and then let GitHub Actions build official releases for all three platforms. The key point here is that the Linux developer never had to use a Windows or OS X machine to get this work done.
If adding multiple files to an MSI requires the Heat utility, then the developer must boot up (perhaps after first buying) a Windows desktop, and then spend time installing .NET, Windows security updates, etc., all for a platform that he or she doesn't personally use. As far as I can tell, the value-add of Heat here is to turn a list of files into a repetitive set of XML elements. So it feels expensive for what we're getting.
Obviously, if you're targeting a platform, then it's fair to expect that you'll own at least one piece of that platform's hardware, and you can do all your TDD/QA on each machine. That's a totally reasonable point of view.
But if you'd like to enable open-source developers, often working for no compensation, to provide prebuilt binaries for end users, then it's also reasonable to imagine that a tool like cargo-wix
might parse a section in Cargo.toml
, expand the globs/patterns listed there, and generate the right .wxs sections. This would give the average underpaid open-source developer a leg up on targeting Windows. I know this somewhat violates the current workflow of using cargo wix init
to generate the first .wxs
and then leaving further edits to the developer, but it seems there ought to be an elegant way to achieve the goal without abandoning the workflow entirely, for example by templatizing that .wxs
to permit insertion of Heat-like elements .
To recap: please consider the perspective of open-source developers who are leaning on GitHub's Windows infrastructure to target Windows, and who don't personally own or use Windows PCs. From that perspective, it would be reasonable to move the concept of a project's asset-file declaration to Cargo.toml
, and then teach cargo-wix
to handle the rest, Thanks.