The configuration unit was not in the module as expected

[Gijsreyn]

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.

Related: #4021

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 Package Manager v1.8.1911
Copyright (c) Microsoft Corporation. All rights reserved.

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]

@Gijsreyn does the same thing happen with WinGet 1.9?

[janegilring]

It does happen with WinGet 1.9 in my testing

[Gijsreyn]

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

[ddieppa]

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]

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

[denelon]

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

[denelon]

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]

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

[denelon]

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.