Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Store installed dsc breaks executables #559

Open
3 tasks done
Gijsreyn opened this issue Sep 26, 2024 · 4 comments
Open
3 tasks done

Store installed dsc breaks executables #559

Gijsreyn opened this issue Sep 26, 2024 · 4 comments
Labels
Issue-Bug Something isn't working Need-Review

Comments

@Gijsreyn
Copy link
Contributor

Gijsreyn commented Sep 26, 2024

Prerequisites

  • Write a descriptive title.
  • Make sure you are able to repro it on the latest version
  • 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:

image

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

image

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

@Gijsreyn Gijsreyn added Issue-Bug Something isn't working Need-Review labels Sep 26, 2024
@SteveL-MSFT
Copy link
Member

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.

@SteveL-MSFT SteveL-MSFT changed the title WinGet install breaks executables Store installed dsc breaks executables Sep 26, 2024
@Gijsreyn
Copy link
Contributor Author

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?

image

@SteveL-MSFT
Copy link
Member

SteveL-MSFT commented Oct 1, 2024

@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
Copy link
Contributor Author

Gijsreyn commented Oct 3, 2024

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Issue-Bug Something isn't working Need-Review
Projects
None yet
Development

No branches or pull requests

2 participants