Subject identification not working on remote desktop

[0lks]

Description

I have not been able to get the subject identification component of FluentAssertions working on either of our two remote testing desktops and build configurations don't seem to be the cause of the issue for me.

I don't imagine my use case is that uncommon, so I'm hoping this is just a simple configuration issue, however I'm unable to find information about what to look for to troubleshoot this. The documentation mentions using the debug build configuration as the only requirement, but there seem to be more that go unmentioned?

Reproduction Steps

I can easily reproduce the issue in a fresh (SpecFlow) testing project.

After setting up a new testing project...

1. Build the following test in debug mode:

    string test = "true";
    test.Should().Be("false");

2. Run it with "dotnet test [YourTestAssemblyName].dll"
3. See 'Expected behavior'
4. Move all the build files to a remote desktop (including .pdb files)
5. Run the command from '2)' on the remote desktop
6. See 'Actual behavior'

Expected behavior

Expecting to receive the following error on both machines:
"Expected test to be "false" with a length of 5, but "true" has a length of 4, differs near "tru" (index 0)."

Actual behavior

The expected error only appears when running the test script on the local PC (same one where tests were built)

On the remote desktop I receive the error without subject identification:
"Expected string to be "false" with a length of 5, but "true" has a length of 4, differs near "tru" (index 0)."

Regression?

For me the subject identification has never worked on any PC other than the one I build on.

Known Workarounds

No response

Configuration

FluentAssertions v. 6.11
.NET 5 and .NET 6

Other information

No response

Are you willing to help with a pull-request?

No

[IT-VBFK]

What OS runs on the remote desktop?

Can you please verify following:

1. clone this repo
2. run ./build.sh (for unix) or .\build.ps1 (for windows) and check if all tests pass
3. If not, check if the test cases have the same issue you described

[0lks]

All the machines have Windows.

I ran the build on the remote desktop and all tests passed.

[IT-VBFK]

Ok.

I thought something related to #2368

[dennisdoomen]

4. Move all the build files to a remote desktop (including .pdb files)

Do you mean that you only move the binaries to the new machine? Or did you also copy over the binaries? Because by default, dotnet test will rebuild the test project.

[0lks]

I copy over all the binaries, yes. Everything from the bin folder is carried over. Then I run the dotnet test command on the remote machine exactly as I would run it locally. The command is given the dll containing my tests as the argument and because it's a dll it doesn't attempt to rebuild.

[dennisdoomen]

1. Try adding --configuration Debug to make sure it's not optimizing the DLL.
2. Copy the binaries from your dev machine to a different folder on your dev machine and try the same thing
3. Use a tool like DotPeek to verify that those binaries are really not optimized.