Chocolatey CLI MSI

[JPRuskin]

We've seen some customer interest in having an MSI method for installation of Chocolatey (and eventually the related packages and services), but it would be great to gather some data on what users want out of it!

Current Plan: Chocolatey

• MSI installer for Chocolatey
• Allows silent installation, accepting arguments for
  • Install Location
  • ToolsDir
  • Accepting the Chocolatey license

Sample Usage

Standard installation via GUI

Selecting install location and optional configuration (e.g. profile)

# Basic silent install
msiexec /qn /i C:\Temp\Chocolatey-1.1.0.msi /l*v C:\Temp\chocolateyInstall.log ACCEPTLICENSE=YES

# Specify a different location to install to
msiexec /qn /i C:\Temp\Chocolatey-1.1.0.msi ACCEPTLICENSE=YES INSTALLDIR='C:\Some\Directory\Choco'

What do you think? Is there anything missing?

[TheCakeIsNaOH]

• I presume all the required files are embedded inside the .msi so this can be installed offline?
• Is there an option to switch between 7zip and built-in compression for extracting the .nupkg, or the .nupkg not used?
• How does this show up in Programs & Features, assuming it does at all?
• This is perhaps outside the scope of the MSI, but what happens if there is a pre-existing install? What changes if it is older/newer version already installed. What if the install is "broken", e.g. just an empty folder, or missing choco.exe or similar?

[JPRuskin]

Hey! Thank you for the response!

• Correct, this would be suited to completely offline installation
• I believe the current plan would be to offer a separate non-7z version of the installer, similar to what we do currently with Chocolatey
• It would show up as Chocolatey, with a version (need to double check that I shouldn't change this to Chocolatey CLI)
• I have considered this. Currently the answer is that it doesn't handle it properly, but it's something I would like to fix and am driving conversation towards - the main issue is that the installer is currently a wrapper for the current installer script, empty-directory-handling-and-all. Moving to an alternate (harder to maintain but better MSI practice) way of creating the installer would allow for self-healing installations, repairs, handling existing upgrades, etc.

[TheCakeIsNaOH]

• Correct, this would be suited to completely offline installation
• I believe the current plan would be to offer a separate non-7z version of the installer, similar to what we do currently with Chocolatey

Perfect, exactly what I was hoping to hear.

It would show up as Chocolatey, with a version (need to double check that I shouldn't change this to Chocolatey CLI)

Ok, that is what I would generally expect.

What happens with existing Chocolatey (non-MSI) installations? I presume a one use case for this installer is to allow users that have a pre-existing RMM (or similar) tool already deployed to use that tool to install this MSI. At least some of those tools figure out what is already installed exclusively via Programs & Features, so the tool would try to install Chocolatey via the MSI, even if it is already installed the normal way. Perhaps a feature could be added to Chocolatey CLI open source to make it show up in Programs & Features?

• I have considered this. Currently the answer is that it doesn't handle it properly, but it's something I would like to fix and am driving conversation towards - the main issue is that the installer is currently a wrapper for the current installer script, empty-directory-handling-and-all. Moving to an alternate (harder to maintain but better MSI practice) way of creating the installer would allow for self-healing installations, repairs, handling existing upgrades, etc.

Hmm, perhaps could the existing install script be enhanced to allow for these cases?

[JPRuskin]

Hmm, perhaps could the existing install script be enhanced to allow for these cases?

It could, but there's a certain amount of protection in the current method - "thou shalt not modify a potential existing configuration / install" seems to be the message I've seen used.

We could build a lot more checking in there, but there's something quite clean about asking users to please manually ensure they're really sure before installing [with the basic install script].

We began by using this method because we didn't really want to have to maintain two separate potential installation methods, but I would like to argue that us using a more MSI-specific method to create our MSIs may well pay off in the long run, even if it takes a little more maintenance (and means we have to ensure that future PRs that touch the Install script must update our MSI build logic).

[TheCakeIsNaOH]

It could, but there's a certain amount of protection in the current method - "thou shalt not modify a potential existing configuration / install" seems to be the message I've seen used.

Yup, which is why this is a larger conversation.

but I would like to argue that us using a more MSI-specific method to create our MSIs may well pay off in the long run, even if it takes a little more maintenance (and means we have to ensure that future PRs that touch the Install script must update our MSI build logic).

Which would relegate the install.ps1 to being a second class citizen, as it would not be able to repair a broken installation of Chocolatey (or update Chocolatey, etc).

[Daxx23]

I would definitely like to see a .msi installer for Chocolatey components, especially for Choco Central Management.
This would allow for IT-personnel to install these Chocolatey components without having intimate knowledge of PowerShell and/or the Choco CLI. I'm trying to bring my colleagues up to speed on C4B implementations and all the CLI commands is turning out to be a big threshold. Even though they have knowledge of how PowerShell works, having a next-next-finish .msi installer for manual installations of Chocolatey would help in some situations.

For mass deployments to endpoints like we do with Intune, I'm fine with using Choco packages and PowerShell scripts to install the Chocolatey components, as those PS scripts only had to be written once and can be reused for each customer environment we implement Chocolatey for Business. But to install e.g. a singular Admin Workstation it would make more sense to use a .msi installer. In our case such Admin Workstations are set-up in each customer environment, usually centralized on a management server.

The step where I have to manually create the C:\ProgramData\Chocolatey\License folder and copy the .xml C4B license over is prone to errors and such. I would suggest including an option in this .msi to point to the C4B license for a C4B installation, so it will automatically create the license folder, place the license file and install the licensed extension.

But having implemented CCM a couple of times now, that surely could use a .msi installer to set everything up as well.

[pauby]

@Daxx23 Would you be willing to drop me a DM over on Discord (name is pauby over there too)? Or we can use another medium if we can swap communication details privately)? I'd like to have a chat about your experiences above (apologies for only coming back to this 5 months later 🤦).

[pauby]

Just to be clear, the discussion here is just for Chocolatey CLI and not Licensed Extension or CCM. That isn't to say they woul come along at a later date, but for any initial release it would be just CLI.

The step where I have to manually create the C:\ProgramData\Chocolatey\License folder and copy the .xml C4B license over is prone to errors and such.

We would suggest that you create a license package and distribute it that way. The docs I provided link to the solution for the Chocolatey For Business Azure Environment and was to demonstrate the concept. If you are going to follow them verbatim, you will need to amend them accordingly.

[pauby]

We have published a Chocolatey CLI MSI for version 2.0.0. We'll publish an MSI for future stable releases only. We'll also be looking to create MSI versions of other Chocolatey products in future.

The Chocolatey CLI MSI is also being used for the WinGet package.

As this is now complete, I'll go ahead and close it.