-
Notifications
You must be signed in to change notification settings - Fork 4.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add the ability to remove COM support using ILLinker #36659
Comments
Tagging subscribers to this area: @vitek-karas, @swaroop-sridhar |
In this case, I'd prefer to see a new public property for COM. Something like |
@vitek-karas and @MichalStrehovsky I would be grateful if one of you could provide some suggestions on the best way to solve this issue. |
Both |
Linker has all the required features needed to make COM support feature-based. The ball is on the libraries side to decide what level of granularity is needed and add the API (static bool property/properties). |
Ok, my proposal would be |
I think it can be internal for now, we can make it public later if we see a need. We would also need a feature switch to allow for trimming |
Ideally, Or do you believe that we should rather ask everybody out there (both in libraries and apps) to mark their |
I guess it depends on how much we want the ILLinker to know about COM. My understanding was that @marek-safar and @vitek-karas were moving away from ILLinker having hard-coded knowledge of features. But since COM is so low in the stack, it may be fine for the ILLinker to know about it. |
I think we're discussing two related but separate issues here:
The former is something we're trying to solve for .NET 5. The latter is something we should probably punt to later releases. I also don't think the solutions will be that related, so we should feel free to do what's necessary to make the .NET 5 goals work. |
If we aren't trying to fully solve this issue in .NET 5, I believe the only thing necessary to strip it from Blazor would be to remove these lines from the System.Private.CoreLib's Shared ILLink.Descriptors file: runtime/src/libraries/System.Private.CoreLib/src/ILLink/ILLink.Descriptors.Shared.xml Lines 50 to 55 in 643f5e1
And move them into the CoreCLR specific For |
That might work... although it would be safer to introduce the feature switch and make sure that Blazor runs it off - just so that we don't run into surprises in the future. |
I suspect we'll need it public at least in scope for our libraries. I guess there will be some code outside of SPC which could be conditionally excluded based on this property. It'd also be helpful for libraries authors so they don' have to rely on
The COM types are already recognized by the linker and handled differently. I don't think we have should bound that logic directly with |
What does linker do for them? If it did the right thing (tm) for them, we would not need the manual entries for IMarshal and ComEventsSink? |
I think it marks the default constructor and all fields on the type |
Fields do not matter for COM interop. Did you meant to say methods? |
I couldn't find the code which is handling this so it looks like it was removed when we stopped caring about COM. We could add it back to linker though. |
That's sounds like the first thing to do here. These types do not even exist in the shared CoreLib... |
These types only exist in CoreCLR, they don't exist in Mono. Contributes to dotnet#36659
Okay. I will move this to .NET 6.0. Feel free to remark if this becomes a need for .NET 5.0. |
Yes, each feature exposed as API is responsible to expose its own local |
I created #43604 to track the work around breaking hard coded dependencies in |
@LakshanF - is this work completed? Or is there still more to do? |
There are still some cleanup work around test coverage and rooting native types. I'm planning to spend some time this week to review and will re-visit this after that |
yes |
Closing this now |
As discussed in:
We are currently "rooting" types in the libraries specifically for COM:
runtime/src/libraries/Microsoft.CSharp/src/ILLinkTrim.xml
Lines 7 to 8 in 0955d7f
runtime/src/libraries/System.Runtime.InteropServices/src/ILLinkTrim.xml
Lines 3 to 4 in 0955d7f
A lot of scenarios in .NET don't have COM support, as such we should be able to trim out any COM specific code when we are linking for a scenario that won't ever need COM (Blazor, Xamarin, Linux, etc).
One way of doing this would be to add a new feature switch to the product that would enable/disable COM. We can then add the switch in code to remove any COM specific code. In order to remove the COM types from being rooted by the
ILLinkTrim.xml
"descriptor XML files" above, we would need the ILLinker to allow "feature switches" to be present in the descriptor XML files, and to include/exclude that root based on the feature switch.Note that Blazor today is already using something similar when it uses
monolinker.exe
---exclude-feature com
. See the Blazor build code. However,--exclude-feature
is not supported by the ILLinker, only bymonolinker.exe
.cc @vitek-karas @MichalStrehovsky @sbomer @marek-safar
The text was updated successfully, but these errors were encountered: