Map local build path during WSL run

[JanKrivanek]

Problem

Fixes #654
Running under WSL crashes due to mixing windows and subsystem mapped files
Related discussion within #700

Proposed solution

Added prototype mapper function mapping the build time paths to mapped WSL paths.
Used the mapping 'as late as possible' - so with exception of Expecto (that needs source path to infer calling type) it's in the ResolveDirectory, plus in AttributeReader (as that's publicly exposed)

What is missing

Testing - unit testing is bit problematic with this type of feature

[SimonCropp]

is it possible to add a test for this scenario? either locally or on CI?

[JanKrivanek]

is it possible to add a test for this scenario? either locally or on CI?

Would it be acceptable to have manual testing for this?
I added testenvironments.json to be able to localy run unit tests on WSL:

(note some of the tests failing under WSL - this is most likely mostly due to mismatched matching of streams between environemnts. This is not related to the way how the WSL is supported).

There can likely be an additional CI job, which setups additional docker container and runs tests there - I unfortunately cannot commit to this work during this year.

[SimonCropp]

Would it be acceptable to have manual testing for this?
I added testenvironments.json to be able to localy run unit tests on WSL:

yep thats sufficient. can you add a section the readme on how to do that test. then i will merge and ship this

[JanKrivanek]

@SimonCropp I've reworked a bit - so one more look might be needed.
I wanted to make dockerized runs supported as well - so that it can be prepared for CI testing scenario in the future (I'm trying to see if this feature can be used from CLI and will comment back here or create item once I have some details).

I as well created separate item for fixing the tests failing for those scenarios.

[JanKrivanek]

dotnet/sdk#29516

[JanKrivanek]

@SimonCropp - This feels ready from mine point of view. Though I'm very open to any suggestions/ideas.

[SimonCropp]

this is problematic since based on people use of AttributeReader the virtualizedRunHelper can be mutated. shouldnt the static instance of virtualizedRunHelper only be initialized in TargetAssembly.Assign?

[JanKrivanek]

Correct - I originally intentionaly had it that way - as I was expecting all the callers to AttributeReader and Verify to be located in a code that is all going through single build in a single location. While the code can be in multiple assemblies, it still would have single root (solution) - so despite performing mapping via different projects/assemblies, result would be same.
Would the code be comming from different builds - then hopes for proper mapping of every single path are lost due to inability to locate and reach the other build code location from the virtualized mapped path.

...

At least that was my thinking.. but based on your comment I realized there is one specific scenario where separating mappers per assembly makes sense - and that's when the callers are in different assemblies, comming from different builds, but all those builds occured on the same developer machine and from same drive. The code roots might differ. All the code is still reachable from the VM/docker then and the mapping code should be able to reflect that.

A bit esoteric scenario (yeah - I'm the last one to speak about esoteric scenarios), but not nonexistent, plus code is cleaner this way. So thanks for detailed look!

tl;dr;: I have updated the code to separate mappers per assembly.

[SimonCropp]

this is now deployed