On dsc 3.3.0-rc.2, asking for a preview of a configuration that removes a registry value fails with Error: JSON: EOF while parsing a value at line 1 column 0. The same document runs fine under config test and config set, and the same --what-if call works if the resource is creating a value rather than removing one.
Here is the document:
$schema: https://aka.ms/dsc/schemas/v3/bundled/config/document.json
resources:
- name: remove the value
type: Microsoft.Windows/Registry
properties:
keyPath: HKCU\Software\DscWhatIfProbe
valueName: V
_exist: falsedsc config set --what-if -f on that gives the error above and nothing else. dsc config validate -f says it is valid, and dsc config test -f runs it and reports state normally, so the document itself is fine.
Changing only _exist to true and adding a valueData makes the same --what-if call work as expected, and it returns the preview you would hope for, including "whatIf":["Key 'DscWhatIfProbe' not found, would create it"]. So --what-if is clearly wired up for this resource in general, and it is specifically the removal case that falls over. I mention that because issue #1529 tracks adding --what-if to built-in resources that do not have it yet, and Microsoft.Windows/Registry is not on that list, presumably because it already does. This looks like a different problem to me rather than part of that work.
I first hit this on 3.2.3 and confirmed it is unchanged on 3.3.0-rc.2.
The reason it matters more than a normal preview gap: removing a value is the one operation you cannot undo by running the configuration again, so it is the one people most want to rehearse first. At the moment a document that removes values is exactly the document --what-if will not describe, and the error gives no clue that removal is the reason, which sent me looking at my document rather than at the operation.
For context on why we generate removals at all, the Windows Group Policy client deletes values rather than blanking them in several ordinary cases, so any tool converting Group Policy into DSC produces _exist: false resources routinely rather than exceptionally.
Environment is Windows 11 Pro 26200, dsc 3.3.0-rc.2 and 3.2.3.
On dsc 3.3.0-rc.2, asking for a preview of a configuration that removes a registry value fails with
Error: JSON: EOF while parsing a value at line 1 column 0. The same document runs fine underconfig testandconfig set, and the same--what-ifcall works if the resource is creating a value rather than removing one.Here is the document:
dsc config set --what-if -fon that gives the error above and nothing else.dsc config validate -fsays it is valid, anddsc config test -fruns it and reports state normally, so the document itself is fine.Changing only
_existtotrueand adding avalueDatamakes the same--what-ifcall work as expected, and it returns the preview you would hope for, including"whatIf":["Key 'DscWhatIfProbe' not found, would create it"]. So--what-ifis clearly wired up for this resource in general, and it is specifically the removal case that falls over. I mention that because issue #1529 tracks adding--what-ifto built-in resources that do not have it yet, andMicrosoft.Windows/Registryis not on that list, presumably because it already does. This looks like a different problem to me rather than part of that work.I first hit this on 3.2.3 and confirmed it is unchanged on 3.3.0-rc.2.
The reason it matters more than a normal preview gap: removing a value is the one operation you cannot undo by running the configuration again, so it is the one people most want to rehearse first. At the moment a document that removes values is exactly the document
--what-ifwill not describe, and the error gives no clue that removal is the reason, which sent me looking at my document rather than at the operation.For context on why we generate removals at all, the Windows Group Policy client deletes values rather than blanking them in several ordinary cases, so any tool converting Group Policy into DSC produces
_exist: falseresources routinely rather than exceptionally.Environment is Windows 11 Pro 26200, dsc 3.3.0-rc.2 and 3.2.3.