Convert VisualStudioWorkloads to use direct COM - #52650
#52650Merged
Merged
Convert VisualStudioWorkloads to use direct COM#52650
Conversation
Member
Author
|
Current before and after for just the changed method:
|
Contributor
There was a problem hiding this comment.
Pull request overview
This pull request converts Visual Studio workload detection from using COM interop (via the Microsoft.VisualStudio.Setup.Configuration.Interop package) to direct COM invocation using function pointers. This enables AOT compilation scenarios and reduces marshalling overhead.
Changes:
- Replaced COM interop package with custom COM interface definitions and direct vtable calls
- Added comprehensive COM infrastructure (ComScope, SafeArrayScope, VARIANT handling, etc.)
- Refactored VisualStudioWorkloads.cs to use unsafe code with direct COM calls
- Added start-vs.cmd utility script for development
- Made minor optimizations in other files (collection expressions, string caching)
Reviewed changes
Copilot reviewed 50 out of 50 changed files in this pull request and generated no comments.
Show a summary per file
| File | Description |
|---|---|
| src/Cli/dotnet/Commands/Workload/List/VisualStudioWorkloads.cs | Converted to use direct COM calls via custom interfaces; improved string handling with spans |
| src/Cli/dotnet/Windows/Win32/System/Variant/* | New VARIANT marshalling infrastructure for COM interop |
| src/Cli/dotnet/Windows/Win32/System/Com/* | New COM helper types (ComScope, SafeArrayScope, etc.) for resource management |
| src/Cli/dotnet/Windows/Win32/Foundation/* | New Win32 foundation types (BSTR, HRESULT, Error handling, etc.) |
| src/Cli/dotnet/Microsoft/VisualStudio/Setup/Configuration/* | Custom definitions of VS Setup Configuration COM interfaces |
| src/Cli/dotnet/dotnet.csproj | Removed VS Setup interop package; updated CsWin32 configuration |
| test/dotnet.Tests/dotnet.Tests.csproj | Enabled unsafe blocks; removed VS Setup interop package |
| start-vs.cmd | New utility script for launching VS with local SDK |
| Directory.Packages.props | Updated CsWin32 version to 0.3.264 |
This was referenced Jan 23, 2026
JeremyKuhne
marked this pull request as ready for review
January 27, 2026 19:32
baronfel
reviewed
Jan 27, 2026
baronfel
reviewed
Jan 27, 2026
baronfel
reviewed
Jan 27, 2026
baronfel
reviewed
Jan 27, 2026
This change uses function pointers to avoid overhead and allow AOT scenarios. VS setup APIs are not part of the Windows SDK and as such aren't filled out via CsWin32. I've defined all of the setup APIs as CsWin32 would. We don't use much of the API surface area, but there is no marshalling here so the code cost is small. If we care to trim out some of these we can #ifdef down to what is actually used. The patterns used here are similar to what is used in WinForms and WPF. They can be multi-targeted and I've left TFM conditions in this code so I can move the implementations to the utility assembly as I fix other COM usage there. I'm working on adding the unit tests for the supporting functionalty.
This additional functionality (and more) can be pulled in as needed from: - WinForms - https://github.com/JeremyKuhne/vsinterop - https://github.com/JeremyKuhne/madowaku
JeremyKuhne
force-pushed
the
vsworkload
branch
from
January 28, 2026 20:12
14bdfb0 to
ee88f6a
Compare
joeloff
reviewed
Jan 28, 2026
joeloff
reviewed
Jan 28, 2026
joeloff
approved these changes
Jan 28, 2026
MiYanni
approved these changes
Jan 29, 2026
Member
Author
|
I didn't squash this one so the more complete definitions for some of the interop stuff is in the history. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This change uses function pointers to avoid overhead and allow AOT scenarios.
VS setup APIs are not part of the Windows SDK and as such aren't filled out via CsWin32. I've defined all of the setup APIs as CsWin32 would. We don't use much of the API surface area, but there is no marshalling here so the code cost is small. If we care to trim out some of these we can #ifdef down to what is actually used.
The patterns used here are similar to what is used in WinForms and WPF. They can be multi-targeted and I've left TFM conditions in this code so I can move the implementations to the utility assembly as I fix other COM usage there.
I'm working on adding the unit tests for the supporting functionality.
Also added a
start-vs.cmdfor easily starting VS to facilitate running tests on the local .NET.