Add DSC Resource identifier to WinGet manifests

[denelon]

Description of the new feature / enhancement

When I'm trying to author a WinGet configuration file (*.dsc.yaml) it's not easy to discover the DSC resource with the ability to configure the package.

I'd like to have a field in the WinGet manifest with a pointer to a DSC Resource. This would allow WinGet to help configuration file authors locate resources. For example, if a user is adding Visual Studio to a configuration, the manifest for Visual Studio would be able to indicate the "Microsoft.VisualStudio.DSC" module can configure Visual Studio.

Proposed technical implementation details

No response

[denelon]

I've been thinking about something like:

DesiredStateConfiguration:  # optional pointer to DSC resources
  PowerShellModule:         # optional PowerShell Module
  DscResources:             # optional DSC resources
    - DscResource:          # optional DSC resource
  PowerShellRepository:     # optional PowerShell repository

The WinGet community repository would have a policy to only allow the PowerShell Gallery "SourceLocation" for the "PowerShellRepository" key.

During manifest validation, existence checks would be the only initial automated capability until the PowerShell DSC v3 "export" capability is added.

[cdhunt]

This might also be a fix the error message I'm seeing with The module for the configuration unit is available in multiple locations with the same version.. I don't see a way to specify the repository to pull DSC resources from.

[JohnMcPMS]

I'm starting to think that it might be better to leverage the existing DSC document schema to define the set of resources required to extract configuration.

[denelon]

I'm leaning towards the community repository not allowing a mapping of DSC v2 resources until or unless we have the verified developer feature fully deployed. I don't want to run into a situation where fitness for purpose or concerns around the origin of a resource doesn't match the publisher.

I think it may make sense to include this in the schema so organizations with private REST sources can help for their own use cases when they have decided which module is appropriate for a given package, but not for the community repository.

As we're ramping up the work on DSC v3, when that happens, we should be able to add checks in our validation processes to test out the DSC v3 implementation, and if necessary, we can add the metadata for those the same way we do for icons. I think that would only be necessary in some situations, and may be obviated by other configuration work we're doing with DSC.exe.

[JohnMcPMS]

The DSC v3 team is looking at using SWID for this purpose of associating resources and applications. If that route proves fruitful, then adding SWID data to our manifest might be the best way to create a loose coupling between resources and packages. It would also be very nice for correlating packages between sources.

This wouldn't strictly remove the need for more direct mechanisms for pointing to resources, but it would likely be a good best practice.