[MSTest][Discovery] Unable to load types from the test source ... Could not load file or assembly about testfx

[eleshoe]

@Evangelink
Thanks for the clarification, it is clear now.
Thank you very much.

[eleshoe]

The above github repo url is not working, please use this
DemoUnitTestProject

[eleshoe]

I also tried to use absolute path to the dependencies in the .runsettings file, but still the same issue as above.

[Evangelink]

Hi @eleshoe,

Thanks for the detailed issue!

Looking at your project configuration, I think I have found the issue and it seems to be more of a general configuration issue that something specifically related to MSTest. On your tests, you are changing the output path property to ..\unittest and you have the project references DemoProject.csproj and DemoTestBase.csproj setup with <Private>false</Private> which means that you are preventing any local copy of these dlls.

After the compilation, if you open the unittest folder you will see that it contains DemoUnitTestProject.dll but not DemoProject.dll nor DemoTestBase.dll and so when you are executing the tests you end up with the file not found issue.

If you either allow local copy (remove the <Private> parts) or also copy the dll in your output, you will see that the issue is gone and the tests are run properly.

Regarding why the test from the class inheriting TestBase are not found. This is the same issue, because the base class is not found there is a runtime error thrown and so we are unable to discover the test correctly.

I will move forward by closing this issue but feel free to ask for more details if needed.

[eleshoe]

@Evangelink
Hi, thanks for the quick response.
I understand what you mean, but for net framework 4.7.2, it works, just the net6 not working. Why?

[Evangelink]

Oh sorry! I went too fast in doing my analysis. I will reopen and investigate the change (I would guess that something is wrong in non-netfx and the AssemblyResolution setting is being ignored.

[Evangelink]

I was able to investigate the difference. The AssemblyResolve settings is only impacting .NET Framework as some of the custom resolver tools are not available in "core" version of .NET. I think we could improve user experience by printing some warning if we find this property on non-netfx run. We should also update the documentation around this property to specify it's not used in non netfx versions.

[eleshoe]

I was able to investigate the difference. The AssemblyResolve settings is only impacting .NET Framework as some of the custom resolver tools are not available in "core" version of .NET. I think we could improve user experience by printing some warning if we find this property on non-netfx run. We should also update the documentation around this property to specify it's not used in non netfx versions.

@Evangelink
AssemblyResolve you mean AssemblyResolution?

If I understand correctly, you mean the AssembyResolution is currently not working in .Net 6 (or other "core") and only work in .Net framework; and the solution here is to provide some warnings and update of documentations?

1. Does that means there will not be any fixing for .Net 6 (or other "core") to be able to use the AssembyResolution?
2. If there is no fix to use AssembyResolution for .Net 6, what's the alternatives/workaround?

[Evangelink]

Hi @eleshoe,

My bad, reading again my sentence, I see it's not super clear.

Let me start again. As you pointed out, you are using the AssemblyResolution configuration in the runsettings file. This property allows users to give different locations in which MSTest should try to be loading dlls from. This is used internally in a custom assembly resolver along with AppDomains.

In netcore/net versions of .NET, some functionnalities of the AppDomain are no longer available which is preventing some of the behaviours of MSTest.

To answer more specifically your questions. No, there will not be any "fix" for supporting the AssemblyResolution property in netcore/net versions of MSTest. But we will update the documentation to specify this is not supported AND we will emit a warning if we detect this property in some netcore run.

As for workarounds, I would suggest "fixing" the project setup so that the dlls are found in the location of the test dll. As explained in some previous comment, you could remove the <Private>, you could add a task to copy the dlls in the custom location or edit the "production" projects to emit in the custom location:

Looking at your project configuration, I think I have found the issue and it seems to be more of a general configuration issue that something specifically related to MSTest. On your tests, you are changing the output path property to ..\unittest and you have the project references DemoProject.csproj and DemoTestBase.csproj setup with <Private>false</Private> which means that you are preventing any local copy of these dlls.

After the compilation, if you open the unittest folder you will see that it contains DemoUnitTestProject.dll but not DemoProject.dll nor DemoTestBase.dll and so when you are executing the tests you end up with the file not found issue.

If you either allow local copy (remove the <Private> parts) or also copy the dll in your output, you will see that the issue is gone and the tests are run properly.

Regarding why the test from the class inheriting TestBase are not found. This is the same issue, because the base class is not found there is a runtime error thrown and so we are unable to discover the test correctly.

[Evangelink]

Warning was not added, reopening

[fx999dev]

To answer more specifically your questions. No, there will not be any "fix" for supporting the AssemblyResolution property in netcore/net versions of MSTest. But we will update the documentation to specify this is not supported AND we will emit a warning if we detect this property in some netcore run.

@Evangelink
We have about 1500 dlls of which 30-50 dlls need to be loaded at runtime depending on the project. via the .runsettings file gave us the possibility to specify a path where all possible runtime components can be found.
Surely we can't specify "Copy Local" on each of our projects, after which around 3 gigabytes of dlls are copied to the binary folder on each build, which would not only be a huge waste of memory, but also a massive performance loss when building the projects.

We are currently still using .NET Framework, but how should we solve the problem when we move to .NET 6.0 in the future?