Store installed `dsc` breaks executables

[Gijsreyn]

Prerequisites

• [X] Write a descriptive title.
• [X] Make sure you are able to repro it on the latest version
• [X] Search the existing issues.

Summary

When you install DesiredStateConfiguration-Preview using WinGet, the executables that are packaged e.g. registry.exe, cannot be called anymore.

The error message:

I'm not aware of the process behind WinGet, but it looks like the executables should also be registered in the USERPROFILE.

It also became harder to discover the original resources:

if (TestWinGetModule)
{
    # TODO: life is difficult with WinGet
    $version = (GetDscVersion) -replace "preview.", ""
    $architecture = ([System.Runtime.InteropServices.RuntimeInformation]::OSArchitecture).ToString().ToLower()
    $Path = Join-Path $env:ProgramFiles 'WindowsApps' "Microsoft.DesiredStateConfiguration-Preview_3.0.$version.0_$architecture`__8wekyb3d8bbwe" 'dsc.exe'
}

The other side-effect will be for bootsrapping scenario's - Pester tests will fail if called directly.

Steps to reproduce

Install dsc.exe from WinGet and try calling registry.exe.

Expected behavior

Able to call `registry.exe` outside `dsc.exe`

Actual behavior

Unable to call `registry.exe` outside `dsc.exe`

Error details

No response

Environment data

Name                           Value
----                           -----
PSVersion                      7.4.5
PSEdition                      Core
GitCommitId                    7.4.5
OS                             Microsoft Windows 10.0.22631
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

Version

dsc 3.0.0-preview.10

Visuals

No response

[SteveL-MSFT]

So AppStore installed apps don't allow the user to access files that are in the App's home directory, however, dsc.exe itself can. So if you use a config that uses the registry resource, it will still work:

$yaml = @'
$schema: https://raw.githubusercontent.com/PowerShell/DSC/main/schemas/2024/04/config/document.json
resources:
- name: windows product name
  type: Microsoft.Windows/Registry
  properties:
    keyPath: HKLM\Software\Microsoft\Windows NT\CurrentVersion
    valueName: ProductName
'@
dsc config get -d $yaml

However, this does open up a bigger issue where apps installed from the AppStore that contains DSC resources dsc.exe can't discover them currently as the resource manifest can't be accessed. Let me follow up with the Appx/Store team.

[Gijsreyn]

I could have mentioned the fact that dsc.exe was still working.

The ability to fetch schema information from command-based resources that haven't it embedded in the *.dsc.resource.json, allows me to build up data used in PowerShell.

It isn't really related to this issue, but the package in the store doesn't have a version number. I can imagine that it is already on the list or in an issue. If that's the case, please ignore the remark.

Having such information available, helps in scenarios to install/upgrade dsc.exe in a more automated fashion. It's also nice to have the information in the executable properties. Would winres be useful to set the properties?

[SteveL-MSFT]

@Gijsreyn you can always get the version of the Store one using dsc -V. Unfortunately it looks like winget isn't able to get Store installed app version information.

[Gijsreyn]

@SteveL-MSFT Yes I've got that now scripted, but I don't always want to rely on calling dsc -v consistently. Other options would be nice also.

[SteveL-MSFT]

Direct access to supporting exes/files is deliberately restricted by the Store, so this isn't something we can work around

[Gijsreyn]

Hey @SteveL-MSFT, I know this issue has been closed, but I was still thinking about it. Would publishing a package to the Windows Package Management repository be a good idea?

EDIT: Ok, I might have put on the naughty shoes and already submitted the package: https://github.com/microsoft/winget-pkgs/pull/199293.