Note

This is not for 2.1.26 because it will just slow progress down there. Not particularly relevant anyhow since ProdCon builds should have IsFinalBuild set to true.

/fyi @vseanreesermsft

/azp run

/azp run

@JunTaoLuo any ideas about our 2.1 test hangs❔ I've lost track of how many times I've retried builds in this PR…

/azp run

@dotnet/aspnet-build, my second commit in this PR resolves the 2.1 test hangs. I'm not sure of the root cause but guess either

1. The --TestAdapterPath argument value (see
   https://github.com/aspnet/BuildTools/blob/e2b019a5c8d338b060644e2ea5437beea1f5a888/files/KoreBuild/modules/vstest/module.targets#L110-L112
   ) is always from the last project in a test group because that's how property group batching works. In the few cases I changed, that project (Microsoft.AspNetCore.AzureAppServicesIntegration.Tests.csproj -- chosen consistently) does not provide all assemblies needed for everything else in the UnitTests (default) test group. The problems with this cause are none of the four projects has changed in ages and --TestAdapterPath isn't documented to affect dependencies. But, maybe some change somewhere changed the --TestAdapterPath value i.e. the order of the @(TestAssemblies) item group.
2. Some change somewhere caused timing changes within the UnitTests/net461 test group, leading to conflicts between the large number of test assemblies in that group. The problem with this cause is consistent MissingMethodExceptions seems like a strange symptom of "conflicts".

Given the fact

dotnet vstest --Parallel --Framework:.NETFramework,Version=v4.6.1 --TestAdapterPath:src\Azure\AzureAppServicesIntegration\test\bin\Release\net461\ `
src\Servers\bin\Microsoft.AspNetCore.Server.Kestrel.Transport.Libuv.Tests\Release\net461\Microsoft.AspNetCore.Server.Kestrel.Transport.Libuv.Tests.dll

fails (miserably) and

dotnet vstest --Parallel --Framework:.NETFramework,Version=v4.6.1 --TestAdapterPath:src\Servers\bin\Microsoft.AspNetCore.Server.Kestrel.Transport.Libuv.Tests\Release\net461\ `
src\Servers\bin\Microsoft.AspNetCore.Server.Kestrel.Transport.Libuv.Tests\Release\net461\Microsoft.AspNetCore.Server.Kestrel.Transport.Libuv.Tests.dll

succeeds, I lean toward (1) but I am still building an old 2.1 commit to see the previous behaviour.

Nice!! I'm not familiar with what TestGroupName does - based on your comment, is it splitting those tests into groups that are more guaranteed to resolve a sufficient TestAdapterPath?

is it splitting those tests into groups that are more guaranteed to resolve a sufficient TestAdapterPath?

Yes, that's what it does but I'm still not positive why changing the TestAdapaterPath works as it does. Could add a wait-for-debugger loop in one of the problematic test class constructors and debug the short dotnet vstest command that fails but I'm not sure the extra effort is worthwhile. Thoughts❔

Could add a wait-for-debugger loop in one of the problematic test class constructors and debug the short dotnet vstest command that fails but I'm not sure the extra effort is worthwhile. Thoughts❔

If this works, I don't think you need to make that a priority given that this is 2.1. If the hang resurfaces then maybe we can do the deeper dive.

/fyi the old command also looked like

dotnet vstest --Parallel --Framework:.NETFramework,Version=v4.6.1 --TestAdapterPath:...\src\Azure\AzureAppServicesIntegration\test\bin\Debug\net461\ {test assemblies}...

on my system. New guess is a project that depends on reduced what is copy-localed into that path i.e. it's not a change to the @(TestAssemblies) item group. Either way, this works and I've got other stuff to do😺

@dotnet/aspnet-build this should probably go in first after we complete the branding updates because it isn't combined with as many other fixes (all three of my 2.1 changes include the test fix)