Fix flaky tests

[ThomasGoulet73]

Fixes #10250

Description

This fixes the flaky tests which was caused by the native dependencies sometime not being built before the test projects. This PR adds an explicit reference to the projects of the native dependencies to make sure that it's built in the right order and also adds some protection by including the files explictly instead of using file globbing to make the build fail with an error which contain the path of the file missing instead of the tests failing to start, which improves the build logs in case of error.

Customer Impact

None, tests only.

Regression

No.

Testing

Did a bunch of local builds and it fails on 1 out of 5 build before this PR and I did ~10 local builds with this PR and it didn't failed. I also validated the build order in the build log.

Risk

Low to none, tests only.

/cc @JeremyKuhne since you worked in that area too lately.

Microsoft Reviewers: Open in CodeFlow

[ThomasGoulet73]

I've fixed the build errors so this PR is now ready for review.

I also had to fix the property _PackagingNativePath because it didn't have the right value when targeting ARM64.

[dipeshmsft]

LGTM.

Just to reiterate, the purpose of the project reference is just to make sure the native dependencies are already built and that is what was causing the flakiness in tests.

For the rest of the changes they are fixing the issue that we did not have the right path of native dependencies for ARM64

[ThomasGoulet73]

@dipeshmsft Yes, and also the changes in IncludeNativeDependencies is to prevent flakiness in the future by making the build fail if the native dependency was not found instead of failing at runtime.

This fixes the ARM64 test build (ARM64 tests are not ran in CI currently so that's why the tests weren't failing):
https://github.com/dotnet/wpf/pull/10304/files#diff-29b181700610c640b4a8cd2b9cd25af0e791ed8b90ec215f8343cab55d0de8a8L5-R5

This prevents flakiness in the future:
https://github.com/dotnet/wpf/pull/10304/files#diff-29b181700610c640b4a8cd2b9cd25af0e791ed8b90ec215f8343cab55d0de8a8L18-R28

This fixes the current flakiness:
https://github.com/dotnet/wpf/pull/10304/files#diff-29b181700610c640b4a8cd2b9cd25af0e791ed8b90ec215f8343cab55d0de8a8R34-R54

[dipeshmsft]

Thanks @ThomasGoulet73, got it.

[dipeshmsft]

@ThomasGoulet73 , I was writing some tests for PresentationFramework.Fluent, but when I do window.Show(), the tests fail with the exception Unable to load wpfgfx_cor3.dll or some of it's dependencies even after taking this fix. Any ideas on what can be going wrong ?

[ThomasGoulet73]

@dipeshmsft I was able to reproduce the issue, I'm looking into it.

[dipeshmsft]

Thank you @ThomasGoulet73 for taking a look at this

[ThomasGoulet73]

@dipeshmsft: I found the issue, there seems to be a problem when loading a native dll from a local path which depends on another dll in a project that uses "DllImportSearchPath.AssemblyDirectory | DllImportSearchPath.System32" as the default search path. AFAIK it should work but for some reason it doesn't. This default search path is added to all WPF projects here:

wpf/eng/WpfArcadeSdk/tools/ExtendedAssemblyInfo.props

Lines 16 to 20 in 81019fc

	<ExtendedAssemblyInfo Include="DefaultDllImportSearchPaths"
	Condition="'$(IncludeDllSafeSearchPathAttribute)'=='true'">
	<Parameter1>DllImportSearchPath.AssemblyDirectory | DllImportSearchPath.System32</Parameter1>
	<IsLiteral1>true</IsLiteral1>
	</ExtendedAssemblyInfo>

The reason it doesn't fail in production is because the .Net host has custom search paths that includes the WindowsDesktop pack which contains the dlls.

It's not specific to WPF, I was able to repro in a barebones project and I'll open an issue in dotnet/runtime to see if it's the expected behavior or not (Or maybe I misunderstand the bug).

In the meantime, I'll open a PR to workaround this issue in test projects.