search

dotnet / runtime

.NET is a cross-platform runtime for cloud, mobile, desktop, and IoT apps.
https://docs.microsoft.com/dotnet/core/
MIT License
15.16k stars 4.71k forks source link

Convert remaining COM-based libraries to use source-generated COM #88220

Open jkoritzinsky opened 1 year ago

jkoritzinsky commented 1 year ago

We have 4 libraries that are still using runtime-based COM interop. Once main is .NET 9 and main drops support for versions of .NET that will be out of support when .NET 9 releases (so .NET 6 and 7), we can move these libraries to use source-generated COM as they will only target .NET Standard and .NET 8+ and the .NET Standard implementation is a PNSE (PlatformNotSupportedException-throwing) assembly.

ghost commented 1 year ago

Tagging subscribers to this area: @dotnet/area-meta See info in area-owners.md if you want to be subscribed.

Issue Details
We have 4 libraries that are still using runtime-based COM interop. Once main is .NET 9 and main drops support for versions of .NET that will be out of support when .NET 9 releases (so .NET 6 and 7), we can move these libraries to use source-generated COM as they will only target .NET Standard and .NET 8+ and the .NET Standard implementation is a PNSE (PlatformNotSupportedException-throwing) assembly. - [ ] Convert System.DirectoryServices to use source-generated COM. - [ ] Convert System.DirectoryServices.AccountManagement to use source-generated COM. - [ ] Convert System.Speech to use source-generated COM. - [ ] Convert System.Management to use source-generated COM. - [ ] We should also remove the dependency on the .NET Framework-provided `wminet_utils.dll` if we're already updating the library to use source-generated COM as most of the point of `wminet_utils` is to assist with the COM interop.
Author: jkoritzinsky
Assignees: -
Labels: `area-Meta`, `source-generator`
Milestone: Future
jkoritzinsky commented 1 year ago

cc: @dotnet/area-infrastructure-libraries as I know some of these packages have been considered for moving to dotnet/maintenance-packages.

stephentoub commented 1 year ago

We have very poor test coverage for these libraries. What is our confidence that we can switch to use source-generated COM interop in a close-to-zero-risk manner? I'd be inclined to leave them as-is unless our confidence is super high and there's a significant benefit to switching.

jkoritzinsky commented 1 year ago

If the interop team does the switch-over and review, I have high confidence that we can get it right. When we moved over libraries to use LibraryImport, we moved over many of these libraries. There was some fallout then, but we have also taken the learnings from those conversions and used them to improve the interop source generators to lessen the chance of a break. With source-generated interop, we can get significant perf benefits and remove some complexity from the interactions with the underlying libraries in these APIs.

We can also get good perf improvements by just making the interop usage cleaner, which is much easier to do with source-generated interop as we have much better tooling to guide users to using high-performance interop (instead of something slow that works).

MichalStrehovsky commented 1 year ago

There were a couple customer requests for System.Management with Native AOT in the past and since we don't have built-in COM interop support in Native AOT, source generated COM is the only way to fix this.

https://github.com/dotnet/corert/issues/6728 https://github.com/dotnet/corert/issues/8184

ViktorHofer commented 1 year ago

https://github.com/orgs/dotnet/teams/area-infrastructure-libraries as I know some of these packages have been considered for moving to dotnet/maintenance-packages.

Only System.Speech and we never formalized those discussions into a plan. For now, that library will stay in runtime.

jkoritzinsky commented 1 year ago

I've taken a look at these libraries and determined that there's more work we can do to make the migration easier:

MichalStrehovsky commented 5 months ago

Another user reporting inability to use System.DirectoryServices.ActiveDirectory with native AOT due to built-in COM use: #101882

MichalStrehovsky commented 4 months ago

Internal partner ran into this for System.Management.

MichalStrehovsky commented 4 months ago

Also linking to #61960 that is about System.Management with trimming/AOT and wasn't mentioned here yet. Found it as I was looking for this issue.