Demitrius Nelon

@Ramshu it looks like you may not have "installed" the module before trying to run the cmdlet. Try running `Install-Module Microsoft.WinGet.Client` before trying to run `Repair-WinGetPackageManager -Force -Latest`.

@StevenBucher98 I'd be more than happy to collaborate to figure out what we can do here. Maybe there is a switch we can pass to the installer or something else...

Did you use the WinGet Configuration file to set up your environment? (I don't think this would have any bearing, but I'm asking out of curiosity on how you set...

The "relative" path part is specifically to make sure the .vsconfig file is captured from the project's relative path. It should just be adding workloads and other components necessary to...

I just did a quick search, and this is what the AI told me. I don't know if that's absolutely correct, but it might be worth trying a shorter path....

There are some other folks who have been looking at the "long tail" problems with long path support. I'll pass this thread along to them as another solid datapoint on...

Was the configuration run in a "user" context? There should have been a UAC (User Account Control) trigger after accepting the configuration agreement.

Can you share the output from `winget features`?

I ran the configuration on my local machine and it did succeed. I'm spinning up a VM to see if I can repro in Hyper-V.

OK, I was able to repro this. @SteveL-MSFT is this something you've seen before? Given WinGet is leveraging the DSCR_FileContent/TextFile resource in this configuration, I'm wondering if it's an issue...