Could not load file or assembly 'Microsoft.Build.Utilities.Core, Version=15.1.0.0

[Evangelink]

Thanks, while I have you, I'm trying to run a test project by running directly the EXE generated but I'm facing this error:

Assembly Initialization method Evs.Phoenix.Starasset.Api.Remote.ComponentTest.TestSettings.AssemblyInitializeAsync threw exception. System.Reflection.ReflectionTypeLoadException: Unable to load one or more of the requested types. [10:02:32 ](https://teamcity.evs.tv/buildConfiguration/Phoenix_EvsPhoenixStarasset_EvsPhoenixStarassetBuildOnCommitSharedResources/13896258?buildTab=log&focusLine=1604&linesState=1604&logView=flowAware) Could not load file or assembly 'Microsoft.Build.Utilities.Core, Version=15.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. The system cannot find the file specified.
@Evangelink

Originally posted by @TheFireCookie in #2577 (comment)

[Evangelink]

Microsoft.Build.Utilities.Core is a dependency of Microsoft.Testing.Platform.MSBuild but we are relying on version 17.7.2 so I am not sure why you are having this issue. cc @MarcoRossignoli

Would it be possible to have some repro?

[MarcoRossignoli]

Microsoft.Build.Utilities.Core is a dependency of Microsoft.Testing.Platform.MSBuild

It's should not end in the build of the user because it's non consumed as asset for the build.

[TheFireCookie]

I'll try to drop an isolated sample but it might be hard to get it

[Evangelink]

Would it be possible for you to send us privately some binlog (you can follow the steps here https://learn.microsoft.com/cpp/overview/how-to-report-a-problem-with-the-visual-cpp-toolset?view=msvc-170#to-create-a-problem-report-for-private-information)?

[TheFireCookie]

I'll try to do that. Meanwhile is there a way to generate a TRX or something similar that my CI could ingest to report the tests?

[Evangelink]

Sure thing, please have a look at the trx extension https://learn.microsoft.com/dotnet/core/testing/unit-testing-platform-extensions#visual-studio-test-reports

[nohwnd]

There is repro of this, or a similar problem in the internal repo in Verify_Correct_Registration_Order_For_WellKnown_Extensions test, the comment there mentions the same problem when running the test with something else than netstandard2.0. I also saw it when I was doing some changes.

(there are probably many ways to investigate, but dependency walker for .NET maybe would help here: isindicic/DependencyWalker.Net#7 )

[TheFireCookie]

So we have a lib and in that lib there is some reflection and this is the method that make it break;
var commandCandidates = AppDomain.CurrentDomain.GetAssemblies().SelectMany(a => a.GetTypes()).ToList();
if I remove this line, everything is fine.
But I don't know if the problem is with the reflection itself or if it's the types that comes of the assemblies.