MSI Installer

[ZigMeowNyan]

What all did you need for an installer? Depending on how complex you need it, I (or others) might be able to help. A couple things about installers:

• For generating vanilla MSI Windows installers, WiX is the usual means. All the configuration is stored in XML, and it can work with Visual Studio or as a standalone tool. It can do most everything, but it requires a fair amount of knowledge to do more complex tasks. Simple folder deployments are very straightforward, though.
• There's a lot of other installation systems, like InstallShield or NSIS that get used a lot due to be being relatively simplistic. Most often they get deployed as executable assemblies (EXEs) instead of installers.
• You can do fancy UI wrappers around the installers (with EXE wrappers) and some limited internal UI changes, too, but I generally wouldn't bother. There are templates that give you the standard Welcome/License/Installation Path UX.
• Building installers from non-Windows systems can be a pain. WiX requires WINE to build on Linux due to a dependency on MSI.DLL. There's a Gnome project, MSITools, that has a partial WiX implementation but finding documentation on it is a pain, so I haven't bothered looking into it.

So what did you need the installer to actually do? And is it okay if it only builds on Windows?

[dthree]

Hey thanks, you're awesome!

1. Yes, totally okay for only Windows. The point of this is to make it ridiculously easy for Windows users to get started with Cash.
2. The installer needs to a) bundle Node (another MSI), and if it doesn't exist, run that installer first, and b) place the bundled cash package in a directory, and run a script using Node to link commands to PATH (that heavy lifting is covered by NPM).
3. In terms of options, it would be really cool if there could be a page with a checkboxed picklist of which commands (ls, less, etc.) the person wants to install, but this isn't mandatory.

---

Ideally, the build process is something I can throw into this repo (don't know if that's a terrible idea) so its easy to throw together new builds based on updates.

---

I can help with a ton of it, I'm just in the point where I have no idea what I'm talking about on this subject and don't know where to get started.

You're awesome! :+1:

[ZigMeowNyan]

Ok, I'm looking into how to best install Node from an external MSI at the moment. There's a lot of ways this type of thing can be handled, and I haven't touched that side of things in a while. More info on that in a bit.

In terms of options, it would be really cool if there could be a page with a checkboxed picklist of which commands (ls, less, etc.) the person wants to install, but this isn't mandatory.

This is doable. You can make a feature selection with the templates. One wart of MSIs is by splitting things into features, the install slows down a little, but it's still faster than InstallShield and it's a one-time gripe.

I can help with a ton of it, I'm just in the point where I have no idea what I'm talking about on this subject and don't know where to get started.

If you can start taking inventory of:

• Your files and their dependencies
• Your deployment locations
• Where these end up being built after your build process
• Informational details (organization name, contact address / help url etc) that can go into the installer
• Any additional requirements beyond file deployment (e.g. editing the Path variable, shortcuts, documentation, etc)

That would let you get ahead of the game. I'll probably work with you on the first few features and then help you add the rest your own so you feel comfortable supporting it yourself. If you can install WiX, that's good, too. I'm on the latest stable, but the version's not terribly important most times. I use it through Visual Studio, but it works standalone, as well.

[dthree]

K.

• I installed Wix two weeks ago, before I realized how terribly amateur I was on this subject. So were good there :)
• All files and deps are in this repo. Going to do an NPM shrinkwrap, basically, which I'll write a script for. But consider that done.
• %ProgramFiles%\Cash, or %ProgramFiles(x86)%\Cash. Node just does its normal thing.
• Same spot as install, unless I am misunderstanding something.
• When we get to that, just tell me where to add the details.
• I think we're good on additionals for now, let's just get the basics done and then we'll elaborate.

[ZigMeowNyan]

The installer needs to a) bundle Node (another MSI), and if it doesn't exist, run that installer first, and b) place the bundled cash package in a directory, and run a script using Node.

Ok, I'm looking into how to best install Node from an external MSI at the moment. There's a lot of ways this type of thing can be handled, and I haven't touched that side of things in a while. More info on that in a bit.

So, apparently there are a lot of limitations on this. Chaining MSIs is not supported, though I'm seeing some notes that there's been some changes as of Windows Installer 4.5 (Win 7+, I believe). I'm not finding a lot of information on how to use that in WiX. There's this, but it'll take some time to grok it. Before that, there were two techniques:

1. Build the prerequisite into a merge module (MSM file) and include it in the installer. I'm not seeing any reference to node being built as an MSM, though...
2. Wrap the installer with a bootstrap EXE that chains the installers for you.

So, I think what I'll do right now is postpone that part of it and give you an example of the feature selection that you can work with.

[ZigMeowNyan]

I'm going to check through the UI templates for one that fits the feature selection UX. I should have a simple example for you within 15-30.

[dthree]

You're the best.

[ZigMeowNyan]

Here's an example that provides a feature selection with two components: ls.exe and dir.exe. This should give you an idea of how it works.

Since I didn't know if you were actually using Visual Studio, it pulls those files from a Files subdirectory. The Source attribute is the bit that specifies the path.

[dthree]

Okay great. Now the tricky part is that ls, dir, etc. aren't going to be .exes. Preferrably, those checkboxes could just write the chosen config to a file, and I can handle the post-processing in a Node script that builds the PATHs. Would that work?

[ZigMeowNyan]

Okay great. Now the tricky part is that ls, dir, etc. aren't going to be .exes.

This part is just for file deployment, and works for any file type. Only deploying the selected files if the feature is selected is the easiest and most generic MSI approach.

Preferrably, those checkboxes could just write the chosen config to a file, and I can handle the post-processing in a Node script that builds the PATHs. Would that work?

It's a bit complex. I'm looking at config file building for you. It looks like built-in WiX functionality can do XML writing, which I know isn't a Javascript favorite. Gotta love enterprise. I haven't seen anything that builds a JSON file. I guess we could look at a custom action, but that'll probably require Node to be installed first.

Gonna drop a few generic guidelines for Wix stuff:

1. It's pretty common to define things in fragments, rather than one massive structured XML file. You can split those fragments into separate files and reference them, or put multiple Fragment elements anywhere under the Wix element. Visual Studio is pretty helpful with WiX because of the built-in intellisense of the WiX schemas.
2. ComponentGroups can contain multiple components (which can be files, registry entries, etc). You can reference both Components (with ComponentRef ) and ComponentGroups (with ComponentGroupRef) in the Feature definitions.
3. Components can technically have multiple files, but only one of those files may have the KeyPath attribute set to yes. The rest would be set to no.
4. The attributes in the Product element contain the installer name and version number. The Id is a Guid. An Asterisk autogenerates, but it's a good idea to pick one for that.
5. The Package element has a lot of metadata, like contact information, languages, etc.
6. The MediaTemplate element controls how the cab files are built.
7. The MajorUpgrade upgrade element controls how the MSI behaves when another MSI of the same id.
8. Add a license file (RTF) like so: <WixVariable Id="WixUILicenseRtf" Value="Files/License.rtf" />

I'll see what I can do about a node installation bootstrapper now. You can use the above to start building out the files you're always placing in the target directory.

[dthree]

Okay great - very helpful info.

[mikekidder]

Wix# is much easier https://wixsharp.codeplex.com/wikipage?title=Managed%20Setup

[ZigMeowNyan]

Yeah, Wix# is pretty handy. You don't have to know the XML config, but then you've got to know C# and have a .NET build environment ready, which might not be the case for a lot of people building this, since it's based in node. I was going for something where they could run a tool and build as long as WiX was installed. If you want to throw an example together, though, I'm sure it'd be appreciated.

[mikekidder]

Really though, Node is pretty dead simple to install these days. And then there is Chocolatey.org as well. So not why the need for installer. Anybody who wants this, easy enough to npm install.

This is awesome project, been using Posh-git in Powershell

[mikekidder]

Actually the author of Wix# also wrote and built CS-Script.. and has a plugin available for Notepad++. Its really cool stuff. So no need for Visual Studio, etc. Its optional. Everything is built on top of Wix and hides all the ugly XML cruft. Lots of examples when you download as well. Really good stuff. I've built custom installer (with custom UI, dependancies, IIS, SQL steps. etc.) from it. Just my 2 cents.

[ZigMeowNyan]

@dthree I had to do some other stuff, but I finished and put together a gist for a bootstrapper that installs Node if they're running anything less than 5.7.0 (the latest stable).

I set Compressed to yes so that it would pack the msi inside the exe. This is a preference thing. You can embed the MSI like this or set it to no to have both the exe and the MSI.

So that leaves you with (1) translating the Features into configuration data so that you can read it later to (2) execute a script that applies them.

[dthree]

Thanks, I'll get to this pretty soon and will let you know.

[ZigMeowNyan]

@dthree I did some thinking about the configuration aspect. It seems to me that the simplest approach to translating feature configuration to configuration in a script is by writing to the registry. It requires no additional binaries on the MSI side, and can be read using various node modules (I've seen suggestions for windows or regedit). Each configurable feature that doesn't match up to a deployable file would instead correspond to a registry value in a component. It will also be completely removable on uninstall. This is also a common technique used to store the installation path. What are your thoughts on this? I'm not sure if you're comfortable using the registry in the configuration process. If not, it might mean some ugly hacks with custom actions.

Also, let me know if you're getting hung up on something. You mentioned being able to do the legwork, so I've been focusing on looking up how to implement your needs and providing examples more than doing it for you.

[dthree]

@ZigMeowNyan thanks and I like the registry idea.

---

I apologize for not getting back to you, Cash exploded far faster and bigger than I expected, so I'm trying to keep up with the usage issues that are coming in. As soon as these calm down a bit, I'll be jumping on this!

[ZigMeowNyan]

@dthree No problem. It has hit 3.4K stars in 4 days, so I expect it's kept you quite busy. Just tackle it at your own pace, and drop a mention if you need help.

[dthree]

Haha k thanks.