.NET Acquisition Failed: Too many properties to enumerate

[Wintaru]

Does this occur consistently? Yes
Repro steps:

1. Start VS Code with Copilot extension
2. Open Copilot chat window (this seems to trigger the .NET version check)

Action: azextAgent.activate
Error type: Error
Error Message: Failed to acquire .NET runtime. Please report an issue and share the output from the .Net Install Tool output channel.

Version: 0.3.131
OS: darwin
OS Release: 24.3.0
Product: Visual Studio Code
Product Version: 1.97.1
Language: en

Call Stack

extension.bundle.js:2:1834109
fulfilled extension.bundle.js:2:1833204

Using configured .NET path: /usr/local/share/dotnet/dotnet
ms-azuretools.vscode-azure-github-copilot requested to download the .NET ASP.NET Runtime.
Downloading .NET version(s) 8.0.13~arm64~aspnetcore ... Done!
.NET 8.0.13~arm64~aspnetcore executable path: /Users/<myuser>/Library/Application Support/Code/User/globalStorage/ms-dotnettools.vscode-dotnet-runtime/.dotnet/8.0.13~arm64~aspnetcore/dotnet


Error : (DotnetCommandFailed)
Failed to download .NET 8.0.13~arm64~aspnetcore:
.NET Acquisition Failed: Too many properties to enumerate

For what it's worth, from the output it looks like it's actually able to download it but it fails upon installing. I double checked that the dotnet-install.sh script has execute permissions and it does.

[kvenkatrajan]

@nagilson can you have a look please?

[Wintaru]

I should add that this only happens when my .NET version is behind whatever the most current one is, and I can work around it by manually installing the latest SDK.

[nagilson]

Sorry you're facing this, that's interesting -- I think it's working but it's failing at the end? Is GH Copilot actually working ok?

It looks like it put an executable in /Users/<myuser>/Library/Application Support/Code/User/globalStorage/ms-dotnettools.vscode-dotnet-runtime/.dotnet/8.0.13~arm64~aspnetcore/dotnet -- if you try to run that, does it work? Aka, try /Users/<myuser>/Library/Application Support/Code/User/globalStorage/ms-dotnettools.vscode-dotnet-runtime/.dotnet/8.0.13~arm64~aspnetcore/dotnet --info or whatever you need to run the executable.

2nd question:
May you please add another log? Sorry for the inconvenience.
Ctrl + Shift + P (cmd pallette) -> Open Extensions Log Folder -> ms-dotnettools.vscode-dotnet-runtime -> Find the log.txt with the timestamp where you hit this error.

There will be your username and environment in the log, please redact any PII you don't want to share. Alternatively, if you could share just towards the end of the log where it has the error, that may be sufficient.

---

My thoughts:

I looked in telemetry and this error was not one of the most common out of 100 errors, I've never seen this before. It created some huge error object so big it doesn't want to report it lol -- it needs to have at least 65535 properties. If it's writing that out on the log, your log may be massive... so good to delete it afterwards.

Btw, the reason this happens when you have a newer SDK it's OK, is because it won't do the download unless it needs a newer version, (since you set the path setting but it's not new enough for it to work) so you might hit this regardless.

[Wintaru]

@nagilson Hello! It does seem the dotnet command in that path works, but I've also downloaded the latest and installed it manually so I suspect that test may not be very reliable.

As far as the logs go, there is only one in that folder for me and I don't see the error in it at all. The only thing with the string "err" in it that seems relevant was this section:

2/18/2025, 7:59:53 AM CommandExecutionStdError
The command "/usr/local/share/dotnet/dotnet" --info encountered stderr:

I also am not sure this is the log file from when I got this to happen but since I've updated the SDK on my machine and have restarted VS Code I'm not sure that log exists anymore. I could wait for it to happen again and then try searching the log file to see what happened?

[nagilson]

Thank you.

Ah yes, the logs do get cleaned up. If the timestamp doesn't match the VS Code Session (or you didnt open it from the same session) it will not have it. Each session of vscode has its own folder. Go up from that logs dir, there will be a bunch of timestamped folders with sessions. For the right session, then follow back the path to find the log. Btw, each window of vscode has its own folder, window1, window2, etc...

[Wintaru]

@nagilson ok this is kind of wild. I think I found the file in question, but MacOS Gatekeeper wouldn't let me open it because it suspected malware for some reason. I had to go to Securty & Privacy to allow it to be opened. I hope I scrubbed whatever stuff from this file that needs to be, but this seems to show the error at least.

DotNetAcquisition-ms-dotnettools.vscode-dotnet-runtime-1739885688022.txt

[nagilson]

Thank you.

Sorry to ask more questions! If you try to use the uninstall command (ctrl shift p -> uninstall .NET) do you see the runtime that was added after this bug occurs (immediately after.)

And can you try this when launching vscode from the terminal and running this beforehand: export NODE_OPTIONS="--max-old-space-size=8192"

--

It looks like this is failing to add the install to the 'installed' list. Then some generic thing throws a MASSIVE error that is too big to hold in memory. I can garner this because the install script sees that its installed, but the extension doesn't know its installed even though the last 2 things it does is verify it works (which it did successfully) then add it to the in memory set of installed things.

The only reasons I could see why:

fs.writeFileSync('/Users/<myuser>/.vscode/extensions/ms-dotnettools.vscode-dotnet-runtime-2.2.8/dist/installed.lock', '', 'utf-8'); is failing and throwing some massive error object up the callstack? Very weird because it was able to write to it before. Wonder if GateKeeper is causing a problem?

calling .delete on a set object is failing (docs don't show that this would be an issue)

NODE_OPTIONS=--stack-trace-limit is set to Infinity, so when it fails to acquire the lock it explodes. Don't think so since you didn't set that according to the log.

[Wintaru]

If you try to use the uninstall command (ctrl shift p -> uninstall .NET) do you see the runtime that was added after this bug occurs (immediately after.)

I sure can do these things @nagilson , can you elaborate on this one here? I'm not sure what to do to "see the runtime that was added". Otherwise I think I can handle most of the rest of this, just wanted clarification on this point before I start doing things.

[nagilson]

Thank you!

If you open the command palette (ctrl shift p) and search for the uninstall .NET command, it will show a list of runtimes and sdks it knows its installed

If it shows up in this list then that'd be interesting but I dont think it will.

[Wintaru]

@nagilson Gotcha. Weirdly, several versions don't show up, I guess you can see right where I started having the problem. I think I'm currently running 8.0.13.

[nagilson]

Nice, hopefully with those settings it will show the full stack frame so it actually shows the error