The configuration unit was not in the module as expected

Gijsreyn commented 3 weeks ago

Brief description of your issue

When applying the following on a fresh created Hyper-V box through DevHome:

#configure.devbox.config.yaml
properties:
  resources:
  - resource: Microsoft.WinGet.DSC/WinGetPackage
    directives:
      description: Installing Git
      allowPrerelease: true
    settings:
      id: "Git.Git"
      source: winget
    id: Git.Git | Git
  - resource: GitDsc/GitClone
    directives:
      description: 'Cloning: winget-dsc.git'
      allowPrerelease: true
      securityContext: current
    settings:
      httpsUrl: https://github.com/microsoft/winget-dsc.git
      rootDirectory: C:\Repos\winget-dsc.git
    id: 'Clone winget-dsc.git: C:\Repos\winget-dsc.git'
    dependsOn:
    - Git.Git | Git
  configurationVersion: 0.2.0

I get the error: The configuration unit was not in the module as expected.

Steps to reproduce

Create Hyper-V box through DevHome with default settings. Create a file with the above and execute winget configure configure.devbox.config.yaml --accept-configuration-agreements

Expected behavior

Clone repository on C:\repos

Actual behavior

The configuration unit was not in the module as expected.

Environment

Windows: Windows.Desktop v10.0.22621.3880 System Architecture: X64 Package: Microsoft.DesktopAppInstaller v1.23.1911.0

Winget Directories

Logs %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\Diag… User Settings %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\sett… Portable Links Directory (User) %LOCALAPPDATA%\Microsoft\WinGet\Links Portable Links Directory (Machine) C:\Program Files\WinGet\Links Portable Package Root (User) %LOCALAPPDATA%\Microsoft\WinGet\Packages Portable Package Root C:\Program Files\WinGet\Packages Portable Package Root (x86) C:\Program Files (x86)\WinGet\Packages Installer Downloads %USERPROFILE%\Downloads

Links

Privacy Statement https://aka.ms/winget-privacy License Agreement https://aka.ms/winget-license Third Party Notices https://aka.ms/winget-3rdPartyNotice Homepage https://aka.ms/winget Windows Store Terms https://www.microsoft.com/en-us/storedocs/terms-of-sale

Admin Setting State

LocalManifestFiles Disabled BypassCertificatePinningForMicrosoftStore Disabled InstallerHashOverride Disabled LocalArchiveMalwareScanOverride Disabled ProxyCommandLineOptions Disabled DefaultProxy Disabled

denelon commented 3 weeks ago

@Gijsreyn does the same thing happen with WinGet 1.9?

janegilring commented 3 weeks ago

It does happen with WinGet 1.9 in my testing

Gijsreyn commented 3 weeks ago

Was about to open up the Hyper-V box, but thanks for checking already @janegilring!

ddieppa commented 3 weeks ago

Same happening to me using winget v1.9.2411-preview in Windows 11 Version 23H2 (OS build 22631.4391)

Error:

Apply :: WinGetPackage [Ditto.Ditto]
  The configuration unit was not in the module as expected.

I did run winget configure validate --file .\apps.dsc.yaml and winget configure test --file .\apps.dsc.yaml and both were succesfull. this is the file content:

# yaml-language-server: $schema=https://aka.ms/configuration-dsc-schema/0.2
# Reference: https://github.com/microsoft/winget-create#building-the-client
# WinGet Configure file Generated By Dev Home.

properties:
  configurationVersion: 0.2.0
  resources:
  - resource: Microsoft.WinGet.DSC/WinGetPackage
    directives:
      description: Installing Ditto.Ditto
      allowPrerelease: false
      securityContext: current
    settings:
      id: "Ditto.Ditto"
      source: winget
    id: Ditto.Ditto
  - resource: Microsoft.WinGet.DSC/WinGetPackage
    directives:
      description: Installing Microsoft.PowerToys
      allowPrerelease: false
      securityContext: current
    settings:
      id: "Microsoft.PowerToys"
      source: winget
    id: Microsoft.PowerToys
  - resource: Microsoft.WinGet.DSC/WinGetPackage
    directives:
      description: Installing ShareX.ShareX
      allowPrerelease: false
      securityContext: current
    settings:
      id: "ShareX.ShareX"
      source: winget
    id: ShareX.ShareX

JohnMcPMS commented 3 weeks ago

I've found the issue (fixed in #4932 ) and we are working to release that fix as soon as possible.

denelon commented 3 weeks ago

As soon as the updated Microsoft.WinGet.DSC module is published, we will provide instructions to address devices in the bad state.

denelon commented 3 weeks ago

We've published https://www.powershellgallery.com/packages/Microsoft.WinGet.DSC/1.9.25190

New WinGet 1.9 users who have not yet run a configuration shouldn't hit the bug.

If users have encountered this bug there will be manual steps needed to mitigate the issue until our next updated version of WinGet. I'll add the instructions here as soon as we've validated them.

janegilring commented 3 weeks ago

I can confirm that the issue is resolved when provisioning new machines using version 1.9.25190

denelon commented 1 week ago

OK, it's taken a while to get devices into the broken state so we could offer a workaround.

The fix is to get the latest version of the Microsoft.WinGet.DSC module updated in the effective path for WinGet. In my case, I used the following command substituting my username: Save-Module Microsoft.WinGet.DSC -Path "C:\Users\<username>\AppData\Local\Microsoft\WinGet\Configuration\Modules.

If you run the WinGet Configuration in verbose mode, you will find the "effective path" for where the older module is saved in the logs. You shouldn't need to delete it, but if you want to keep that directory clean, you can remove the older version of the module.

microsoft / winget-cli