Parameter HostItem instead of correct Type

[DanielGerlach2]

I may have found another problem with the ComVisible setting for projects/assemblies and hope you can help me with a "simple" setting so that this works correctly.

I have added a sample project (see below) where the behavior is understandable.

Here is a textual description of the processing in the code, so that it may be easier to understand:
The App class has a Run method which initializes the needed objects and calls a "main" function via the Clearscript.
In the "Main" function, a parameter named "Record" is passed to the function App.RunPlugin, which is then called.
Important: the record is NOT passed to the script engine as an AddHostObject, but as a parameter (pRecord).
When the RunPlugin function is now called/executed, the parameter (Param1) is passed as Microsoft.ClearScript.HostItem instead of tstClearScript.Record.

Please do not question the logic in this example project; it is greatly simplified, but illustrates the problem.

Things get really interesting when you change the ComVisible attribute (<Assembly: ComVisible(True)>) in the AssemblyInfo.vb file from True to False.
Then the type is passed correctly.

Is there a setting that needs to be configured when initializing the ScriptEngine to ensure the type is passed correctly?

SampleProject

[ClearScriptLib]

Hello @DanielGerlach2,

Thanks for posting your sample!

Unfortunately, it left us confused, as its behavior appears identical regardless of the ComVisible values. In every case, the script calls Session.GetFieldType, which returns FieldTypeEnum.ftUnknown, leading to the output "undefined".

Are we missing something? Is that not the correct behavior? If it is, how do we reproduce the incorrect behavior?

Cheers!

[DanielGerlach2]

I'm afraid you didn't get the correct version of the example project.

The code described is from an older request and doesn't match the example project mentioned above.

[ClearScriptLib]

I'm afraid you didn't get the correct version of the example project.

Ah, you're right! Sorry about that! Not sure how it happened 🤣

Anyway, the behavior you're seeing is expected. By exposing the App object in DirectAccess mode, you cut ClearScript out of the loop when it comes to marshaling, so it gets no opportunity to unwrap the Param1 argument.

Unfortunately, while AddHostObject supports DirectAccess, there's currently no way to specify that behavior when passing arguments. Therefore, the only workaround would be to expose Record via AddHostObject and have main use that instead of a parameter.

DirectAccess was simply never intended for use with managed objects. Nevertheless, it might be possible to provide some way to pass arguments in that mode. We'll be happy to hear any ideas!

[DanielGerlach2]

Thank you for your explanation.

Your proposed solution is understandable and plausible, but not applicable to our situation.

We are migrating from MSScriptControl to ClearScript as our scripting component.
Since both we and the customer already have script code, which may have been modified/implemented by the customer, it is neither possible nor permissible to check and modify all signatures or functions as part of an update.
Our goal is for the code to continue functioning exactly as it is, which has worked quite well so far, but we are now facing the hurdle described above.

We would appreciate it if you could provide this accordingly.

Have a nice weekend, best regards

[ClearScriptLib]

Hi @DanielGerlach2,

We would appreciate it if you could provide this accordingly.

To do that, we need to understand your scenario better. It's not about questioning your logic but finding a solution that works within your restrictions, makes sense from an API perspective, and provides a permanent fix free of hidden gotchas.

To that end, can you tell us why you're using DirectAccess? Are you using it only for the App object, or do you need to expose all .NET objects in that manner, including all objects the host passes to script functions? Anything you could tell us – if not about your application, then about your calling patterns across the host-script boundary – might be helpful.

Thanks!

[DanielGerlach2]

Regarding the other inquiries, I've reviewed our current code again.

We encountered the following errors/issues:

• Comparison of enums -> resolved by using DirectAccess.
• Optional parameters -> resolved by using DirectAccess.
• Access to "complex objects" -> error when evaluating ComVisible (because objects are included via DirectAccess).

Since we come from the MSScriptControl world, as mentioned above, some objects are passed via AddHostObject (DirectAccess).
These are typically globally available elements, which in turn contain functions/properties/enums... that can be used in the script code.

Other objects are passed as parameters (by the host) to script functions. (This corresponds to the code in the example project.)

Since most of the problems were solved by passing the objects via DirectAccess, we believe it makes sense to also provide a "DirectAccess" option for "passed parameter".

[ClearScriptLib]

Hi @DanielGerlach2,

The problem is that ClearScript has no involvement in script code's communication with DirectAccess objects. If you expose everything that way, then ClearScript adds no value over MSScriptControl, and we have no way to predict or affect the resulting behavior.

Your experience is a good example. DirectAccess helped you resolve one issue but introduced several others.

DirectAccess was intended for use with unmanaged objects designed specifically for Windows Script engines – objects whose behavior degrades if they pass through .NET's COM layers. We can't support DirectAccess with managed objects – again, because ClearScript has no control once the object is in the script engine's hands – except under very specific conditions.

If we understand correctly, there are two issues if you don't use DirectAccess:

1. ClearScript's method binder doesn't support sparse argument lists.
2. Enums exposed by ClearScript aren't comparable with integers.

ClearScript 7.5 includes a fix for the first issue. The reflection binder now supports sparse argument lists.

As for the second issue, we suggested a solution here. Is it not practical in your case?

Thanks!

[DanielGerlach2]

Thank you for your reply.

You're right that with ClearScript 7.5, functions with missing optional parameters can be used even without DirectAccess.
Unfortunately, this only helps to a limited extent, since the real problem is comparing enums with integers.

While it would be possible in principle to provide the proposed adapters for enums, this is not feasible in this project due to the associated effort.
We don't just have a few enums, but a large number of them, which are also distributed across different assemblies and classes.

Internally, Enums are all integral numeric types, which can be directly compared to integer values, at least in vb.net code.

e.g.

Public Class TestEnumeration

	Enum tstEnum
		value1 = 1
		value2 = 2
		value3 = 3
	End Enum

	Public Sub Test()
		Dim varValue1 As tstEnum = tstEnum.value1
		Dim varValue2 As tstEnum = 1

		If varValue1 = varValue2 Then

		End If

		If varValue1 = 1 Then

		End If

		If varValue1 = tstEnum.value1 Then

		End If

	End Sub

End Class

The example shows that assignment as an integer or as an enum is possible; and also that comparison between enum and integer or enum and enum is possible without (compiler) errors.
Perhaps a control property for the script engine would be advisable, providing this as an option, similar to these properties.

Have a nice weekend, best regards

P.S. The main advantage we hope to gain from ClearScript is its 64-bit capability, which we will need for migrating our application to .NET8 (or higher).

[ClearScriptLib]

Hi @DanielGerlach2,

After some experimentation, we believe we can make enum-integer interop work without DirectAccess. Notes:

1. The default method binding algorithm – based on C#'s type inference ruleset and the only way to bind to generic methods – cannot be made to accept integers for enum-typed parameters. This new feature will have to be used in conjunction with DisableDynamicBinding or UseReflectionBindFallback.

2. Passing or assigning a numeric value that cannot be implicitly converted to the target enum's underlying type could still fail. For example, passing the value 500 to an enum whose underlying type is byte will not work.

Please send your thoughts.

[DanielGerlach2]

Sorry for the delay, but I was on vacation 😁

Thank you very much, your answer sounds very promising. 👍

Regarding point 1:
We already have DisableDynamicBinding in use, as this was already recommended by you in response to request.
This therefore poses no problem.

Regarding point 2:
That's perfectly logical and doesn't pose a problem.
Our code is already in use and working.
Should any extensions or changes be necessary, they would have to be implemented and then tested, so passing or assigning invalid values ​​is practically impossible for our use cases.

[ClearScriptLib]

Excellent! Barring unexpected findings, we'll add the following in the next release:

1. The ability to marshal enums to script code as integers. This feature will be opt-in.
2. The ability to use integers as arguments for enum-typed host parameters and as values for enum-typed host properties and fields. This feature will be opt-in and limited to the reflection binder.

Unfortunately, we can't give you an ETA for the next release. Hopefully some time before the new year.