Hi Sam,
I’ve seen some people using DSC to ‘package’ installation via the use of ScriptResource or composite resource, and I strongly recommend against it!
It mixes Package Installation with State Configuration: not only it ‘feels dirty’ given the workarounds required for some .exe or other badly packaged software, it also mixes the purposes of Configuration definition (a policy) an Installation (a mutation mechanism).
The ideal way would be to use DSC to simply say (like with MSIs), “Package yyy should be installed on Node zzz. Then (DependsOn) Configure it like this …”.
Creating your own resource to wrap around it may sound like a good idea, but truth is, you’ll keep re-working on it, as different packages will have different behaviour. Then there’ll be MUCH to do as there’s more to Package Management (like tracking the binaries, dependency management…).
And this is why Chocolatey is so popular (and created in the first place I suppose), by adding a consistent (in interface, not necessarily in package implementation) abstraction layer, on top of the different installer vendors are known to be creative with…
Since PSv5 you can use the PackageManagement/OneGet provider to install some packages, but it’s only Implementing a ‘ProtoType’ provider which does not support the latest improvement from Chocolatey.
Instead, you’d have better coverage, and future proof your setup by using the Chocolatey installer (there’s a free version).
Eventually, I’ve heard that the Chocolatey Provider might get updated if it’s required: GitHub - chocolatey-community/chocolatey-oneget: OneGet Provider for Chocolatey
In DSC the story is very much the same, the PackageManagement module exposes DSC resources for Chocolatey feeds (whether internal or hosted on Chocolatey.org), or you could use the cChoco DSC resource, which is being worked on more recently by the Chocolatey crew, as it needed some love since it’s birth from the community.
All of this can be done for free, as there’s free version of Chocolatey (and DSC resource is free as well), and you could consume package from the Chocolatey.org gallery, or setup your own internal feed with an open NuGet feed (ProGet also has a free edition).
That said, at my current gig we currently use Chocolatey as an internal self-hosted feed in ProGet (paid version with AD authentication and some other convenient features like connector filtering): https://inedo.com/proget/pricing/features-by-edition.
My current DSC configs uses the PackageManagement Provider, but we’ll be moving to cChoco DSC resource very soon.
We’re seriously looking at Chocolatey Enterprise (the paid version with bells and whistles), because it should drastically reduce the time overhead of ‘internalizing’ packages (recompile package with the local source of the binary, instead of fetching from the www): Redirected
And it has very interesting features to help packaging some dirty installers with less efforts, plus many other features you may or may not benefit from: Redirected and Chocolatey Software | Pricing
So a recap in short, I recommend to:
- Use Chocolatey Packages hosted on a NuGet feed, ProGet is an option
- Package the apps you need using chocolatey (GitHub - chocolatey/choco: Chocolatey - the package manager for Windows)
- Use DSC to define what package should be installed where, and to manage post-installation configuration
- Evaluate Choco Enterprise if you think it’d save you time, and pay itself off
Hope that helps