VSCodeInstaller DSC class-based resource

[Gijsreyn]

• I have signed the Contributor License Agreement.
• This pull request is related to an issue.

---

It would have made sense if we are doing things with VSCode extensions, there would be an installer. First draft of documentation up. Let me know your thoughts @denelon and @ryfu-msft

[ryfu-msft]

What is the benefit of this DSC resource as opposed to using the WinGetPackage DSC resource to install vscode through winget? Winget does a better job at handling the installer and ensuring the installer url is valid, secure, and up to date. These are my main concerns about this DSC resource and whether it will be easily maintainable moving forward. I'd rather not have to reinvent the wheel here if it's not absolutely necessary. Just my opinion though... I'll let @denelon share his thoughts as well.

[Gijsreyn]

Mhm... I know there are talks around WinGet and Linux. Even thought the resource doesn't have it, the only benefit would be cross-platform (MacOs/Linux included).

[denelon]

I think there is a philosophical debate to resolve. We're at the edge of blurring the lines between package management and configuration management. Configuration as Code and Infrastructure as Code don't have "hard" boundaries.

In terms of a declarative configuration file, I'd want to understand some of the separation of concern. On Windows, I'd expect DSC Resources to handle a single concern. This would follow the concept of SOLID OO principles. I'd expect a package manager would handle packages so I'd imagine on Windows you would likely have one of the package managers handle installing things, and given WinGet as the orchestrator (on Windows), that seems a natural fit for "installing/uninstalling/upgrading/downgrading" things. It could certainly be used to install another package manager like Chocolatey, Scoop, or any other package manger and then use a DSC Resource for the other package manager to handle package management.

In the cross-platform world, I would assume DSC.exe would be the orchestrator, and we'd need resources capable of installing other package managers or using the OS native package manager for package management.

Logically the package manager ensures the package is installed, then the package acts as its own DSC Resource for configuration. I wouldn't want to see the massive amounts of duplicated code across all DSC resources, so they have different ways of installing the thing they intend to be used to configure.

I'd be happy to coordinate a meeting/call for anyone interested in discussing ideas and approaches.

[denelon]

I've been in discussions with some of the DotNet folks about cross platform scenarios as well. It might be worth a new GitHub discussion if we want to keep things outside of this PR and we can promote the discussion to get others involved. I'd expect @claudiaregio, @SteveL-MSFT, and @craigloewen-msft would all be interested.

[denelon]

I'd be very interested in pulling a POC together to demonstrate the usage of other package managers and configurations across multiple OSs.

[Gijsreyn]

Let's do it @denelon! Really appreciated the detailed philosophical explanation. Would love to have a talk on it.