Split Variant marshalling tests

[kant2002]

These tests split to be able test ComWrappers,
built-in COM enabled/disable mode.
See #50500, #51265

[kant2002]

Initially discovered as part of dotnet/runtimelab#1142
I do not know how to pass IsComSupported to test and how to read. Would like that somebody help me with that.
This PR to gather feedback on the implementation details, code split approach.

[AaronRobinsonMSFT]

I do not know how to pass IsComSupported to test and how to read. Would like that somebody help me with that.

Adding a feature flag to a test project is the same as passing it in the product. See https://github.com/dotnet/runtime/pull/52940/files#diff-c25cd81bf60eaf73ca87747baafae7fbfd0ac8a787da03b22382eff45316c9e5 and look for RuntimeHostConfigurationOption.

[AaronRobinsonMSFT]

/cc @LakshanF@elinor-fung

[kant2002]

I think I overcomplicate PR. I will revert changes, and will create couple projects in same folder. Seems to be that would be easier to maintain.

[LakshanF]

@kant2002, thanks for taking a look! Please also take a look at some test changes that are already present for library, and the pending PR, #52940, that has some tests for the runtime.

[kant2002]

@LakshanF this changes just for Variant marshalling. Hopefully current version is in spirit of what was for #52940

[kant2002]

Build was failed, since results was not sent to Helix

[LakshanF]

I see these 2 tests failing when built-in COM is disabled,

Interop\PInvoke\Variant\VariantTestBuiltInComDisabled\VariantTestBuiltInComDisabled.cmd
Interop\PInvoke\Variant\VariantTestComWrappers\VariantTestComWrappers.cmd

The first test has the following output,

BEGIN EXECUTION
"C:\h\w\AC52093C\p\corerun.exe" -p "System.Runtime.InteropServices.BuiltInComInterop.IsSupported=false" VariantTestBuiltInComDisabled.dll
Built-in COM Disabled?: True
Test failed: System.NotSupportedException: Built-in COM has been disabled via a feature switch. See https://aka.ms/dotnet-illink/com for more information.
at System.StubHelpers.ObjectMarshaler.ConvertToNative(Object objSrc, IntPtr pDstVariant)
at VariantNative.Marshal_ByValue_Object(Object obj)
at Test.TestByValue(Boolean hasComSupport) in VariantTestBuiltInComDisabled.dll:token 0x6000059+0x223
at Test.Main() in VariantTestBuiltInComDisabled.dll:token 0x600005e+0x34
Expected: 100
Actual: 101
END EXECUTION - FAILED

[kant2002]

Thanks for pointing me in the error log. I was able to find it afterwards. I see now only one error

 Interop\PInvoke\Variant\VariantTestComWrappers\VariantTestComWrappers.cmd [FAIL]
Return code: 1
Raw output file: C:\h\w\AF5C0958\w\B3E30948\e\Interop\PInvoke\Reports\Interop.PInvoke\Variant\VariantTestComWrappers\VariantTestComWrappers.output.txt
Raw output:
BEGIN EXECUTION
"C:\h\w\AF5C0958\p\corerun.exe" -p "System.Runtime.InteropServices.BuiltInComInterop.IsSupported=false" VariantTestComWrappers.dll Test failed: TestLibrary.AssertTestException: Assert.IsTrue: at TestLibrary.Assert.HandleFail(String assertionName, String message) in TestLibrary.dll:token 0x6000021+0x11
at TestLibrary.Assert.IsTrue(Boolean condition, String message) in TestLibrary.dll:token 0x600000a+0x3
at Test.TestByValue(Boolean hasComSupport) in VariantTestComWrappers.dll:token 0x6000059+0x223
at Test.Main() in VariantTestComWrappers.dll:token 0x600005e+0xc
Invalid format. Expected VT_DISPATCH.

Does that means that ComWrappers has slightly different marshalling, or this is a bug? Should I fix that bug as part of PR?

[AaronRobinsonMSFT]

Does that means that ComWrappers has slightly different marshalling, or this is a bug? Should I fix that bug as part of PR?

@kant2002 It isn't clear to me which statement in the test is failing. Can you narrow it down to which one is the issue?

[kant2002]

@AaronRobinsonMSFT this line produce exception
https://github.com/dotnet/runtime/pull/53035/files#diff-1c679eb2a695bcba0de0c236544a305004b9e816151a677657a2528b2a039608R46
because there printed message from

runtime/src/tests/Interop/PInvoke/Variant/VariantNative.cpp

Line 152 in 57bdb95

printf("Invalid format. Expected VT_DISPATCH.\n");

[kant2002]

Honestly I did not run that. It's just reading logs. I'm yet to build single test project locally. Otherwise it's hard to me to allocate time (~1 hour). If you strictly need me to build, and validate my last statement, let me know. I will compile and troubleshoot in more details. But I think I point location to you properly.

[AaronRobinsonMSFT]

@kant2002 The issue here is a bug in the ComWrappers conversion logic for IDispatch. It is a part of the absolute mess that is the OLE support and how enum values are used as both request and result – yuck.

In the both case we detect if IDispatch is implemented but don't reduce the returned enum value to just ComIpType_Dispatch but return the input - which is the request not the result. The solution here is to return either ComIpType_Dispatch or ComIpType_Unknown but not ComIpType_Both.

runtime/src/coreclr/vm/interopconverter.cpp

Lines 183 to 205 in 959c327

	if (TryGetComIPFromObjectRefUsingComWrappers(*poref, &pUnk))
	{
	hr = S_OK;
	IUnknown* pvObj;
	if (ReqIpType & ComIpType_Dispatch)
	{
	hr = SafeQueryInterface(pUnk, IID_IDispatch, &pvObj);
	pUnk->Release();
	}
	else
	{
	pvObj = pUnk;
	}
	if (FAILED(hr))
	COMPlusThrowHR(hr);
	if (pFetchedIpType != NULL)
	*pFetchedIpType = ReqIpType;
	RETURN pvObj;
	}

[AaronRobinsonMSFT]

Should I fix that bug as part of PR?

Yes, that would be much appreciated.

[kant2002]

@AaronRobinsonMSFT can you take a look?

[kant2002]

Do not understand test failures. Please advice if this something which I'm responsible with?

[AaronRobinsonMSFT]

@kant2002 I would take a step back here and walk through this logic more fully. I think there was some confusion on when this was originally written and support IDispatch has uncovered that in the ComWrappers scenario.

/cc @elinor-fung

[AaronRobinsonMSFT]

This Release shouldn't be called indiscriminately here. We are checking for IDispatch now and it could fail, but ComIpType_Unknown must still be returned. Move this release into the success path below.

[kant2002]

Do I understand correctly that in discussed part of code, I should follow these rules?

ReqIpType = ComIpType_Both

1. QI to IDispatch - ok

pUnk->Release();
FetchedIpType = ComIpType_Dispatch;

2. QI to IDispatch - failed

pvObj = pUnk;
FetchedIpType = ComIpType_Unknown;

ReqIpType = ComIpType_IDispatch

3. QI to IDispatch - ok

pUnk->Release();
FetchedIpType = ComIpType_Dispatch;

4. QI to IDispatch - failed

COMPlusThrowHR(hr); // ????

ReqIpType = ComIpType_IUnknown

pvObj = pUnk;
FetchedIpType = ComIpType_Unknown;

[AaronRobinsonMSFT]

@kant2002 Yes.

[kant2002]

@AaronRobinsonMSFT is it possible that ComIpType_OuterUnknown would be passed to that location? Technically that will be handled by IUnknown case, but maybe there special processing needed.

[AaronRobinsonMSFT]

@kant2002 I don't think that ComIpType_OuterUnknown should be a concern here. The ComWrappers API does support aggregation but at present I am not sure how we would integrate at this point. I am okay not dealing with it at present.

[kant2002]

@AaronRobinsonMSFT then can you take a look?

[AaronRobinsonMSFT]

LGTM. Thank you.

[kant2002]

These tests split to be able test ComWrappers,
built-in COM enabled/disable mode.
See #50500, #51265

[kant2002]

Initially discovered as part of dotnet/runtimelab#1142
I do not know how to pass IsComSupported to test and how to read. Would like that somebody help me with that.
This PR to gather feedback on the implementation details, code split approach.

[AaronRobinsonMSFT]

I do not know how to pass IsComSupported to test and how to read. Would like that somebody help me with that.

Adding a feature flag to a test project is the same as passing it in the product. See https://github.com/dotnet/runtime/pull/52940/files#diff-c25cd81bf60eaf73ca87747baafae7fbfd0ac8a787da03b22382eff45316c9e5 and look for RuntimeHostConfigurationOption.

[AaronRobinsonMSFT]

/cc @LakshanF@elinor-fung

[kant2002]

I think I overcomplicate PR. I will revert changes, and will create couple projects in same folder. Seems to be that would be easier to maintain.

[LakshanF]

@kant2002, thanks for taking a look! Please also take a look at some test changes that are already present for library, and the pending PR, #52940, that has some tests for the runtime.

[kant2002]

@LakshanF this changes just for Variant marshalling. Hopefully current version is in spirit of what was for #52940

[kant2002]

Build was failed, since results was not sent to Helix

[LakshanF]

I see these 2 tests failing when built-in COM is disabled,

Interop\PInvoke\Variant\VariantTestBuiltInComDisabled\VariantTestBuiltInComDisabled.cmd
Interop\PInvoke\Variant\VariantTestComWrappers\VariantTestComWrappers.cmd

The first test has the following output,

BEGIN EXECUTION
"C:\h\w\AC52093C\p\corerun.exe" -p "System.Runtime.InteropServices.BuiltInComInterop.IsSupported=false" VariantTestBuiltInComDisabled.dll
Built-in COM Disabled?: True
Test failed: System.NotSupportedException: Built-in COM has been disabled via a feature switch. See https://aka.ms/dotnet-illink/com for more information.
at System.StubHelpers.ObjectMarshaler.ConvertToNative(Object objSrc, IntPtr pDstVariant)
at VariantNative.Marshal_ByValue_Object(Object obj)
at Test.TestByValue(Boolean hasComSupport) in VariantTestBuiltInComDisabled.dll:token 0x6000059+0x223
at Test.Main() in VariantTestBuiltInComDisabled.dll:token 0x600005e+0x34
Expected: 100
Actual: 101
END EXECUTION - FAILED

[kant2002]

Thanks for pointing me in the error log. I was able to find it afterwards. I see now only one error

 Interop\PInvoke\Variant\VariantTestComWrappers\VariantTestComWrappers.cmd [FAIL]
Return code: 1
Raw output file: C:\h\w\AF5C0958\w\B3E30948\e\Interop\PInvoke\Reports\Interop.PInvoke\Variant\VariantTestComWrappers\VariantTestComWrappers.output.txt
Raw output:
BEGIN EXECUTION
"C:\h\w\AF5C0958\p\corerun.exe" -p "System.Runtime.InteropServices.BuiltInComInterop.IsSupported=false" VariantTestComWrappers.dll Test failed: TestLibrary.AssertTestException: Assert.IsTrue: at TestLibrary.Assert.HandleFail(String assertionName, String message) in TestLibrary.dll:token 0x6000021+0x11
at TestLibrary.Assert.IsTrue(Boolean condition, String message) in TestLibrary.dll:token 0x600000a+0x3
at Test.TestByValue(Boolean hasComSupport) in VariantTestComWrappers.dll:token 0x6000059+0x223
at Test.Main() in VariantTestComWrappers.dll:token 0x600005e+0xc
Invalid format. Expected VT_DISPATCH.

Does that means that ComWrappers has slightly different marshalling, or this is a bug? Should I fix that bug as part of PR?

[AaronRobinsonMSFT]

Does that means that ComWrappers has slightly different marshalling, or this is a bug? Should I fix that bug as part of PR?

@kant2002 It isn't clear to me which statement in the test is failing. Can you narrow it down to which one is the issue?

[kant2002]

@AaronRobinsonMSFT this line produce exception
https://github.com/dotnet/runtime/pull/53035/files#diff-1c679eb2a695bcba0de0c236544a305004b9e816151a677657a2528b2a039608R46
because there printed message from

runtime/src/tests/Interop/PInvoke/Variant/VariantNative.cpp

Line 152 in 57bdb95

printf("Invalid format. Expected VT_DISPATCH.\n");

[kant2002]

Honestly I did not run that. It's just reading logs. I'm yet to build single test project locally. Otherwise it's hard to me to allocate time (~1 hour). If you strictly need me to build, and validate my last statement, let me know. I will compile and troubleshoot in more details. But I think I point location to you properly.

[AaronRobinsonMSFT]

@kant2002 The issue here is a bug in the ComWrappers conversion logic for IDispatch. It is a part of the absolute mess that is the OLE support and how enum values are used as both request and result – yuck.

In the both case we detect if IDispatch is implemented but don't reduce the returned enum value to just ComIpType_Dispatch but return the input - which is the request not the result. The solution here is to return either ComIpType_Dispatch or ComIpType_Unknown but not ComIpType_Both.

runtime/src/coreclr/vm/interopconverter.cpp

Lines 183 to 205 in 959c327

	if (TryGetComIPFromObjectRefUsingComWrappers(*poref, &pUnk))
	{
	hr = S_OK;
	IUnknown* pvObj;
	if (ReqIpType & ComIpType_Dispatch)
	{
	hr = SafeQueryInterface(pUnk, IID_IDispatch, &pvObj);
	pUnk->Release();
	}
	else
	{
	pvObj = pUnk;
	}
	if (FAILED(hr))
	COMPlusThrowHR(hr);
	if (pFetchedIpType != NULL)
	*pFetchedIpType = ReqIpType;
	RETURN pvObj;
	}

[AaronRobinsonMSFT]

Should I fix that bug as part of PR?

Yes, that would be much appreciated.

[kant2002]

@AaronRobinsonMSFT can you take a look?

[kant2002]

Do not understand test failures. Please advice if this something which I'm responsible with?

[AaronRobinsonMSFT]

@kant2002 I would take a step back here and walk through this logic more fully. I think there was some confusion on when this was originally written and support IDispatch has uncovered that in the ComWrappers scenario.

/cc @elinor-fung

[AaronRobinsonMSFT]

This Release shouldn't be called indiscriminately here. We are checking for IDispatch now and it could fail, but ComIpType_Unknown must still be returned. Move this release into the success path below.

[kant2002]

Do I understand correctly that in discussed part of code, I should follow these rules?

ReqIpType = ComIpType_Both

1. QI to IDispatch - ok

pUnk->Release();
FetchedIpType = ComIpType_Dispatch;

2. QI to IDispatch - failed

pvObj = pUnk;
FetchedIpType = ComIpType_Unknown;

ReqIpType = ComIpType_IDispatch

3. QI to IDispatch - ok

pUnk->Release();
FetchedIpType = ComIpType_Dispatch;

4. QI to IDispatch - failed

COMPlusThrowHR(hr); // ????

ReqIpType = ComIpType_IUnknown

pvObj = pUnk;
FetchedIpType = ComIpType_Unknown;

[AaronRobinsonMSFT]

@kant2002 Yes.

[kant2002]

@AaronRobinsonMSFT is it possible that ComIpType_OuterUnknown would be passed to that location? Technically that will be handled by IUnknown case, but maybe there special processing needed.

[AaronRobinsonMSFT]

@kant2002 I don't think that ComIpType_OuterUnknown should be a concern here. The ComWrappers API does support aggregation but at present I am not sure how we would integrate at this point. I am okay not dealing with it at present.

[kant2002]

@AaronRobinsonMSFT then can you take a look?

[AaronRobinsonMSFT]

LGTM. Thank you.

[kant2002]

These tests split to be able test ComWrappers,
built-in COM enabled/disable mode.
See #50500, #51265

[kant2002]

Initially discovered as part of dotnet/runtimelab#1142
I do not know how to pass IsComSupported to test and how to read. Would like that somebody help me with that.
This PR to gather feedback on the implementation details, code split approach.

[AaronRobinsonMSFT]

I do not know how to pass IsComSupported to test and how to read. Would like that somebody help me with that.

Adding a feature flag to a test project is the same as passing it in the product. See https://github.com/dotnet/runtime/pull/52940/files#diff-c25cd81bf60eaf73ca87747baafae7fbfd0ac8a787da03b22382eff45316c9e5 and look for RuntimeHostConfigurationOption.

[AaronRobinsonMSFT]

/cc @LakshanF@elinor-fung

[kant2002]

I think I overcomplicate PR. I will revert changes, and will create couple projects in same folder. Seems to be that would be easier to maintain.

[LakshanF]

@kant2002, thanks for taking a look! Please also take a look at some test changes that are already present for library, and the pending PR, #52940, that has some tests for the runtime.

[kant2002]

@LakshanF this changes just for Variant marshalling. Hopefully current version is in spirit of what was for #52940

[kant2002]

Build was failed, since results was not sent to Helix

[LakshanF]

I see these 2 tests failing when built-in COM is disabled,

Interop\PInvoke\Variant\VariantTestBuiltInComDisabled\VariantTestBuiltInComDisabled.cmd
Interop\PInvoke\Variant\VariantTestComWrappers\VariantTestComWrappers.cmd

The first test has the following output,

BEGIN EXECUTION
"C:\h\w\AC52093C\p\corerun.exe" -p "System.Runtime.InteropServices.BuiltInComInterop.IsSupported=false" VariantTestBuiltInComDisabled.dll
Built-in COM Disabled?: True
Test failed: System.NotSupportedException: Built-in COM has been disabled via a feature switch. See https://aka.ms/dotnet-illink/com for more information.
at System.StubHelpers.ObjectMarshaler.ConvertToNative(Object objSrc, IntPtr pDstVariant)
at VariantNative.Marshal_ByValue_Object(Object obj)
at Test.TestByValue(Boolean hasComSupport) in VariantTestBuiltInComDisabled.dll:token 0x6000059+0x223
at Test.Main() in VariantTestBuiltInComDisabled.dll:token 0x600005e+0x34
Expected: 100
Actual: 101
END EXECUTION - FAILED

[kant2002]

Thanks for pointing me in the error log. I was able to find it afterwards. I see now only one error

 Interop\PInvoke\Variant\VariantTestComWrappers\VariantTestComWrappers.cmd [FAIL]
Return code: 1
Raw output file: C:\h\w\AF5C0958\w\B3E30948\e\Interop\PInvoke\Reports\Interop.PInvoke\Variant\VariantTestComWrappers\VariantTestComWrappers.output.txt
Raw output:
BEGIN EXECUTION
"C:\h\w\AF5C0958\p\corerun.exe" -p "System.Runtime.InteropServices.BuiltInComInterop.IsSupported=false" VariantTestComWrappers.dll Test failed: TestLibrary.AssertTestException: Assert.IsTrue: at TestLibrary.Assert.HandleFail(String assertionName, String message) in TestLibrary.dll:token 0x6000021+0x11
at TestLibrary.Assert.IsTrue(Boolean condition, String message) in TestLibrary.dll:token 0x600000a+0x3
at Test.TestByValue(Boolean hasComSupport) in VariantTestComWrappers.dll:token 0x6000059+0x223
at Test.Main() in VariantTestComWrappers.dll:token 0x600005e+0xc
Invalid format. Expected VT_DISPATCH.

Does that means that ComWrappers has slightly different marshalling, or this is a bug? Should I fix that bug as part of PR?

[AaronRobinsonMSFT]

Does that means that ComWrappers has slightly different marshalling, or this is a bug? Should I fix that bug as part of PR?

@kant2002 It isn't clear to me which statement in the test is failing. Can you narrow it down to which one is the issue?

[kant2002]

@AaronRobinsonMSFT this line produce exception
https://github.com/dotnet/runtime/pull/53035/files#diff-1c679eb2a695bcba0de0c236544a305004b9e816151a677657a2528b2a039608R46
because there printed message from

runtime/src/tests/Interop/PInvoke/Variant/VariantNative.cpp

Line 152 in 57bdb95

printf("Invalid format. Expected VT_DISPATCH.\n");

[kant2002]

Honestly I did not run that. It's just reading logs. I'm yet to build single test project locally. Otherwise it's hard to me to allocate time (~1 hour). If you strictly need me to build, and validate my last statement, let me know. I will compile and troubleshoot in more details. But I think I point location to you properly.

[AaronRobinsonMSFT]

@kant2002 The issue here is a bug in the ComWrappers conversion logic for IDispatch. It is a part of the absolute mess that is the OLE support and how enum values are used as both request and result – yuck.

In the both case we detect if IDispatch is implemented but don't reduce the returned enum value to just ComIpType_Dispatch but return the input - which is the request not the result. The solution here is to return either ComIpType_Dispatch or ComIpType_Unknown but not ComIpType_Both.

runtime/src/coreclr/vm/interopconverter.cpp

Lines 183 to 205 in 959c327

	if (TryGetComIPFromObjectRefUsingComWrappers(*poref, &pUnk))
	{
	hr = S_OK;
	IUnknown* pvObj;
	if (ReqIpType & ComIpType_Dispatch)
	{
	hr = SafeQueryInterface(pUnk, IID_IDispatch, &pvObj);
	pUnk->Release();
	}
	else
	{
	pvObj = pUnk;
	}
	if (FAILED(hr))
	COMPlusThrowHR(hr);
	if (pFetchedIpType != NULL)
	*pFetchedIpType = ReqIpType;
	RETURN pvObj;
	}

[AaronRobinsonMSFT]

Should I fix that bug as part of PR?

Yes, that would be much appreciated.

[kant2002]

@AaronRobinsonMSFT can you take a look?

[kant2002]

Do not understand test failures. Please advice if this something which I'm responsible with?

[AaronRobinsonMSFT]

@kant2002 I would take a step back here and walk through this logic more fully. I think there was some confusion on when this was originally written and support IDispatch has uncovered that in the ComWrappers scenario.

/cc @elinor-fung

[AaronRobinsonMSFT]

This Release shouldn't be called indiscriminately here. We are checking for IDispatch now and it could fail, but ComIpType_Unknown must still be returned. Move this release into the success path below.

[kant2002]

Do I understand correctly that in discussed part of code, I should follow these rules?

ReqIpType = ComIpType_Both

1. QI to IDispatch - ok

pUnk->Release();
FetchedIpType = ComIpType_Dispatch;

2. QI to IDispatch - failed

pvObj = pUnk;
FetchedIpType = ComIpType_Unknown;

ReqIpType = ComIpType_IDispatch

3. QI to IDispatch - ok

pUnk->Release();
FetchedIpType = ComIpType_Dispatch;

4. QI to IDispatch - failed

COMPlusThrowHR(hr); // ????

ReqIpType = ComIpType_IUnknown

pvObj = pUnk;
FetchedIpType = ComIpType_Unknown;

[AaronRobinsonMSFT]

@kant2002 Yes.

[kant2002]

@AaronRobinsonMSFT is it possible that ComIpType_OuterUnknown would be passed to that location? Technically that will be handled by IUnknown case, but maybe there special processing needed.

[AaronRobinsonMSFT]

@kant2002 I don't think that ComIpType_OuterUnknown should be a concern here. The ComWrappers API does support aggregation but at present I am not sure how we would integrate at this point. I am okay not dealing with it at present.

[kant2002]

@AaronRobinsonMSFT then can you take a look?

[AaronRobinsonMSFT]

LGTM. Thank you.

[kant2002]

These tests split to be able test ComWrappers,
built-in COM enabled/disable mode.
See #50500, #51265

[kant2002]

Initially discovered as part of dotnet/runtimelab#1142
I do not know how to pass IsComSupported to test and how to read. Would like that somebody help me with that.
This PR to gather feedback on the implementation details, code split approach.

[AaronRobinsonMSFT]

I do not know how to pass IsComSupported to test and how to read. Would like that somebody help me with that.

Adding a feature flag to a test project is the same as passing it in the product. See https://github.com/dotnet/runtime/pull/52940/files#diff-c25cd81bf60eaf73ca87747baafae7fbfd0ac8a787da03b22382eff45316c9e5 and look for RuntimeHostConfigurationOption.

[AaronRobinsonMSFT]

/cc @LakshanF@elinor-fung

[kant2002]

I think I overcomplicate PR. I will revert changes, and will create couple projects in same folder. Seems to be that would be easier to maintain.

[LakshanF]

@kant2002, thanks for taking a look! Please also take a look at some test changes that are already present for library, and the pending PR, #52940, that has some tests for the runtime.

[kant2002]

@LakshanF this changes just for Variant marshalling. Hopefully current version is in spirit of what was for #52940

[kant2002]

Build was failed, since results was not sent to Helix

[LakshanF]

I see these 2 tests failing when built-in COM is disabled,

Interop\PInvoke\Variant\VariantTestBuiltInComDisabled\VariantTestBuiltInComDisabled.cmd
Interop\PInvoke\Variant\VariantTestComWrappers\VariantTestComWrappers.cmd

The first test has the following output,

BEGIN EXECUTION
"C:\h\w\AC52093C\p\corerun.exe" -p "System.Runtime.InteropServices.BuiltInComInterop.IsSupported=false" VariantTestBuiltInComDisabled.dll
Built-in COM Disabled?: True
Test failed: System.NotSupportedException: Built-in COM has been disabled via a feature switch. See https://aka.ms/dotnet-illink/com for more information.
at System.StubHelpers.ObjectMarshaler.ConvertToNative(Object objSrc, IntPtr pDstVariant)
at VariantNative.Marshal_ByValue_Object(Object obj)
at Test.TestByValue(Boolean hasComSupport) in VariantTestBuiltInComDisabled.dll:token 0x6000059+0x223
at Test.Main() in VariantTestBuiltInComDisabled.dll:token 0x600005e+0x34
Expected: 100
Actual: 101
END EXECUTION - FAILED

[kant2002]

Thanks for pointing me in the error log. I was able to find it afterwards. I see now only one error

 Interop\PInvoke\Variant\VariantTestComWrappers\VariantTestComWrappers.cmd [FAIL]
Return code: 1
Raw output file: C:\h\w\AF5C0958\w\B3E30948\e\Interop\PInvoke\Reports\Interop.PInvoke\Variant\VariantTestComWrappers\VariantTestComWrappers.output.txt
Raw output:
BEGIN EXECUTION
"C:\h\w\AF5C0958\p\corerun.exe" -p "System.Runtime.InteropServices.BuiltInComInterop.IsSupported=false" VariantTestComWrappers.dll Test failed: TestLibrary.AssertTestException: Assert.IsTrue: at TestLibrary.Assert.HandleFail(String assertionName, String message) in TestLibrary.dll:token 0x6000021+0x11
at TestLibrary.Assert.IsTrue(Boolean condition, String message) in TestLibrary.dll:token 0x600000a+0x3
at Test.TestByValue(Boolean hasComSupport) in VariantTestComWrappers.dll:token 0x6000059+0x223
at Test.Main() in VariantTestComWrappers.dll:token 0x600005e+0xc
Invalid format. Expected VT_DISPATCH.

Does that means that ComWrappers has slightly different marshalling, or this is a bug? Should I fix that bug as part of PR?

[AaronRobinsonMSFT]

Does that means that ComWrappers has slightly different marshalling, or this is a bug? Should I fix that bug as part of PR?

@kant2002 It isn't clear to me which statement in the test is failing. Can you narrow it down to which one is the issue?

[kant2002]

@AaronRobinsonMSFT this line produce exception
https://github.com/dotnet/runtime/pull/53035/files#diff-1c679eb2a695bcba0de0c236544a305004b9e816151a677657a2528b2a039608R46
because there printed message from

runtime/src/tests/Interop/PInvoke/Variant/VariantNative.cpp

Line 152 in 57bdb95

printf("Invalid format. Expected VT_DISPATCH.\n");

[kant2002]

Honestly I did not run that. It's just reading logs. I'm yet to build single test project locally. Otherwise it's hard to me to allocate time (~1 hour). If you strictly need me to build, and validate my last statement, let me know. I will compile and troubleshoot in more details. But I think I point location to you properly.

[AaronRobinsonMSFT]

@kant2002 The issue here is a bug in the ComWrappers conversion logic for IDispatch. It is a part of the absolute mess that is the OLE support and how enum values are used as both request and result – yuck.

In the both case we detect if IDispatch is implemented but don't reduce the returned enum value to just ComIpType_Dispatch but return the input - which is the request not the result. The solution here is to return either ComIpType_Dispatch or ComIpType_Unknown but not ComIpType_Both.

runtime/src/coreclr/vm/interopconverter.cpp

Lines 183 to 205 in 959c327

	if (TryGetComIPFromObjectRefUsingComWrappers(*poref, &pUnk))
	{
	hr = S_OK;
	IUnknown* pvObj;
	if (ReqIpType & ComIpType_Dispatch)
	{
	hr = SafeQueryInterface(pUnk, IID_IDispatch, &pvObj);
	pUnk->Release();
	}
	else
	{
	pvObj = pUnk;
	}
	if (FAILED(hr))
	COMPlusThrowHR(hr);
	if (pFetchedIpType != NULL)
	*pFetchedIpType = ReqIpType;
	RETURN pvObj;
	}

[AaronRobinsonMSFT]

Should I fix that bug as part of PR?

Yes, that would be much appreciated.

[kant2002]

@AaronRobinsonMSFT can you take a look?

[kant2002]

Do not understand test failures. Please advice if this something which I'm responsible with?

[AaronRobinsonMSFT]

@kant2002 I would take a step back here and walk through this logic more fully. I think there was some confusion on when this was originally written and support IDispatch has uncovered that in the ComWrappers scenario.

/cc @elinor-fung

[AaronRobinsonMSFT]

This Release shouldn't be called indiscriminately here. We are checking for IDispatch now and it could fail, but ComIpType_Unknown must still be returned. Move this release into the success path below.

[kant2002]

Do I understand correctly that in discussed part of code, I should follow these rules?

ReqIpType = ComIpType_Both

1. QI to IDispatch - ok

pUnk->Release();
FetchedIpType = ComIpType_Dispatch;

2. QI to IDispatch - failed

pvObj = pUnk;
FetchedIpType = ComIpType_Unknown;

ReqIpType = ComIpType_IDispatch

3. QI to IDispatch - ok

pUnk->Release();
FetchedIpType = ComIpType_Dispatch;

4. QI to IDispatch - failed

COMPlusThrowHR(hr); // ????

ReqIpType = ComIpType_IUnknown

pvObj = pUnk;
FetchedIpType = ComIpType_Unknown;

[AaronRobinsonMSFT]

@kant2002 Yes.

[kant2002]

@AaronRobinsonMSFT is it possible that ComIpType_OuterUnknown would be passed to that location? Technically that will be handled by IUnknown case, but maybe there special processing needed.

[AaronRobinsonMSFT]

@kant2002 I don't think that ComIpType_OuterUnknown should be a concern here. The ComWrappers API does support aggregation but at present I am not sure how we would integrate at this point. I am okay not dealing with it at present.

[kant2002]

@AaronRobinsonMSFT then can you take a look?

[AaronRobinsonMSFT]

LGTM. Thank you.

[kant2002]

These tests split to be able test ComWrappers,
built-in COM enabled/disable mode.
See #50500, #51265

[kant2002]

Initially discovered as part of dotnet/runtimelab#1142
I do not know how to pass IsComSupported to test and how to read. Would like that somebody help me with that.
This PR to gather feedback on the implementation details, code split approach.

[AaronRobinsonMSFT]

I do not know how to pass IsComSupported to test and how to read. Would like that somebody help me with that.

Adding a feature flag to a test project is the same as passing it in the product. See https://github.com/dotnet/runtime/pull/52940/files#diff-c25cd81bf60eaf73ca87747baafae7fbfd0ac8a787da03b22382eff45316c9e5 and look for RuntimeHostConfigurationOption.

[AaronRobinsonMSFT]

/cc @LakshanF@elinor-fung

[kant2002]

I think I overcomplicate PR. I will revert changes, and will create couple projects in same folder. Seems to be that would be easier to maintain.

[LakshanF]

@kant2002, thanks for taking a look! Please also take a look at some test changes that are already present for library, and the pending PR, #52940, that has some tests for the runtime.

[kant2002]

@LakshanF this changes just for Variant marshalling. Hopefully current version is in spirit of what was for #52940

[kant2002]

Build was failed, since results was not sent to Helix

[LakshanF]

I see these 2 tests failing when built-in COM is disabled,

Interop\PInvoke\Variant\VariantTestBuiltInComDisabled\VariantTestBuiltInComDisabled.cmd
Interop\PInvoke\Variant\VariantTestComWrappers\VariantTestComWrappers.cmd

The first test has the following output,

BEGIN EXECUTION
"C:\h\w\AC52093C\p\corerun.exe" -p "System.Runtime.InteropServices.BuiltInComInterop.IsSupported=false" VariantTestBuiltInComDisabled.dll
Built-in COM Disabled?: True
Test failed: System.NotSupportedException: Built-in COM has been disabled via a feature switch. See https://aka.ms/dotnet-illink/com for more information.
at System.StubHelpers.ObjectMarshaler.ConvertToNative(Object objSrc, IntPtr pDstVariant)
at VariantNative.Marshal_ByValue_Object(Object obj)
at Test.TestByValue(Boolean hasComSupport) in VariantTestBuiltInComDisabled.dll:token 0x6000059+0x223
at Test.Main() in VariantTestBuiltInComDisabled.dll:token 0x600005e+0x34
Expected: 100
Actual: 101
END EXECUTION - FAILED

[kant2002]

Thanks for pointing me in the error log. I was able to find it afterwards. I see now only one error

 Interop\PInvoke\Variant\VariantTestComWrappers\VariantTestComWrappers.cmd [FAIL]
Return code: 1
Raw output file: C:\h\w\AF5C0958\w\B3E30948\e\Interop\PInvoke\Reports\Interop.PInvoke\Variant\VariantTestComWrappers\VariantTestComWrappers.output.txt
Raw output:
BEGIN EXECUTION
"C:\h\w\AF5C0958\p\corerun.exe" -p "System.Runtime.InteropServices.BuiltInComInterop.IsSupported=false" VariantTestComWrappers.dll Test failed: TestLibrary.AssertTestException: Assert.IsTrue: at TestLibrary.Assert.HandleFail(String assertionName, String message) in TestLibrary.dll:token 0x6000021+0x11
at TestLibrary.Assert.IsTrue(Boolean condition, String message) in TestLibrary.dll:token 0x600000a+0x3
at Test.TestByValue(Boolean hasComSupport) in VariantTestComWrappers.dll:token 0x6000059+0x223
at Test.Main() in VariantTestComWrappers.dll:token 0x600005e+0xc
Invalid format. Expected VT_DISPATCH.

Does that means that ComWrappers has slightly different marshalling, or this is a bug? Should I fix that bug as part of PR?

[AaronRobinsonMSFT]

Does that means that ComWrappers has slightly different marshalling, or this is a bug? Should I fix that bug as part of PR?

@kant2002 It isn't clear to me which statement in the test is failing. Can you narrow it down to which one is the issue?

[kant2002]

@AaronRobinsonMSFT this line produce exception
https://github.com/dotnet/runtime/pull/53035/files#diff-1c679eb2a695bcba0de0c236544a305004b9e816151a677657a2528b2a039608R46
because there printed message from

runtime/src/tests/Interop/PInvoke/Variant/VariantNative.cpp

Line 152 in 57bdb95

printf("Invalid format. Expected VT_DISPATCH.\n");

[kant2002]

Honestly I did not run that. It's just reading logs. I'm yet to build single test project locally. Otherwise it's hard to me to allocate time (~1 hour). If you strictly need me to build, and validate my last statement, let me know. I will compile and troubleshoot in more details. But I think I point location to you properly.

[AaronRobinsonMSFT]

@kant2002 The issue here is a bug in the ComWrappers conversion logic for IDispatch. It is a part of the absolute mess that is the OLE support and how enum values are used as both request and result – yuck.

In the both case we detect if IDispatch is implemented but don't reduce the returned enum value to just ComIpType_Dispatch but return the input - which is the request not the result. The solution here is to return either ComIpType_Dispatch or ComIpType_Unknown but not ComIpType_Both.

runtime/src/coreclr/vm/interopconverter.cpp

Lines 183 to 205 in 959c327

	if (TryGetComIPFromObjectRefUsingComWrappers(*poref, &pUnk))
	{
	hr = S_OK;
	IUnknown* pvObj;
	if (ReqIpType & ComIpType_Dispatch)
	{
	hr = SafeQueryInterface(pUnk, IID_IDispatch, &pvObj);
	pUnk->Release();
	}
	else
	{
	pvObj = pUnk;
	}
	if (FAILED(hr))
	COMPlusThrowHR(hr);
	if (pFetchedIpType != NULL)
	*pFetchedIpType = ReqIpType;
	RETURN pvObj;
	}

[AaronRobinsonMSFT]

Should I fix that bug as part of PR?

Yes, that would be much appreciated.

[kant2002]

@AaronRobinsonMSFT can you take a look?

[kant2002]

Do not understand test failures. Please advice if this something which I'm responsible with?

[AaronRobinsonMSFT]

@kant2002 I would take a step back here and walk through this logic more fully. I think there was some confusion on when this was originally written and support IDispatch has uncovered that in the ComWrappers scenario.

/cc @elinor-fung

[AaronRobinsonMSFT]

This Release shouldn't be called indiscriminately here. We are checking for IDispatch now and it could fail, but ComIpType_Unknown must still be returned. Move this release into the success path below.

[kant2002]

Do I understand correctly that in discussed part of code, I should follow these rules?

ReqIpType = ComIpType_Both

1. QI to IDispatch - ok

pUnk->Release();
FetchedIpType = ComIpType_Dispatch;

2. QI to IDispatch - failed

pvObj = pUnk;
FetchedIpType = ComIpType_Unknown;

ReqIpType = ComIpType_IDispatch

3. QI to IDispatch - ok

pUnk->Release();
FetchedIpType = ComIpType_Dispatch;

4. QI to IDispatch - failed

COMPlusThrowHR(hr); // ????

ReqIpType = ComIpType_IUnknown

pvObj = pUnk;
FetchedIpType = ComIpType_Unknown;

[AaronRobinsonMSFT]

@kant2002 Yes.

[kant2002]

@AaronRobinsonMSFT is it possible that ComIpType_OuterUnknown would be passed to that location? Technically that will be handled by IUnknown case, but maybe there special processing needed.

[AaronRobinsonMSFT]

@kant2002 I don't think that ComIpType_OuterUnknown should be a concern here. The ComWrappers API does support aggregation but at present I am not sure how we would integrate at this point. I am okay not dealing with it at present.

[kant2002]

@AaronRobinsonMSFT then can you take a look?

[AaronRobinsonMSFT]

LGTM. Thank you.

[kant2002]

These tests split to be able test ComWrappers,
built-in COM enabled/disable mode.
See #50500, #51265

[kant2002]

Initially discovered as part of dotnet/runtimelab#1142
I do not know how to pass IsComSupported to test and how to read. Would like that somebody help me with that.
This PR to gather feedback on the implementation details, code split approach.

[AaronRobinsonMSFT]

I do not know how to pass IsComSupported to test and how to read. Would like that somebody help me with that.

Adding a feature flag to a test project is the same as passing it in the product. See https://github.com/dotnet/runtime/pull/52940/files#diff-c25cd81bf60eaf73ca87747baafae7fbfd0ac8a787da03b22382eff45316c9e5 and look for RuntimeHostConfigurationOption.

[AaronRobinsonMSFT]

/cc @LakshanF@elinor-fung

[kant2002]

I think I overcomplicate PR. I will revert changes, and will create couple projects in same folder. Seems to be that would be easier to maintain.

[LakshanF]

@kant2002, thanks for taking a look! Please also take a look at some test changes that are already present for library, and the pending PR, #52940, that has some tests for the runtime.

[kant2002]

@LakshanF this changes just for Variant marshalling. Hopefully current version is in spirit of what was for #52940

[kant2002]

Build was failed, since results was not sent to Helix

[LakshanF]

I see these 2 tests failing when built-in COM is disabled,

Interop\PInvoke\Variant\VariantTestBuiltInComDisabled\VariantTestBuiltInComDisabled.cmd
Interop\PInvoke\Variant\VariantTestComWrappers\VariantTestComWrappers.cmd

The first test has the following output,

BEGIN EXECUTION
"C:\h\w\AC52093C\p\corerun.exe" -p "System.Runtime.InteropServices.BuiltInComInterop.IsSupported=false" VariantTestBuiltInComDisabled.dll
Built-in COM Disabled?: True
Test failed: System.NotSupportedException: Built-in COM has been disabled via a feature switch. See https://aka.ms/dotnet-illink/com for more information.
at System.StubHelpers.ObjectMarshaler.ConvertToNative(Object objSrc, IntPtr pDstVariant)
at VariantNative.Marshal_ByValue_Object(Object obj)
at Test.TestByValue(Boolean hasComSupport) in VariantTestBuiltInComDisabled.dll:token 0x6000059+0x223
at Test.Main() in VariantTestBuiltInComDisabled.dll:token 0x600005e+0x34
Expected: 100
Actual: 101
END EXECUTION - FAILED

[kant2002]

Thanks for pointing me in the error log. I was able to find it afterwards. I see now only one error

 Interop\PInvoke\Variant\VariantTestComWrappers\VariantTestComWrappers.cmd [FAIL]
Return code: 1
Raw output file: C:\h\w\AF5C0958\w\B3E30948\e\Interop\PInvoke\Reports\Interop.PInvoke\Variant\VariantTestComWrappers\VariantTestComWrappers.output.txt
Raw output:
BEGIN EXECUTION
"C:\h\w\AF5C0958\p\corerun.exe" -p "System.Runtime.InteropServices.BuiltInComInterop.IsSupported=false" VariantTestComWrappers.dll Test failed: TestLibrary.AssertTestException: Assert.IsTrue: at TestLibrary.Assert.HandleFail(String assertionName, String message) in TestLibrary.dll:token 0x6000021+0x11
at TestLibrary.Assert.IsTrue(Boolean condition, String message) in TestLibrary.dll:token 0x600000a+0x3
at Test.TestByValue(Boolean hasComSupport) in VariantTestComWrappers.dll:token 0x6000059+0x223
at Test.Main() in VariantTestComWrappers.dll:token 0x600005e+0xc
Invalid format. Expected VT_DISPATCH.

Does that means that ComWrappers has slightly different marshalling, or this is a bug? Should I fix that bug as part of PR?

[AaronRobinsonMSFT]

Does that means that ComWrappers has slightly different marshalling, or this is a bug? Should I fix that bug as part of PR?

@kant2002 It isn't clear to me which statement in the test is failing. Can you narrow it down to which one is the issue?

[kant2002]

@AaronRobinsonMSFT this line produce exception
https://github.com/dotnet/runtime/pull/53035/files#diff-1c679eb2a695bcba0de0c236544a305004b9e816151a677657a2528b2a039608R46
because there printed message from

runtime/src/tests/Interop/PInvoke/Variant/VariantNative.cpp

Line 152 in 57bdb95

printf("Invalid format. Expected VT_DISPATCH.\n");

[kant2002]

Honestly I did not run that. It's just reading logs. I'm yet to build single test project locally. Otherwise it's hard to me to allocate time (~1 hour). If you strictly need me to build, and validate my last statement, let me know. I will compile and troubleshoot in more details. But I think I point location to you properly.

[AaronRobinsonMSFT]

@kant2002 The issue here is a bug in the ComWrappers conversion logic for IDispatch. It is a part of the absolute mess that is the OLE support and how enum values are used as both request and result – yuck.

In the both case we detect if IDispatch is implemented but don't reduce the returned enum value to just ComIpType_Dispatch but return the input - which is the request not the result. The solution here is to return either ComIpType_Dispatch or ComIpType_Unknown but not ComIpType_Both.

runtime/src/coreclr/vm/interopconverter.cpp

Lines 183 to 205 in 959c327

	if (TryGetComIPFromObjectRefUsingComWrappers(*poref, &pUnk))
	{
	hr = S_OK;
	IUnknown* pvObj;
	if (ReqIpType & ComIpType_Dispatch)
	{
	hr = SafeQueryInterface(pUnk, IID_IDispatch, &pvObj);
	pUnk->Release();
	}
	else
	{
	pvObj = pUnk;
	}
	if (FAILED(hr))
	COMPlusThrowHR(hr);
	if (pFetchedIpType != NULL)
	*pFetchedIpType = ReqIpType;
	RETURN pvObj;
	}

[AaronRobinsonMSFT]

Should I fix that bug as part of PR?

Yes, that would be much appreciated.

[kant2002]

@AaronRobinsonMSFT can you take a look?

[kant2002]

Do not understand test failures. Please advice if this something which I'm responsible with?

[AaronRobinsonMSFT]

@kant2002 I would take a step back here and walk through this logic more fully. I think there was some confusion on when this was originally written and support IDispatch has uncovered that in the ComWrappers scenario.

/cc @elinor-fung

[AaronRobinsonMSFT]

This Release shouldn't be called indiscriminately here. We are checking for IDispatch now and it could fail, but ComIpType_Unknown must still be returned. Move this release into the success path below.

[kant2002]

Do I understand correctly that in discussed part of code, I should follow these rules?

ReqIpType = ComIpType_Both

1. QI to IDispatch - ok

pUnk->Release();
FetchedIpType = ComIpType_Dispatch;

2. QI to IDispatch - failed

pvObj = pUnk;
FetchedIpType = ComIpType_Unknown;

ReqIpType = ComIpType_IDispatch

3. QI to IDispatch - ok

pUnk->Release();
FetchedIpType = ComIpType_Dispatch;

4. QI to IDispatch - failed

COMPlusThrowHR(hr); // ????

ReqIpType = ComIpType_IUnknown

pvObj = pUnk;
FetchedIpType = ComIpType_Unknown;

[AaronRobinsonMSFT]

@kant2002 Yes.

[kant2002]

@AaronRobinsonMSFT is it possible that ComIpType_OuterUnknown would be passed to that location? Technically that will be handled by IUnknown case, but maybe there special processing needed.

[AaronRobinsonMSFT]

@kant2002 I don't think that ComIpType_OuterUnknown should be a concern here. The ComWrappers API does support aggregation but at present I am not sure how we would integrate at this point. I am okay not dealing with it at present.

[kant2002]

@AaronRobinsonMSFT then can you take a look?

[AaronRobinsonMSFT]

LGTM. Thank you.

[kant2002]

These tests split to be able test ComWrappers,
built-in COM enabled/disable mode.
See #50500, #51265

[kant2002]

Initially discovered as part of dotnet/runtimelab#1142
I do not know how to pass IsComSupported to test and how to read. Would like that somebody help me with that.
This PR to gather feedback on the implementation details, code split approach.

[AaronRobinsonMSFT]

I do not know how to pass IsComSupported to test and how to read. Would like that somebody help me with that.

Adding a feature flag to a test project is the same as passing it in the product. See https://github.com/dotnet/runtime/pull/52940/files#diff-c25cd81bf60eaf73ca87747baafae7fbfd0ac8a787da03b22382eff45316c9e5 and look for RuntimeHostConfigurationOption.

[AaronRobinsonMSFT]

/cc @LakshanF@elinor-fung

[kant2002]

I think I overcomplicate PR. I will revert changes, and will create couple projects in same folder. Seems to be that would be easier to maintain.

[LakshanF]

@kant2002, thanks for taking a look! Please also take a look at some test changes that are already present for library, and the pending PR, #52940, that has some tests for the runtime.

[kant2002]

@LakshanF this changes just for Variant marshalling. Hopefully current version is in spirit of what was for #52940

[kant2002]

Build was failed, since results was not sent to Helix

[LakshanF]

I see these 2 tests failing when built-in COM is disabled,

Interop\PInvoke\Variant\VariantTestBuiltInComDisabled\VariantTestBuiltInComDisabled.cmd
Interop\PInvoke\Variant\VariantTestComWrappers\VariantTestComWrappers.cmd

The first test has the following output,

BEGIN EXECUTION
"C:\h\w\AC52093C\p\corerun.exe" -p "System.Runtime.InteropServices.BuiltInComInterop.IsSupported=false" VariantTestBuiltInComDisabled.dll
Built-in COM Disabled?: True
Test failed: System.NotSupportedException: Built-in COM has been disabled via a feature switch. See https://aka.ms/dotnet-illink/com for more information.
at System.StubHelpers.ObjectMarshaler.ConvertToNative(Object objSrc, IntPtr pDstVariant)
at VariantNative.Marshal_ByValue_Object(Object obj)
at Test.TestByValue(Boolean hasComSupport) in VariantTestBuiltInComDisabled.dll:token 0x6000059+0x223
at Test.Main() in VariantTestBuiltInComDisabled.dll:token 0x600005e+0x34
Expected: 100
Actual: 101
END EXECUTION - FAILED

[kant2002]

Thanks for pointing me in the error log. I was able to find it afterwards. I see now only one error

 Interop\PInvoke\Variant\VariantTestComWrappers\VariantTestComWrappers.cmd [FAIL]
Return code: 1
Raw output file: C:\h\w\AF5C0958\w\B3E30948\e\Interop\PInvoke\Reports\Interop.PInvoke\Variant\VariantTestComWrappers\VariantTestComWrappers.output.txt
Raw output:
BEGIN EXECUTION
"C:\h\w\AF5C0958\p\corerun.exe" -p "System.Runtime.InteropServices.BuiltInComInterop.IsSupported=false" VariantTestComWrappers.dll Test failed: TestLibrary.AssertTestException: Assert.IsTrue: at TestLibrary.Assert.HandleFail(String assertionName, String message) in TestLibrary.dll:token 0x6000021+0x11
at TestLibrary.Assert.IsTrue(Boolean condition, String message) in TestLibrary.dll:token 0x600000a+0x3
at Test.TestByValue(Boolean hasComSupport) in VariantTestComWrappers.dll:token 0x6000059+0x223
at Test.Main() in VariantTestComWrappers.dll:token 0x600005e+0xc
Invalid format. Expected VT_DISPATCH.

Does that means that ComWrappers has slightly different marshalling, or this is a bug? Should I fix that bug as part of PR?

[AaronRobinsonMSFT]

Does that means that ComWrappers has slightly different marshalling, or this is a bug? Should I fix that bug as part of PR?

@kant2002 It isn't clear to me which statement in the test is failing. Can you narrow it down to which one is the issue?

[kant2002]

@AaronRobinsonMSFT this line produce exception
https://github.com/dotnet/runtime/pull/53035/files#diff-1c679eb2a695bcba0de0c236544a305004b9e816151a677657a2528b2a039608R46
because there printed message from

runtime/src/tests/Interop/PInvoke/Variant/VariantNative.cpp

Line 152 in 57bdb95

printf("Invalid format. Expected VT_DISPATCH.\n");

[kant2002]

Honestly I did not run that. It's just reading logs. I'm yet to build single test project locally. Otherwise it's hard to me to allocate time (~1 hour). If you strictly need me to build, and validate my last statement, let me know. I will compile and troubleshoot in more details. But I think I point location to you properly.

[AaronRobinsonMSFT]

@kant2002 The issue here is a bug in the ComWrappers conversion logic for IDispatch. It is a part of the absolute mess that is the OLE support and how enum values are used as both request and result – yuck.

In the both case we detect if IDispatch is implemented but don't reduce the returned enum value to just ComIpType_Dispatch but return the input - which is the request not the result. The solution here is to return either ComIpType_Dispatch or ComIpType_Unknown but not ComIpType_Both.

runtime/src/coreclr/vm/interopconverter.cpp

Lines 183 to 205 in 959c327

	if (TryGetComIPFromObjectRefUsingComWrappers(*poref, &pUnk))
	{
	hr = S_OK;
	IUnknown* pvObj;
	if (ReqIpType & ComIpType_Dispatch)
	{
	hr = SafeQueryInterface(pUnk, IID_IDispatch, &pvObj);
	pUnk->Release();
	}
	else
	{
	pvObj = pUnk;
	}
	if (FAILED(hr))
	COMPlusThrowHR(hr);
	if (pFetchedIpType != NULL)
	*pFetchedIpType = ReqIpType;
	RETURN pvObj;
	}

[AaronRobinsonMSFT]

Should I fix that bug as part of PR?

Yes, that would be much appreciated.

[kant2002]

@AaronRobinsonMSFT can you take a look?

[kant2002]

Do not understand test failures. Please advice if this something which I'm responsible with?

[AaronRobinsonMSFT]

@kant2002 I would take a step back here and walk through this logic more fully. I think there was some confusion on when this was originally written and support IDispatch has uncovered that in the ComWrappers scenario.

/cc @elinor-fung

[AaronRobinsonMSFT]

This Release shouldn't be called indiscriminately here. We are checking for IDispatch now and it could fail, but ComIpType_Unknown must still be returned. Move this release into the success path below.

[kant2002]

Do I understand correctly that in discussed part of code, I should follow these rules?

ReqIpType = ComIpType_Both

1. QI to IDispatch - ok

pUnk->Release();
FetchedIpType = ComIpType_Dispatch;

2. QI to IDispatch - failed

pvObj = pUnk;
FetchedIpType = ComIpType_Unknown;

ReqIpType = ComIpType_IDispatch

3. QI to IDispatch - ok

pUnk->Release();
FetchedIpType = ComIpType_Dispatch;

4. QI to IDispatch - failed

COMPlusThrowHR(hr); // ????

ReqIpType = ComIpType_IUnknown

pvObj = pUnk;
FetchedIpType = ComIpType_Unknown;

[AaronRobinsonMSFT]

@kant2002 Yes.

[kant2002]

@AaronRobinsonMSFT is it possible that ComIpType_OuterUnknown would be passed to that location? Technically that will be handled by IUnknown case, but maybe there special processing needed.

[AaronRobinsonMSFT]

@kant2002 I don't think that ComIpType_OuterUnknown should be a concern here. The ComWrappers API does support aggregation but at present I am not sure how we would integrate at this point. I am okay not dealing with it at present.

[kant2002]

@AaronRobinsonMSFT then can you take a look?

[AaronRobinsonMSFT]

LGTM. Thank you.

[kant2002]

These tests split to be able test ComWrappers,
built-in COM enabled/disable mode.
See #50500, #51265

[kant2002]

Initially discovered as part of dotnet/runtimelab#1142
I do not know how to pass IsComSupported to test and how to read. Would like that somebody help me with that.
This PR to gather feedback on the implementation details, code split approach.

[AaronRobinsonMSFT]

I do not know how to pass IsComSupported to test and how to read. Would like that somebody help me with that.

Adding a feature flag to a test project is the same as passing it in the product. See https://github.com/dotnet/runtime/pull/52940/files#diff-c25cd81bf60eaf73ca87747baafae7fbfd0ac8a787da03b22382eff45316c9e5 and look for RuntimeHostConfigurationOption.

[AaronRobinsonMSFT]

/cc @LakshanF@elinor-fung

[kant2002]

I think I overcomplicate PR. I will revert changes, and will create couple projects in same folder. Seems to be that would be easier to maintain.

[LakshanF]

@kant2002, thanks for taking a look! Please also take a look at some test changes that are already present for library, and the pending PR, #52940, that has some tests for the runtime.

[kant2002]

@LakshanF this changes just for Variant marshalling. Hopefully current version is in spirit of what was for #52940

[kant2002]

Build was failed, since results was not sent to Helix

[LakshanF]

I see these 2 tests failing when built-in COM is disabled,

Interop\PInvoke\Variant\VariantTestBuiltInComDisabled\VariantTestBuiltInComDisabled.cmd
Interop\PInvoke\Variant\VariantTestComWrappers\VariantTestComWrappers.cmd

The first test has the following output,

BEGIN EXECUTION
"C:\h\w\AC52093C\p\corerun.exe" -p "System.Runtime.InteropServices.BuiltInComInterop.IsSupported=false" VariantTestBuiltInComDisabled.dll
Built-in COM Disabled?: True
Test failed: System.NotSupportedException: Built-in COM has been disabled via a feature switch. See https://aka.ms/dotnet-illink/com for more information.
at System.StubHelpers.ObjectMarshaler.ConvertToNative(Object objSrc, IntPtr pDstVariant)
at VariantNative.Marshal_ByValue_Object(Object obj)
at Test.TestByValue(Boolean hasComSupport) in VariantTestBuiltInComDisabled.dll:token 0x6000059+0x223
at Test.Main() in VariantTestBuiltInComDisabled.dll:token 0x600005e+0x34
Expected: 100
Actual: 101
END EXECUTION - FAILED

[kant2002]

Thanks for pointing me in the error log. I was able to find it afterwards. I see now only one error

 Interop\PInvoke\Variant\VariantTestComWrappers\VariantTestComWrappers.cmd [FAIL]
Return code: 1
Raw output file: C:\h\w\AF5C0958\w\B3E30948\e\Interop\PInvoke\Reports\Interop.PInvoke\Variant\VariantTestComWrappers\VariantTestComWrappers.output.txt
Raw output:
BEGIN EXECUTION
"C:\h\w\AF5C0958\p\corerun.exe" -p "System.Runtime.InteropServices.BuiltInComInterop.IsSupported=false" VariantTestComWrappers.dll Test failed: TestLibrary.AssertTestException: Assert.IsTrue: at TestLibrary.Assert.HandleFail(String assertionName, String message) in TestLibrary.dll:token 0x6000021+0x11
at TestLibrary.Assert.IsTrue(Boolean condition, String message) in TestLibrary.dll:token 0x600000a+0x3
at Test.TestByValue(Boolean hasComSupport) in VariantTestComWrappers.dll:token 0x6000059+0x223
at Test.Main() in VariantTestComWrappers.dll:token 0x600005e+0xc
Invalid format. Expected VT_DISPATCH.

Does that means that ComWrappers has slightly different marshalling, or this is a bug? Should I fix that bug as part of PR?

[AaronRobinsonMSFT]

Does that means that ComWrappers has slightly different marshalling, or this is a bug? Should I fix that bug as part of PR?

@kant2002 It isn't clear to me which statement in the test is failing. Can you narrow it down to which one is the issue?

[kant2002]

@AaronRobinsonMSFT this line produce exception
https://github.com/dotnet/runtime/pull/53035/files#diff-1c679eb2a695bcba0de0c236544a305004b9e816151a677657a2528b2a039608R46
because there printed message from

runtime/src/tests/Interop/PInvoke/Variant/VariantNative.cpp

Line 152 in 57bdb95

printf("Invalid format. Expected VT_DISPATCH.\n");

[kant2002]

Honestly I did not run that. It's just reading logs. I'm yet to build single test project locally. Otherwise it's hard to me to allocate time (~1 hour). If you strictly need me to build, and validate my last statement, let me know. I will compile and troubleshoot in more details. But I think I point location to you properly.

[AaronRobinsonMSFT]

@kant2002 The issue here is a bug in the ComWrappers conversion logic for IDispatch. It is a part of the absolute mess that is the OLE support and how enum values are used as both request and result – yuck.

In the both case we detect if IDispatch is implemented but don't reduce the returned enum value to just ComIpType_Dispatch but return the input - which is the request not the result. The solution here is to return either ComIpType_Dispatch or ComIpType_Unknown but not ComIpType_Both.

runtime/src/coreclr/vm/interopconverter.cpp

Lines 183 to 205 in 959c327

	if (TryGetComIPFromObjectRefUsingComWrappers(*poref, &pUnk))
	{
	hr = S_OK;
	IUnknown* pvObj;
	if (ReqIpType & ComIpType_Dispatch)
	{
	hr = SafeQueryInterface(pUnk, IID_IDispatch, &pvObj);
	pUnk->Release();
	}
	else
	{
	pvObj = pUnk;
	}
	if (FAILED(hr))
	COMPlusThrowHR(hr);
	if (pFetchedIpType != NULL)
	*pFetchedIpType = ReqIpType;
	RETURN pvObj;
	}

[AaronRobinsonMSFT]

Should I fix that bug as part of PR?

Yes, that would be much appreciated.

[kant2002]

@AaronRobinsonMSFT can you take a look?

[kant2002]

Do not understand test failures. Please advice if this something which I'm responsible with?

[AaronRobinsonMSFT]

@kant2002 I would take a step back here and walk through this logic more fully. I think there was some confusion on when this was originally written and support IDispatch has uncovered that in the ComWrappers scenario.

/cc @elinor-fung

[AaronRobinsonMSFT]

This Release shouldn't be called indiscriminately here. We are checking for IDispatch now and it could fail, but ComIpType_Unknown must still be returned. Move this release into the success path below.

[kant2002]

Do I understand correctly that in discussed part of code, I should follow these rules?

ReqIpType = ComIpType_Both

1. QI to IDispatch - ok

pUnk->Release();
FetchedIpType = ComIpType_Dispatch;

2. QI to IDispatch - failed

pvObj = pUnk;
FetchedIpType = ComIpType_Unknown;

ReqIpType = ComIpType_IDispatch

3. QI to IDispatch - ok

pUnk->Release();
FetchedIpType = ComIpType_Dispatch;

4. QI to IDispatch - failed

COMPlusThrowHR(hr); // ????

ReqIpType = ComIpType_IUnknown

pvObj = pUnk;
FetchedIpType = ComIpType_Unknown;

[AaronRobinsonMSFT]

@kant2002 Yes.

[kant2002]

@AaronRobinsonMSFT is it possible that ComIpType_OuterUnknown would be passed to that location? Technically that will be handled by IUnknown case, but maybe there special processing needed.

[AaronRobinsonMSFT]

@kant2002 I don't think that ComIpType_OuterUnknown should be a concern here. The ComWrappers API does support aggregation but at present I am not sure how we would integrate at this point. I am okay not dealing with it at present.

[kant2002]

@AaronRobinsonMSFT then can you take a look?

[AaronRobinsonMSFT]

LGTM. Thank you.