DSC icon indicating copy to clipboard operation
DSC copied to clipboard

Synthetic export should re-export `name`

Open michaeltlombardi opened this issue 3 months ago • 0 comments

Summary of the new feature / enhancement

As a user exporting a resource that relies on the synthetic export feature, I want the exported resource instance to keep the same name as the input resource instance from my configuration document, so that the meaningful name from the input instance is kept in the export configuration.

Edit: Currently, any instances of a resource exported synthetically share the same name across the exported instances, which is invalid. For example, given the following input configuration:

$schema: https://aka.ms/dsc/schemas/v3/bundled/config/document.json
resources:
  - name: NoExportTwo
    type: Test/Get
    properties:
      name: two
  - name: NoExportThree
    type: Test/Get
    properties:
      name: three

DSC returns the following (invalid) exported configuration document:

$schema: https://aka.ms/dsc/schemas/v3/bundled/config/document.json                                                                                           
contentVersion: 1.0.0
resources:
- type: Test/Get
  name: Get-0
  properties:
    name: two
    id: 2
- type: Test/Get
  name: Get-0
  properties:
    name: three
    id: 3
metadata:
  Microsoft.DSC:
    version: 3.2.0-preview.5
    operation: export
    executionType: actual
    startDatetime: 2025-09-18T15:46:53.555975200-05:00
    endDatetime: 2025-09-18T15:47:03.531802400-05:00
    duration: PT9.9758272S
    securityContext: restricted

Proposed technical implementation details (optional)

The current implementation of the add_resource_export_results_to_configuration() function doesn't have a way to pass the name of the input instance. The function currently handles either hoisting the _name property or creating a default generatedf name:

https://github.com/PowerShell/DSC/blob/3f98ff71a5bcfc4fabc801a25b7f3c8e22bc8c1e/dsc_lib/src/configure/mod.rs#L79-L90

If the add_resource_export_results_to_configuration() function included another parameter as an option, like:

pub fn add_resource_export_results_to_configuration(
    resource: &DscResource,
    conf: &mut Configuration,
    input: &str,
    instance_name: Option<&str>,
) -> Result<ExportResult, DscError> {

We could then update the code to check for instance_name and whether the resource is using synthetic export:

r.name = if let Some(name) = props.remove("_name") {
    name.as_str()
        .map(std::string::ToString::to_string)
        .ok_or_else(|| DscError::Parser(t!("configure.mod.propertyNotString", name = "_name", value = name).to_string()))?
} else if instance_name.is_some() && &resource.manifest.export.is_none() {
    instance_name.unwrap().to_string()
} else {
    let resource_type_short = if let Some(pos) = resource.type_name.find('/') {
        &resource.type_name[pos + 1..]
    } else {
        &resource.type_name
    };
    format!("{resource_type_short}-{i}")
};

This would require plumbing the change through wherever add_resource_export_results_to_configuration() is called. Otherwise, it should have minimal impact.

michaeltlombardi avatar Sep 18 '25 20:09 michaeltlombardi