TestingPlatformBuilderHook -> GetEntryAssembly() issue

[nbalu]

Describe the bug

I've made my orchestration tool that's capable to load and execute the test assemblies. Though dynamic loading fails as the entry assembly is not referencing itself rather the entry assembly.

Steps To Reproduce

Create an executable project with TestPlatformBuilder.
Create a project that references MSTest.
Use the generated functionality to lookup and register the test.

0 tests will be loaded and executed as it references the entry assembly instead of itself.

(

testfx/src/Adapter/MSTest.TestAdapter/TestingPlatformAdapter/TestingPlatformBuilderHook.cs

Line 14 in 981c70f

public static void AddExtensions(ITestApplicationBuilder testApplicationBuilder, string[] arguments) => testApplicationBuilder.AddMSTest(() => [Assembly.GetEntryAssembly()!]);

)

Expected behavior

Tests should be loaded via the extension method.

Actual behavior

0 tests are discovered and added / loaded at all

Additional context

My problem is that the entry might not be the same assembly that holds the tests unfortunately.

[nohwnd]

Same problem can be observed in nativeaot mode, where the assembly property is null and we have to redefine the entrypoint to get reference to the current assembly as typeof(OurRootType).Assembly.

My desired solution was to change the AddExtensions method to pass in the this reference of the caller , or assembly - which is the type we emit into the executable assembly.

e.g.

AddExtensions(ITestApplicationBuilder testApplicationBuilder, Assembly testedAssembly, string[] arguments)

But I was not sure how useful it would be. So this is one more case where getting the type / assembly directly would be useful.

I ended up working around this problem to avoid changing the public api and breaking all extensions that integrate with it.

We could also work around this limitation of public api shape by adding a TestApplicationBuilderWithAssembly : ITestApplicationBuilder public type that would be a bag of info that we know we need right now. This will not limit our options for future if we need to transport more info. But it is a band-aid at best.

[Evangelink]

I am not sure whether this is something we want to fix. We introduced the generated entry point only to help with transitioning from VSTest world but I think the right future and path forward is to have explicit Program.cs. It's like that for most web apps and no-one ever complained. It's also making it easier for everyone to understand what is run, how, what is the start and end... For example [AssemblyInit] and [AssemblyCleanup] are features that would not need to be introduced if we had explicit main from the start as we could simply wrap calls in try/finally.

[nohwnd]

Wrong label, as said above this is not something that we immediately want to fix. The assumption in mstest hook is wrong for native aot, but we don't have a plan to enable arbitrary dlls to be provided to the hook via the extensions registration helper.