Disable array support for the COM variant wrapper classes when built-in COM is disabled. #55756

jkoritzinsky · 2021-07-15T17:41:03Z

…in COM is disabled. Fixes dotnet#55600

ghost · 2021-07-15T17:41:10Z

Tagging subscribers to 'linkable-framework': @eerhardt, @vitek-karas, @LakshanF, @sbomer, @joperezr
See info in area-owners.md if you want to be subscribed.

Issue Details

Fixes #55600

Author:	jkoritzinsky
Assignees:	-
Labels:	`area-Interop-coreclr`, `linkable-framework`
Milestone:	6.0.0

LakshanF · 2021-07-15T17:54:51Z

src/coreclr/vm/olevariant.cpp

+        // VariantWrappers cannot be stored in VARIANT's.
+        if (CoreLibBinder::IsClass(pMT, CLASS__VARIANT_WRAPPER))
+            COMPlusThrow(kArgumentException, IDS_EE_COM_UNSUPPORTED_SIG);
+    }
 #endif // FEATURE_COMINTEROP



This is a more surgical fix than I was thinking and thanks for doing this!

I assume the code under the other #FEATURE_COMINTEROP in this method will not cause a problem?

The other ones won't cause problems.

We'll always have SafeHandle and CriticalHandle (which arrays of are always unsupported in interop).

And then the rest is based on RCW/CCW support having been used to create a wrapper, which is already blocked previously.

elinor-fung

@LakshanF - is there some sort of trimming test in libraries that could be added that would have caught this? (Those actually create a separate app and trim, right?)

src/coreclr/vm/olevariant.cpp

LakshanF · 2021-07-15T18:38:44Z

@LakshanF - is there some sort of trimming test in libraries that could be added that would have caught this? (Those actually create a separate app and trim, right?)

It doesn't look like we have that many library tests that have a trim mode as well. But we should do more test runs with built-in COM disabled

I did a couple of manual CI runs with built-in COM disabled but didn't see unusual failures including reflection emit tests (I didn't comprehensively look at all failures though)
Set BuiltInComInteropSupport=false for test assemblies which don't (and shouldn't) use COM #54523 should expand to include areas like TypeBuilder tests

jkoritzinsky · 2021-07-15T18:39:34Z

These failures only show up when the linker has run, not when the feature flag has been flipped.

elinor-fung · 2021-07-15T18:39:46Z

The issue here wasn't having it disabled though - it was actually trimming.

elinor-fung · 2021-07-15T18:43:11Z

I was talking about having/adding something for this in the tests in the TrimmingTests subfolders, not just tests that turn off the feature flag.

jkoritzinsky · 2021-07-15T18:45:57Z

It might be worth adding static constructors on these wrapper types that makes them throw when built-in COM is disabled by the feature flag.

Otherwise we can get into the following situation:

User uses DispatchWrapper[] in their code.
User tests their app without setting the BuiltInComSupported feature flag to false.
User trims their app with the BuildInComSupported feature flag kept to it's default of false.
Since user code kept the DispatchWrapper type around but the runtime support for the type is disabled, behavior changes (the DispatchWrapper object is marshalled, not the underlying object)

jkoritzinsky · 2021-07-15T18:46:36Z

Then again, the changed behavior is the same as the non-Windows behavior, so I'd be ok saying that it's the expected behavior.

LakshanF · 2021-07-15T18:50:16Z

Yes, you and @jkoritzinsky are right in that the corelib needs to be trimmed and we should look to expand the trimming tests under library.

I wonder though if it is possible to have a test mode in Windows where built-in COM is disabled without going the trimming route. In some sense, this is what is happening in non-Windows platforms where built-in COM is disabled and runtime 'knows' that and it doesn't ask for COM types inside the native code. Currently, Windows have both modes and runtime doesn't have a good way to distinguish that.

eerhardt · 2021-07-15T19:05:22Z

something for this in the tests in the TrimmingTests subfolders

Yes, this bug was caught by our TrimmingTests - see #55283 (comment).

In our current infra, we are using the 6.0-preview4 SDK which doesn't disable COM by default. In that PR, we are upgrading to 6.0-preview5 which is disabling COM by default, and exposed the bug.

So once #55283 is merged, we will have all our TrimmingTests running with COM disabled, like a normal user will be.

eerhardt · 2021-07-15T19:08:24Z

Can we add a new TrimmingTest that tests the repro scenario in #55600? I believe that will ensure this doesn't regress in the future.

It can be added to

https://github.com/dotnet/runtime/tree/main/src/libraries/System.Runtime/tests/TrimmingTests

or

https://github.com/dotnet/runtime/tree/main/src/libraries/System.Reflection.Emit/tests/TrimmingTests

elinor-fung · 2021-07-15T19:31:33Z

User tests their app without setting the BuiltInComSupported feature flag to false.

If they have PublishTrimmed=true, the SDK should automatically set this, right? So it would only be if they don't set that?

Yeah, I was also wondering if we should make the *Wrapper types explicitly throw if built-in COM was disabled, but decided that having the expected behaviour with built-in COM disabled be the same as the non-Windows behaviour made sense to me.

test mode in Windows where built-in COM is disabled without going the trimming route

I think that would basically be not setting FEATURE_COMINTEROP (although I'm sure it is not that clean and assorted refactoring would be needed). Unless we actually start going down the route of building/shipping/publishing different runtimes for different feature flags, I don't think it would make sense to invest in testing that way. Using the TrimmingTests seems like the right thing to me.

Yes, this bug was caught by our TrimmingTests

Ah, missed that it was found from a test failure - glad there is some testing that hit this. I agree we should add one specifically for TypeBuilder.CreateType.

Maybe this is a point-in-time thing, but would it be useful to have some way to set additional runtime config / trimmer args for all the trimmer tests? At least to be able to easily kick off a run (not necessarily checking in the specific values) with changes/defaults that aren't in the repo's SDK version yet.

jkoritzinsky · 2021-07-15T20:42:43Z

I've added a trimming test to validate this behavior. @eerhardt can you check that I configured it correctly?

agocke · 2021-07-15T23:27:29Z

src/libraries/System.Runtime/tests/TrimmingTests/System.Runtime.TrimmingTests.proj

@@ -35,6 +35,9 @@
      as this test will ensure exceptions are using Resource keys -->
      <ExtraTrimmerArgs>--feature System.Resources.UseSystemResourceKeys true</ExtraTrimmerArgs>
    </TestConsoleAppSourceFiles>
+    <TestConsoleAppSourceFiles Include="TypeBuilderComDisabled.cs">
+      <ExtraTrimmerArgs>--feature System.Runtime.InteropServices.BuiltInComInterop.IsSupported false</ExtraTrimmerArgs>


I assume this is run against the live runtime we just built?

If so, I think we should consider moving the default feature switch configuration for the linker into the runtime and try to insert it into the SDK. That would help catch issues like this much faster than waiting for the next SDK update.

I assume this is run against the live runtime we just built?

correct.

consider moving the default feature switch configuration for the linker into the runtime and try to insert it into the SDK

I don't think that is fully worth the engineering and servicing effort of shipping "tooling" out of the runtime. The defaulting belongs in the dotnet/sdk IMO - that is the SDK for the runtime. It would just be great if we weren't 2-3 previews behind in the SDK we are using to build the dotnet/runtime.

+1 on the defaults belonging to SDK. Even more so because different SDKs have different defaults.

In that case, is the proposal to upgrade the SDK used in runtime much more frequently? This could cause a lot of unrelated churn, and we would probably have to be on nightly builds in order to catch things quickly.

If we could somehow enable feature switches faster though, then we wouldn't be dependent on SDK updates.

If we could somehow enable feature switches faster though

We can set feature switches in the tests, like this new test is doing. If required, we could set some feature switches for all tests. But for BuiltInCOMInterop, we will get it for free once #55283 is merged.

Here are the other switches that are defaulted based on PublishTrimmed:

https://github.com/dotnet/sdk/blob/0ce0580f222ff42a1a14eed42f01dcf2f41ea82f/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.ILLink.targets#L35-L45

<PropertyGroup Condition="'$(PublishTrimmed)' == 'true' And $([MSBuild]::VersionGreaterThanOrEquals($(_TargetFrameworkVersionWithoutV), '6.0'))"> <StartupHookSupport Condition="'$(StartupHookSupport)' == ''">false</StartupHookSupport> <CustomResourceTypesSupport Condition="'$(CustomResourceTypesSupport)' == ''">false</CustomResourceTypesSupport> <EnableUnsafeBinaryFormatterInDesigntimeLicenseContextSerialization Condition="'$(EnableUnsafeBinaryFormatterInDesigntimeLicenseContextSerialization)' == ''">false</EnableUnsafeBinaryFormatterInDesigntimeLicenseContextSerialization> <EnableUnsafeBinaryFormatterSerialization Condition="'$(EnableUnsafeBinaryFormatterSerialization)' == ''">false</EnableUnsafeBinaryFormatterSerialization> <EnableUnsafeUTF7Encoding Condition="'$(EnableUnsafeUTF7Encoding )' == ''">false</EnableUnsafeUTF7Encoding > <BuiltInComInteropSupport Condition="'$(BuiltInComInteropSupport)' == ''">false</BuiltInComInteropSupport> <AutoreleasePoolSupport Condition="'$(AutoreleasePoolSupport)' == ''">false</AutoreleasePoolSupport> <EnableCppCLIHostActivation Condition="'$(EnableCppCLIHostActivation)' == ''">false</EnableCppCLIHostActivation> <_EnableConsumingManagedCodeFromNativeHosting Condition="'$(_EnableConsumingManagedCodeFromNativeHosting)' == ''">false</_EnableConsumingManagedCodeFromNativeHosting>

BuiltInCOM is definitely the most likely to cause issues across the stack (like we saw here).

@Anipik @ViktorHofer - thoughts on upgrading the SDK more frequently? preview6 shipped yesterday and we are just trying to update to preview5 now.

Right we could update the feature switches manually like we did here, but it seems like we would want them all to be enabled ASAP, which is why I proposed moving the feature switch code into the runtime. Otherwise it seems too easy to forget to change the tests.

src/libraries/System.Runtime/tests/TrimmingTests/TypeBuilderComDisabled.cs

eng/testing/linker/trimmingTests.targets

Co-authored-by: Eric Erhardt <[email protected]>

src/libraries/System.Runtime/tests/TrimmingTests/TypeBuilderComDisabled.cs

eerhardt

Looks good. Thanks for fixing this.

ViktorHofer · 2021-07-22T07:14:19Z

@Anipik @ViktorHofer - thoughts on upgrading the SDK more frequently? preview6 shipped yesterday and we are just trying to update to preview5 now.

I'm all for ingesting fresh SDK bits more frequently but it comes with a significant burden. In Tactics we agreed on that we want to depend on publicly available, singed SDK bits only when building our repositories. As we don't sign nightly builds and we don't want to force community members and us to install nightly SDKs on our machines we want to depend on publicly announced and released SDKs only which usually release on a monthly basis until a major version ships.

I discussed with @Anipik in the past that it would be great to have a validation job running which ingests newer SDK bits to detect regressions / changes that need reaction earlier. The current process is very manual and requires significant amount of work.

cc @marek-safar and @mmitche as we had a meeting for this some months ago. Unsure where we currently stand with automatically updating Arcade's SDK when a new SDK is released?

mmitche · 2021-07-22T15:32:46Z

There's no automatic update, and no plans to implement the necessary workflow to get it done. It looks like the last update was for p4. dotnet/arcade#7657

Disable array support for the COM variant wrapper classes when built-…

5985f54

…in COM is disabled. Fixes dotnet#55600

jkoritzinsky added area-Interop-coreclr linkable-framework Issues associated with delivering a linker friendly framework labels Jul 15, 2021

jkoritzinsky added this to the 6.0.0 milestone Jul 15, 2021

jkoritzinsky requested review from LakshanF and elinor-fung July 15, 2021 17:41

LakshanF reviewed Jul 15, 2021

View reviewed changes

Fix config call.

69d7d61

elinor-fung reviewed Jul 15, 2021

View reviewed changes

src/coreclr/vm/olevariant.cpp Show resolved Hide resolved

Fix one more location of wrapper class usage.

10d3b3d

jkoritzinsky added 2 commits July 15, 2021 13:36

Fix method name.

6f51a07

Add trimming test.

e0e219f

agocke reviewed Jul 15, 2021

View reviewed changes

eerhardt reviewed Jul 16, 2021

View reviewed changes

src/libraries/System.Runtime/tests/TrimmingTests/TypeBuilderComDisabled.cs Show resolved Hide resolved

elinor-fung added 2 commits July 16, 2021 13:02

Fix AV in IsArrayOfWrappers

19bca14

Fix trimming test

801d9c8

eerhardt reviewed Jul 16, 2021

View reviewed changes

eng/testing/linker/trimmingTests.targets Outdated Show resolved Hide resolved

eerhardt reviewed Jul 16, 2021

View reviewed changes

eng/testing/linker/trimmingTests.targets Outdated Show resolved Hide resolved

elinor-fung reviewed Jul 16, 2021

View reviewed changes

eng/testing/linker/trimmingTests.targets Outdated Show resolved Hide resolved

eng/testing/linker/trimmingTests.targets Outdated Show resolved Hide resolved

elinor-fung and others added 2 commits July 16, 2021 14:21

Apply suggestions from code review

8cf985b

Co-authored-by: Eric Erhardt <[email protected]>

Set Trim=true

ade2649

eerhardt reviewed Jul 16, 2021

View reviewed changes

src/libraries/System.Runtime/tests/TrimmingTests/TypeBuilderComDisabled.cs Show resolved Hide resolved

eerhardt approved these changes Jul 16, 2021

View reviewed changes

Add licence header

b1d7638

eerhardt merged commit 62fad9d into dotnet:main Jul 18, 2021

eerhardt mentioned this pull request Jul 18, 2021

Update SDK to 6.0 Preview 5 #55283

Merged

ManickaP mentioned this pull request Jul 20, 2021

[QUIC] Remove AppContext switch from S.N.Quic #56027

Merged

karelz mentioned this pull request Jul 20, 2021

Reenable Http2_ServerSendsInvalidSettingsValue_Error test #1581

Closed

jkoritzinsky deleted the arrays-com-disabled branch July 22, 2021 16:13

ghost locked as resolved and limited conversation to collaborators Aug 21, 2021

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Disable array support for the COM variant wrapper classes when built-in COM is disabled. #55756

Disable array support for the COM variant wrapper classes when built-in COM is disabled. #55756

jkoritzinsky commented Jul 15, 2021

ghost commented Jul 15, 2021

LakshanF Jul 15, 2021

jkoritzinsky Jul 15, 2021

elinor-fung left a comment

LakshanF commented Jul 15, 2021

jkoritzinsky commented Jul 15, 2021

elinor-fung commented Jul 15, 2021

elinor-fung commented Jul 15, 2021

jkoritzinsky commented Jul 15, 2021

jkoritzinsky commented Jul 15, 2021

LakshanF commented Jul 15, 2021

eerhardt commented Jul 15, 2021

eerhardt commented Jul 15, 2021

elinor-fung commented Jul 15, 2021 •

edited

Loading

jkoritzinsky commented Jul 15, 2021

agocke Jul 15, 2021

eerhardt Jul 16, 2021

eerhardt Jul 16, 2021

vitek-karas Jul 16, 2021

agocke Jul 16, 2021

eerhardt Jul 16, 2021

eerhardt Jul 16, 2021

agocke Jul 16, 2021

eerhardt left a comment

ViktorHofer commented Jul 22, 2021

mmitche commented Jul 22, 2021

Disable array support for the COM variant wrapper classes when built-in COM is disabled. #55756

Disable array support for the COM variant wrapper classes when built-in COM is disabled. #55756

Conversation

jkoritzinsky commented Jul 15, 2021

ghost commented Jul 15, 2021

Choose a reason for hiding this comment

Choose a reason for hiding this comment

elinor-fung left a comment

Choose a reason for hiding this comment

LakshanF commented Jul 15, 2021

jkoritzinsky commented Jul 15, 2021

elinor-fung commented Jul 15, 2021

elinor-fung commented Jul 15, 2021

jkoritzinsky commented Jul 15, 2021

jkoritzinsky commented Jul 15, 2021

LakshanF commented Jul 15, 2021

eerhardt commented Jul 15, 2021

eerhardt commented Jul 15, 2021

elinor-fung commented Jul 15, 2021 • edited Loading

jkoritzinsky commented Jul 15, 2021

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

eerhardt left a comment

Choose a reason for hiding this comment

ViktorHofer commented Jul 22, 2021

mmitche commented Jul 22, 2021

elinor-fung commented Jul 15, 2021 •

edited

Loading