How does ScriptEngin.AccessContext work?

[nextfool]

Hi @ClearScriptLib ,
So from my naïve understanding, ScriptEngin.AccessContext can work as a "host api set" tool, by that I mean following:

public class ApiSet1
{
public void Feature1(){}
public void Feature2(){}
}
public class ApiSet2
{
public void Feature1(){}
public void Feature2(){}
}

engineWithApiSet1.AccessContext = typeof(ApiSet1);
engineWithApiSet2.AccessContext = typeof(ApiSet2);

But I was confused by the test methods in "AccessContextTest"

So here are my questions:
Given the fact that "AccessContextTestBase" is already "exposed" to engines global context by following,

How could code like " engine.Evaluate("new AccessContextTestBase()")" would fail? I mean, the default engine.AccessContext is the default "global" context isn't?

The next questions is that:

Neither of these two types defined a member "AccessContextTestBase" , then how suddenly after engine.AccessContext = GetType(), those the same code can succeed?

Please help me to understand the magic here :)
Thank you for your time.

[nextfool]

Another question would be, how does "engine.AccessContext = typeof(SomeContext)" affect the default global context, are those types/objects added by "AddHostType/AddHostObject" still accessible/importable in script after the new context is assigned?

[ClearScriptLib]

Hi @nextfool,

How could code like " engine.Evaluate("new AccessContextTestBase()")" would fail?

For script code to use a host resource, that resource must be both exposed and accessible. As you've noted, TestInitialize exposes AccessContextTestBase. However, initially, that class isn't accessible, because it's internal to the ClearScript.Core assembly¹.

I mean, the default engine.AccessContext is the default "global" context isn't?

By default, AccessContext is null, which means that a host resource is accessible only if it has public visibility.

Neither of these two types defined a member "AccessContextTestBase" , then how suddenly after engine.AccessContext = GetType(), those the same code can succeed?

Within that test method, GetType returns typeof(AccessContextTest), so that statement effectively makes subsequent script code behave – in terms of resource accessibility – as if it were managed code within the AccessContextTest class.

In other words, that statement empowers script code to use the same resources as managed code within AccessContextTest – as long as those resources are exposed.

After that statement, AccessContextTestBase is not only exposed but also accessible, because script code now effectively resides within the ClearScriptTest assembly, and ClearScript.Core makes its internals visible to ClearScriptTest (see here).

Another question would be, how does "engine.AccessContext = typeof(SomeContext)" affect the default global context, are those types/objects added by "AddHostType/AddHostObject" still accessible/importable in script after the new context is assigned?

Again, AccessContext affects accessibility, whereas AddHost* affects exposure. Those concepts are independent.

Please send any additional questions our way.

Thank you!

¹ Yes, putting a test class into the core assembly is ugly, but it's the only way we could test certain things without creating yet another project.

[nextfool]

Yes, putting a test class into the core assembly is ugly, but it's the only way we could test certain things without creating yet another project.

aha, it's actually such a brilliant solution, I couldn't imagine something else better. To be honest, I was never aware of the usage of "InternalsVisibleTo" attribute. So thank you very much for the clarification.