Consider how we might offer resource code as an ARM resource

Summary of the new feature / enhancement

The intention would be for DSC resources to be published as an ARM resource. The motivation for such as solution would be to eliminate the machine configuration dependency on external artifacts, by modeling resources in ARM and writing them as a control-plane API.

This might be workable, based on Run Command resources. In that model, the script reference can either be in-line code or an external file.
https://learn.microsoft.com/en-us/azure/virtual-machines/windows/run-command-managed#rest-api

Proposed technical implementation details (optional)

For very simple one-liners we could consider passing in the command syntax with the parameter input. This probably would be most useful in audit scenarios. Set scripts are more often complicated but Get scripts can sometimes be quite short.

If we followed the Run Command schema, this is what the json might look like.

{
  "source": {
    "get": "$service = get-service -name $env:Name; @{Name = $service.Name; Status = $service.status}"
  },
  "parameters": {
    "Status": "Running",
    "Name": "bits"
  }
}

So an end-to-end automation command would look something like this.

{"source": {"get": "$service = get-service -name $env:Name; @{Name = $service.Name; Status = $service.status}"},"parameters": {"Status": "Running","Name": "bits"}} | dsc resource

This would require the machine configuration service team to create a new resource type under Microsoft.GuestConfiguration. Then a configuration in JSON format in ARM could reference the script code as a dependency.

Beginne mit der Überprüfung des verlinkten Azure Run Command REST API-Modells und der im Issue beschriebenen Abhängigkeit zwischen Machine Configuration Service und Ressourcentyp. Es werden keine Repository-Dateien oder Tests genannt; für ein ARM-Ressourcenschema, die Verarbeitung von Inline-Skripten und einen durchgängigen dsc-Ressourcenablauf müssten Abschlusskriterien vereinbart werden.