Open boylec opened 2 years ago
launch.json config below
note: both of these configurations result in the same symptoms described above, the latter merely launches the function app before attempting to attach.
{
"version": "0.2.0",
"configurations": [
{
"name": ".NET Core Attach",
"type": "coreclr",
"request": "attach",
"targetArchitecture": "x86_64"
},
{
"name": "Attach to .NET Functions",
"type": "coreclr",
"request": "attach",
"processId": "${command:azureFunctions.pickProcess}",
"targetArchitecture": "x86_64"
},
]
}
Can you hit a breakpoint anywhere in your code?
If so: does the process stick around while you are broken?
If you can't hit a breakpoint: can you confirm that your code is running and the debugger is attached to your process? You can output the current process id, and compare that to the process id logged in the process
event in the engine log
Also, including the engine log in this issue may be helpful.
Myself and 2 other members of our team are experiencing this as well.
Similar to @boylec, the function host starts up, debugger attempts to attach and then immediately fails. The Function host continues to run successfully so I suspect this is more so around attaching to the process.
I've attempted to attach to the func
process by ID directly which has a similar behaviour of connecting and then immediately disconnecting.
We're all running the same setup:
OmniSharp Log:
Function Host Logs:
I am experiencing the same issue. I configured detailed debugging and had VSCode connect to a running vsdbg-ui
binary so I could see the output there. Output seems normal until the debugger establishes a connection and vsdbg-ui
terminates with a Killed: 9
and nothing else.
Workaround for now is to operate remotely in a Linux-based container environment. This appears to be a MacOS specific issue.
Can someone post the debugger log (instructions) in case that gives me any guesses.
Can someone post the debugger log (instructions) in case that gives me any guesses.
david@Davids-MacBook-Pro x86_64 % ./vsdbg-ui --server --consoleLogging
Waiting for communication on port 4711...
>> accepted connection from client
-> (C) {"command":"initialize","arguments":{"clientID":"vscode","clientName":"Visual Studio Code","adapterID":"coreclr","pathFormat":"path","linesStartAt1":true,"columnsStartAt1":true,"supportsVariableType":true,"supportsVariablePaging":true,"supportsRunInTerminalRequest":true,"locale":"en-gb","supportsProgressReporting":true,"supportsInvalidatedEvent":true,"supportsMemoryReferences":true},"type":"request","seq":1}
<- (R) {"seq":1,"type":"response","request_seq":1,"success":true,"command":"initialize","body":{"supportsConfigurationDoneRequest":true,"supportsFunctionBreakpoints":true,"supportsConditionalBreakpoints":true,"supportsHitConditionalBreakpoints":true,"supportsEvaluateForHovers":true,"exceptionBreakpointFilters":[{"filter":"all","label":"All Exceptions","description":"Break when an exception is thrown. For more information about exception settings, see: https://aka.ms/VSCode-CS-ExceptionSettings","default":false,"supportsCondition":true,"conditionDescription":"Comma-separated list of exception types to break on, or if the list starts with '!', a list of exception types to ignore. \nExample 1: System.NullReferenceException -- this will break on just null reference exceptions. \nExample 2: !System.Threading.Tasks.TaskCanceledException -- this will break on all exceptions except for task canceled.\n\nFor more information about exception settings, see: https://aka.ms/VSCode-CS-ExceptionSettings"},{"filter":"user-unhandled","label":"User-Unhandled Exceptions","description":"Break when an exception is caught in non-user code (system code) after having passed through user code. For more information about exception settings, see: https://aka.ms/VSCode-CS-ExceptionSettings","default":true,"supportsCondition":true,"conditionDescription":"Comma-separated list of exception types to break on, or if the list starts with '!', a list of exception types to ignore. \nExample 1: System.NullReferenceException -- this will break on just null reference exceptions. \nExample 2: !System.Threading.Tasks.TaskCanceledException -- this will break on all exceptions except for task canceled.\n\nFor more information about exception settings, see: https://aka.ms/VSCode-CS-ExceptionSettings"}],"supportsSetVariable":true,"supportsGotoTargetsRequest":true,"supportsModulesRequest":true,"supportedChecksumAlgorithms":["MD5","SHA1","SHA256"],"supportsExceptionOptions":true,"supportsValueFormattingOptions":true,"supportsExceptionInfoRequest":true,"supportTerminateDebuggee":true,"supportsSetExpression":true,"supportsReadMemoryRequest":true,"supportsCancelRequest":true,"supportsExceptionFilterOptions":true,"supportsExceptionConditions":true,"supportsLoadSymbolsRequest":true,"supportsModuleSymbolSearchLog":true,"supportsDebuggerProperties":true,"supportsSetSymbolOptions":true,"supportsHitBreakpointIds":true,"supportsVsIndividualBreakpointOperations":true,"supportsVsBreakpointLanguage":true,"supportsSetHitCount":true,"supportsVsCustomMessages":true,"supportsEvaluationOptions":true,"supportsExceptionStackTrace":true,"memoryReferencesAreAddresses":true,"supportsObjectFavorites":true,"supportsObjectId":true,"supportsVariableEnumerators":false}}
-> (C) {"command":"initialize","arguments":{"clientID":"vscode","clientName":"Visual Studio Code","adapterID":"coreclr","pathFormat":"path","linesStartAt1":true,"columnsStartAt1":true,"supportsVariableType":true,"supportsVariablePaging":true,"supportsRunInTerminalRequest":true,"locale":"en-gb","supportsProgressReporting":true,"supportsInvalidatedEvent":true,"supportsMemoryReferences":true},"type":"request","seq":1}
-> (C) {"command":"attach","arguments":{"name":"Attach to .NET Functions","type":"coreclr","request":"attach","processId":"12237","targetArchitecture":"x86_64","debugServer":4711,"__configurationTarget":5,"__sessionId":"ee5e8c56-60ea-4c30-b467-9ce46ec66c90"},"type":"request","seq":2}
<- (E) {"seq":4,"type":"event","event":"output","body":{"category":"console","output":"-------------------------------------------------------------------\nYou may only use the Microsoft .NET Core Debugger (vsdbg) with\nVisual Studio Code, Visual Studio or Visual Studio for Mac software\nto help you develop and test your applications.\n-------------------------------------------------------------------\n","severity":"ok"}}
<- (R) {"seq":5,"type":"response","request_seq":2,"success":true,"command":"attach"}
<- (E) {"seq":6,"type":"event","event":"initialized","body":{}}
-> (C) {"command":"setBreakpoints","arguments":{"source":{"name":"HttpTrigger1.cs","path":"/Users/david/Prototypes/func-net6/HttpTrigger1.cs","checksums":[{"algorithm":"SHA1","checksum":"0e2094784b9cba668d8096895ac090f1eef7ced1"},{"algorithm":"SHA256","checksum":"3eada0a066aeb8b4434aaf8a5e6abb699d5b032dcbc9712653c950c8b61b9a4c"},{"algorithm":"SHA1","checksum":"d0f19213a2784f84967250bb450043234ee04345"},{"algorithm":"SHA256","checksum":"a3c715f7f55271c703f91d694b0376476a7b6f1ca4370e0a668a50473f9950e4"}]},"lines":[20],"breakpoints":[{"line":20}],"sourceModified":false},"type":"request","seq":3}
<- (R) {"seq":7,"type":"response","request_seq":3,"success":true,"command":"setBreakpoints","body":{"breakpoints":[{"id":1,"verified":false,"message":"The breakpoint is pending and will be resolved when debugging starts.","line":20}]}}
-> (C) {"command":"setFunctionBreakpoints","arguments":{"breakpoints":[]},"type":"request","seq":4}
<- (R) {"seq":8,"type":"response","request_seq":4,"success":true,"command":"setFunctionBreakpoints","body":{"breakpoints":[]}}
-> (C) {"command":"setExceptionBreakpoints","arguments":{"filters":[],"filterOptions":[{"filterId":"user-unhandled"}]},"type":"request","seq":5}
<- (R) {"seq":9,"type":"response","request_seq":5,"success":true,"command":"setExceptionBreakpoints","body":{"breakpoints":[{"verified":true}]}}
-> (C) {"command":"configurationDone","type":"request","seq":6}
zsh: killed ./vsdbg-ui --server --consoleLogging
I hope this is more useful to you than it is to me!
Not much, but a little bit. What I believe this says is that, during the attach, some native code in the vsdbg-ui process is crashing.
These instructions are a bit old, but can you see if there is anything logged in crash reporter? Instructions
@gregg-miskelly Not sure what you're referring to in the crash reporter. I followed the "full method" instructions on that link you sent in.
Can you hit a breakpoint anywhere in your code? If so: does the process stick around while you are broken? If you can't hit a breakpoint: can you confirm that your code is running and the debugger is attached to your process? You can output the current process id, and compare that to the process id logged in the
process
event in the engine logAlso, including the engine log in this issue may be helpful.
I've switched to the dotnet-isolated target for my Azure functions and am able to run those with "func start" from the terminal (rather than using Azure Function extension in VS Code) and then attach directly to the process in VS Code with no problems.
Before, when my function target was "dotnet" vs "dotnet-isolated", my debugger was not breaking on breakpoints. (As per your question)
@gregg-miskelly Not sure what you're referring to in the crash reporter. I followed the "full method" instructions on that link you sent in.
@davec643: Sorry, I think the killed
line in your output is because something in the vsdbg-ui process is calling abort
(or similar), so I am hoping that macOS`s Crash Reporter might give some indication as to what is doing so.
@gregg-miskelly When vsdbg-ui is killed, it doesn't seem to log anything to the Crash Reporter.
When I run the debugger via Rider, I get a "dotnet quit unexpectedly" crash report, which has some details below. It's hard to say if it's the same issue, but it behaves similarly. The main exception seems to be "EXC_BAD_ACCESS (Code Signature Invalid)"
I was triggered by a log line about code signing in the logging above. I therefore tried the following:
~/.vscode/extensions/ms-dotnettools.csharp-1.24.4-darwin-x64/.debugger/x86_64
)codesign --remove-signature vsdbg-ui && codesign --remove-signature vsdbg
codesign -s my-codesign-cert vsdbg-ui && codesign -s my-codesign-cert vsdbg
I can now attach to a running instance of ./vsdbg-ui --server --consoleLogging --engineLogging
from VS Code that stops at breakpoints. It's a work-around, but it shows something is wrong with the code signing of vsdbg
and/or vsdbg-ui
.
2022-04-20: can confirm that this still works, using OmniSharp 1.24.4.
I was having a similar issue when running Azure Durable Function code locally and @basilfx's workaround seems to have fixed my issue as well. I should note that this does not appear to be tied directly to netcore 6.0 as I only have 3.1 installed.
Environment: MacOS - Monterey VSCode - 1.63 Azure Functions Extension - 1.6.0 C# Extension - 1.23.17 NetCore - 3.1.416
I am also experiencing this issue! @basilfx's workaround works for me as well. I'm not incredibly familiar with how these codesigning certificates work though. Will we need to undo the workaround manually once a fix is published to the extension, or will it just be overwritten?
Environment: MacOS - Monterey 12.1 on Intel (x86) VSCode - 1.63.2 Azure Functions Extension - 1.6.0 C# Extension - 1.23.17 .NET - 6.0.1
I was triggered by a log line about code signing in the logging above. I therefore tried the following:
- Create self-signed code signing certificate: https://stackoverflow.com/a/58363510/1423623
- Navigate to the debugger folder (in my case, /Users/basilfx/.vscode/extensions/ms-dotnettools.csharp-1.23.18/.debugger/x86_64)
- Run
codesign --remove-signature vsdbg-ui && codesign --remove-signature vsdbg
- Run
codesign -s my-codesign-cert vsdbg-ui && codesign -s my-codesign-cert vsdbg
I can now attach to a running instance of
./vsdbg-ui --server --consoleLogging --engineLogging
from VS Code that stops at breakpoints. It's a work-around, but it shows something is wrong with the code signing ofvsdbg
and/orvsdbg-ui
.
I had the exact same problem on iMac (OS 12.1). I copied by local git repo to my Macbook (OS 12.0.1) and it worked just fine. So it looks like the issue might be with Monterey 12.1.
The workaround from @basilfx fixed my iMac.
I had the same issue. re-signing the vsdbg and vsdbg-ui, resolved it for me as well.
The workaround that @basilfx suggested does not seem to be working on an M1 machine with macOS Montery 12.2.
This seems a bit better in the latest .NET release (M1 Pro, macOS Monterey 12.3). I'm tentatively optimistic that this has been fixed (at least for the most part).
Version: 6.0.201
Commit: ef40e6aa06
Runtime Environment:
OS Name: Mac OS X
OS Version: 12.3
OS Platform: Darwin
RID: osx.12-arm64
Base Path: /usr/local/share/dotnet/sdk/6.0.201/
Host (useful for support):
Version: 6.0.3
Commit: c24d9a9c91
.NET SDKs installed:
6.0.100 [/usr/local/share/dotnet/sdk]
6.0.101 [/usr/local/share/dotnet/sdk]
6.0.200 [/usr/local/share/dotnet/sdk]
6.0.201 [/usr/local/share/dotnet/sdk]
.NET runtimes installed:
Microsoft.AspNetCore.App 6.0.0 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 6.0.1 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 6.0.2 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 6.0.3 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.NETCore.App 6.0.0 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
Microsoft.NETCore.App 6.0.1 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
Microsoft.NETCore.App 6.0.2 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
Microsoft.NETCore.App 6.0.3 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
Hi, have you any progress on this? I just makes me crazy:) Thanks
Any infos on that issue?
Any updates?
@basilfx Thanks for the research on that. This temporary work around did resolve the issue for me.
Before applying @basilfx's fix: updating Azure Function Core Tools 4.0.4426 and to .NET SDK 6.0.201 (both are the latest at the time of this post) did not resolve this issue for me.
Although I suppose they wouldn't if the problem is code signing on the vsdbg-ui and vsdbg binaries that come packaged w/ the Omnisharp extension?
Updating the Omnisharp extension to v1.24.3 (also the latest at the time of this post) did not resolve the issue either.
Doing that reset the code signing problem on vsdbg and vsdbg-ui as might be expected (undid the previous fix I had applied from @basilfx's suggestion).
I had to reapply @basilfx's fix to the new binaries at /Users/me/.vscode/extensions/ms-dotnettools.csharp-1.24.3-darwin-x64/.debugger/x86_64/*
@basilfx 's workaround worked for me! thanks mate!
am running:
@basilfx thanks
@basilfx Thank you
Still works!
MacOS: BigSur VSCode: 1.67 VSCode C# Ext. : 1.25.0 Azure Func Core Tools: 4.x Dotnet: 6.x
@basilfx thank you!!!
Still works for me, was having tons of issues with the debugger detaching.
MacOs: Monterey 12.4 VSCode: 1.68.1 VSCode C# Ext: 1.25.0 Azure Func Core Tools: 4.x (latest as of this post) Dotnet: 6.0.201
The fix mentioned by @basilfx (thank you!) still works for the following setup:
macOS version: 12.4 (21F79) VSCode: 1.68.1 CSVode C# Ext: 1.25.0 Azure function core tools: 4.0.4590 Dotnet: 6.0.301
I had the same issue (actually VS Code debugger not able to attach to Azure Function process at all - no error, just loading) and @basilfx 's workaround solved the problem. God bless you @basilfx!!! OmniSharp team, please fix this once and for all!
My configuration:
OS: MacOS Monterey OS Version: 12.4 OS Platform: Darwin RID: osx.12-x64 Processor: 2.6 GHZ 6-Core Intel Core i7
.NET SDK: 6.0.101
.NET Runtime: Microsoft.NETCore.App 6.0.1
Azure Functions Core Tools: v4.0.4590
Visual Studio Code: version 1.68.1
VS Code Extensions:
I was triggered by a log line about code signing in the logging above. I therefore tried the following:
* Create self-signed code signing certificate: https://stackoverflow.com/a/58363510/1423623 * Navigate to the debugger folder (in my case, `~/.vscode/extensions/ms-dotnettools.csharp-1.24.4-darwin-x64/.debugger/x86_64`) * Run `codesign --remove-signature vsdbg-ui && codesign --remove-signature vsdbg` * Run `codesign -s my-codesign-cert vsdbg-ui && codesign -s my-codesign-cert vsdbg`
I can now attach to a running instance of
./vsdbg-ui --server --consoleLogging --engineLogging
from VS Code that stops at breakpoints. It's a work-around, but it shows something is wrong with the code signing ofvsdbg
and/orvsdbg-ui
.2022-04-20: can confirm that this still works, using OmniSharp 1.24.4.
Thanks Man! Still Working Monterey 12.5
I've just bumped on this issue and lost half a day before happening upon this issue. Thanks @basilfx for the workaround - it's got me back up and debugging ❤️
It would be tremendous to see this resolved in the extension itself - @gregg-miskelly do you happen to know if it's likely to be looked at?
@basilfx you da man. Got me unblocked.
same issue. thanks @basilfx
I've needed to refer back to @basilfx's workaround so often that I've turned it into a blog post here: https://johnnyreilly.com/debugging-azure-functions-vs-code-mac-os (credit attributed to @basilfx)
Thanks @basilfx
Also in case you use vscode server (and host on Mac), make sure you (also) resign this extension. So instead of .vscode/extensions
the location would be .vscode-server/extensions
.
Thanks @basilfx. Fix worked for me as well. Would be nice if this was addressed... It's been over a year now. I've noticed I have to redo this every time the extension updates, which is frustrating. Officially bookmarked ❤️ .
We're over a year on this issue that dulls Azure Functions dev exprience on Mac.
@basilfx - Thank you for the epic workaround. Saved my bacon.
@gregg-miskelly - Any news on this? Won't fix? Hard fix? Gameplan?
it didnt work for me. I executed the mentioned steps above and resign my vsdbg and vsdbg-ui but when I start it try to debug the azure function I receive the same error. Reboot of vscode and my macbook did not help :(. Any other ideas?
An alternative option is to remove the restriction from your Mac that all apps must either be from the App Store or signed by identified developers.
This is a hidden option in the System Preferences -> Privacy area that used to be visible in Sierra and earlier.
To reenable this option, hit your terminal with:
sudo spctl --master-disable
Then close any already open System Preferences app and then open System Preferences -> Privacy -> General tab and you should see that there is now an "Anywhere" option under the "Allow apps downloaded from:" area.
This has effectively turned off the need for apps to be signed by developers so do so at your own risk!
@gregg-miskelly can you guys get the binaries inside https://vsdebugger.azureedge.net/coreclr-debug-1-25-1/coreclr-debug-osx-x64.zip signed with a code cert that identifies Microsoft as the developer so that our Macs can execute those binaries?
This would fix the issue once and for all.
That appears to be where OmniSharp pulls the binaries from.
An alternative option is to remove the restriction from your Mac that all apps must either be from the App Store or signed by identified developers.
This is a hidden option in the System Preferences -> Privacy area that used to be visible in Sierra and earlier.
To reenable this option, hit your terminal with:
sudo spctl --master-disable
Then close any already open System Preferences app and then open System Preferences -> Privacy -> General tab and you should see that there is now an "Anywhere" option under the "Allow apps downloaded from:" area.
This has effectively turned off the need for apps to be signed by developers so do so at your own risk!
Thank you! But sadly I cant change this behaviour because I have a company managed device and I have not way to change it since it is managed by Intune :). Well... I have to find a way around it or... well just live with it.
Any movement on this?
I revisit this thread more frequently than I visit my in-laws. The resigning works, but It's just a pain.
Anyone other then me still have to do this? i need to visit this thread 2-3 times a week... for some reason it works for a couple of days and then the problem is back again.
@DrBlackBird Did you find a workaround which have worked for you? The resigning doesn't work for me either. :(
@fanyang-mono if the resigning fails you can try to log out and see if that helps, especially if you had no issue previously.
Issue Description
Attaching the debugger to an Azure Functions Core Tools running process (dotnet runtime - not dotnet-isolated) seems to attach for a second or two and then just detach with no errors/useful information reported.
Steps to Reproduce
Expected Behavior
Debugger attaches to the underlying process and waits for breakpoints to be hit. (I.e. when you manually trigger the function via cURL/Postman against localhost)
Actual Behavior
Debugger attaches for a few seconds and then detaches.
Logs
OmniSharp log
C# log
Environment information
VSCode version: 1.62.3 C# Extension: 1.23.16
Mono Information
OmniSharp using built-in monoDotnet Information
.NET SDK (reflecting any global.json): Version: 6.0.100 Commit: 9e8b04bbff Runtime Environment: OS Name: Mac OS X OS Version: 11.6 OS Platform: Darwin RID: osx.11.0-x64 Base Path: /usr/local/share/dotnet/sdk/6.0.100/ Host (useful for support): Version: 6.0.0 Commit: 4822e3c3aa .NET SDKs installed: 3.1.402 [/usr/local/share/dotnet/sdk] 3.1.407 [/usr/local/share/dotnet/sdk] 3.1.412 [/usr/local/share/dotnet/sdk] 5.0.201 [/usr/local/share/dotnet/sdk] 5.0.402 [/usr/local/share/dotnet/sdk] 6.0.100 [/usr/local/share/dotnet/sdk] .NET runtimes installed: Microsoft.AspNetCore.App 3.1.8 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App] Microsoft.AspNetCore.App 3.1.13 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App] Microsoft.AspNetCore.App 3.1.18 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App] Microsoft.AspNetCore.App 5.0.4 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App] Microsoft.AspNetCore.App 5.0.11 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App] Microsoft.AspNetCore.App 6.0.0 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App] Microsoft.NETCore.App 3.1.8 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App] Microsoft.NETCore.App 3.1.13 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App] Microsoft.NETCore.App 3.1.18 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App] Microsoft.NETCore.App 5.0.4 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App] Microsoft.NETCore.App 5.0.11 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App] Microsoft.NETCore.App 6.0.0 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App] To install additional .NET runtimes or SDKs: https://aka.ms/dotnet-downloadVisual Studio Code Extensions
|Extension|Author|Version| |---|---|---| |aadb2c|AzureADB2CTools|1.3.1| |application-insights|VisualStudioOnlineApplicationInsights|0.4.2| |armview|bencoleman|0.4.5| |auto-close-tag|formulahendry|0.5.13| |auto-rename-tag|formulahendry|0.1.9| |azure-account|ms-vscode|0.9.11| |azure-blueprints-generator|aminecharot|0.1.1| |azure-pipelines|ms-azure-devops|1.194.1| |azurecli|ms-vscode|0.5.0| |azurepolicyextension|AzurePolicy|0.2.2| |azurerm-vscode-tools|msazurermtools|0.15.5| |azurite|Azurite|3.14.3| |beautify|HookyQR|1.5.0| |csharp|ms-dotnettools|1.23.16| |csharpextensions|jchannon|1.3.1| |cypress-snippets|andrew-codes|1.2.0| |data-workspace-vscode|ms-mssql|0.1.0| |dendron|dendron|0.69.1| |dendron-markdown-links|dendron|0.6.20| |dendron-markdown-preview-enhanced|dendron|0.10.57| |dendron-markdown-shortcuts|dendron|0.12.1| |dendron-paste-image|dendron|1.1.0| |dendron-snippet-maker|dendron|0.1.6| |docomment|k--kato|0.1.30| |es7-react-js-snippets|dsznajder|3.1.1| |file-downloader|mindaro-dev|1.0.11| |github-vscode-theme|GitHub|5.0.3| |gitlens|eamodio|11.7.0| |html-css-class-completion|Zignd|1.20.0| |jupyter|ms-toolsai|2021.10.1101450599| |jupyter-keymap|ms-toolsai|1.0.0| |jupyter-renderers|ms-toolsai|1.0.3| |markdown-mermaid|bierner|1.13.0| |material-theme|zhuangtongfa|3.13.2| |mermaid-markdown-syntax-highlighting|bpruitt-goddard|1.2.2| |mindaro|mindaro|1.0.120210803| |msbuild-project-tools|tintoy|0.3.15| |mssql|ms-mssql|1.11.1| |ng-template|Angular|13.0.0| |night-owl|sdras|2.0.1| |nugetpackagemanagergui|aliasadidev|1.1.9| |postcss|csstools|1.0.9| |powershell|ms-vscode|2021.10.2| |prettier-plus|svipas|4.2.2| |python|ms-python|2021.11.1422169775| |remote-containers|ms-vscode-remote|0.205.2| |rest-client|humao|0.24.5| |sql-database-projects-vscode|ms-mssql|0.13.1| |vsc-community-material-theme|Equinusocio|1.4.2| |vsc-material-theme|Equinusocio|33.2.0| |vsc-material-theme-icons|equinusocio|1.2.2| |vscode-apimanagement|ms-azuretools|1.0.3| |vscode-azureappservice|ms-azuretools|0.23.0| |vscode-azurecache|ms-azurecache|0.1.0| |vscode-azureeventgrid|ms-azuretools|0.1.1| |vscode-azurefunctions|ms-azuretools|1.6.0| |vscode-azureresourcegroups|ms-azuretools|0.4.0| |vscode-azureserverlesspack|ms-azuretools|0.1.0| |vscode-azurestaticwebapps|ms-azuretools|0.9.0| |vscode-azurestorage|ms-azuretools|0.12.1| |vscode-azurevirtualmachines|ms-azuretools|0.4.1| |vscode-bicep|ms-azuretools|0.4.1008| |vscode-commons|redhat|0.0.6| |vscode-cosmosdb|ms-azuretools|0.18.1| |vscode-docker|ms-azuretools|1.18.0| |vscode-dotnet-runtime|ms-dotnettools|1.4.0| |vscode-eslint|dbaeumer|2.2.2| |vscode-html-css|ecmel|1.10.2| |vscode-icons|vscode-icons-team|11.7.0| |vscode-kubernetes-tools|ms-kubernetes-tools|1.3.4| |vscode-logicapps|ms-azuretools|1.0.25| |vscode-node-azure-pack|ms-vscode|0.2.1| |vscode-nuget-package-manager|jmrog|1.1.6| |vscode-pylance|ms-python|2021.11.2| |vscode-react-native|msjsdiag|1.8.0| |vscode-tailwindcss|bradlc|0.7.2| |vscode-tlaplus|alygin|1.5.4| |vscode-typescript-next|ms-vscode|4.6.20211118| |vscode-typescript-tslint-plugin|ms-vscode|1.3.3| |vscode-versionlens|pflannery|1.0.9| |vscode-yaml|redhat|1.2.0| |winteriscoming|johnpapa|1.4.4| |xml|DotJoshJohnson|2.5.1|;