[Feature Request / Bug Report] Provide unsigned Microsoft.DotNet.XUnitExtensions (and similar) packages for .NET Framework to mitigate 0x80131045 FileLoadException

Hello dotnet/arcade team,

I hope this message finds you well.

I've encountered a very persistent and challenging issue when trying to run XUnit tests on projects targeting **.NET Framework 4.7.2** (and potentially other .NET Framework 4.x versions) in Visual Studio 2022. The error manifests as a ```System.IO.FileLoadException``` with HRESULT ```0x80131045``` ("Strong name signature verification failed") during the test discovery phase, specifically for the assembly ```Microsoft.DotNet.XUnitExtensions, Version=8.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35```.

This problem makes testing for .NET Framework 4.7.2 extremely complex and unreliable. I believe providing unsigned versions of these problematic assemblies could greatly benefit developers in similar situations.

**Problem Details:**
- **Assembly Involved:** ```Microsoft.DotNet.XUnitExtensions, Version=8.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35``` (and its dependencies, though the error consistently points to this specific assembly).
- **Context:** Running XUnit tests (with ```xUnit.net VSTest Adapter v2.8.2```) in Visual Studio 2022, which uses ```testhost.net472.exe```. The error also occurs when using ```xunit.runner.console``` directly.
- **Core Error Message:**
```System.IO.FileLoadException: Could not load file or assembly 'Microsoft.DotNet.XUnitExtensions, Version=8.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. Strong name signature verification failed. The assembly may have been tampered with, or it was delayed signed but not fully signed with the correct private key. (Exception from HRESULT: 0x80131045)```
The stack trace indicates the error happens during test discovery, specifically when XUnit attempts reflection on methods (```System.Reflection.CustomAttributeData.GetCustomAttributes```).

**Troubleshooting Steps Performed (and their outcomes):**
We invested significant time diagnosing and attempting to resolve this, exploring all standard and extreme workarounds:
1. **Bypassing Strong Name Verification (**```sn -Vr```**):**
- Attempted both machine-wide (```sn -Vr *,*```) and assembly-specific (```sn -Vr Microsoft.DotNet.XUnitExtensions.dll```).
- **Result:** The error persisted. It appears the test runner's execution context in .NET Framework 4.x either ignores or overrides this directive due to security/isolation policies.
2. **Binding Redirects:**
- Added ```assemblyBinding``` for ```Microsoft.DotNet.XUnitExtensions``` and ```System.Memory``` (which caused a secondary issue) to the project's ```App.config```.
- Also attempted to add ```bindingRedirects``` directly to the ```testhost.net472.exe.config``` file within the Visual Studio extensions directory.
- **Result:** Did not resolve the ```0x80131045``` error for ```Microsoft.DotNet.XUnitExtensions```.
3. **Fuslogvw (Assembly Binding Log Viewer):**
- Used extensively to diagnose load failures.
- **Result:** Consistently showed failure for ```Microsoft.DotNet.XUnitExtensions``` with ```PublicKeyToken=31bf3856ad364e35``` and HRESULT ```0x80131045```, even after attempts to modify the DLL in the project's ```bin``` directory. This strongly indicated a deeper CLR interaction issue.
4. **Manual Strong Name Removal (using**```ildasm```**/**```ilasm```**):**
- The Microsoft.DotNet.XUnitExtensions.dll assembly was decompiled to IL, its .publickey and .hash algorithm directives were removed, and the assembly was reassembled without a strong name.
- **Verification:** ```sn.exe -Tp Microsoft.DotNet.XUnitExtensions.dll``` confirmed the assembly was no longer strong-named.
- **Result (initial):** The error persisted. This was particularly baffling, as an unsigned DLL should not trigger a strong name verification error.
5. **Crucial Discovery with Process Explorer and Final Resolution:**
- By monitoring the ```testhost.net472.exe``` process with Process Explorer, we discovered that, contrary to expectations, DLLs were **not being loaded from the project's** ```bin\Debug\net472``` **directory, but from a temporary directory (**```%USERPROFILE%\AppData\Local\Temp\xxxxxx\```**) used for shadow copying**. This revealed that the actual source of the loaded DLLs was the NuGet package cache.
- **Successful Workaround:** We then repeated the strong name removal procedure (```ildasm```/```ilasm```) directly on the copy of ```Microsoft.DotNet.XUnitExtensions.dll``` located in the **global NuGet package cache (**```%USERPROFILE%\.nuget\packages\microsoft.dotnet.xunitextensions\...\lib\net472\```**).** This was followed by a deep cleanup of ```bin```/```obj``` folders, NuGet caches, and a full system reboot.
- **Result:** The tests now run correctly.

**Suspected Root Cause:**
It appears the interaction between the strong name of ```Microsoft.DotNet.XUnitExtensions``` (which might be a delayed-signed assembly that's not fully signed, or has signing peculiarities), the way the .NET Framework 4.x CLR handles strong name verification in test contexts (seemingly ignoring ```sn -Vr```), and the shadow copying mechanism (which copies strong-named versions from the NuGet cache), creates a problem that is incredibly difficult to work around without invasive manual file modifications.

**Request / Proposal:**
Given the significant complexity and the fragile nature of the workaround required (manual modification of DLLs in the NuGet cache is not sustainable for CI/CD or large-scale development), I kindly request that the ```dotnet/arcade``` team consider providing alternative NuGet packages for .NET Framework (net4x) that contain unsigned versions of assemblies like ```Microsoft.DotNet.XUnitExtensions```.

This would allow developers facing these strong name verification issues to opt for an assembly version that does not trigger these conflicts with the .NET Framework CLR, greatly simplifying the testing and development process for those still relying on .NET Framework.

Thank you very much for your time and consideration of this issue.

Best regards,

Francesco Crimi