Add Microsoft.IO.Redist for directory enumeration.

[AR-May]

Fixes #6075

Context

Microsoft.IO.Redist brings some of the new .NET Core System.IO functionality to .NET Framework. In particular, enumeration in Microsoft.IO was optimized comparing to System.IO: new enumeration API was added and old one was improved. We consider it is beneficial to switch default file system enumeration to the old API from Microsoft.IO.Redist.

Changes Made

• Added Microsoft.IO.Redist
• Default file system enumeration uses Microsoft.IO instead of System.IO

Testing

Unit tests & DDRITs

Notes

We should be wary of possible regressions. There were differences in behavior, see .NET Framework only notes in doc. The change therefore is under change wave 17_0.

[AR-May]

I measured CPU and memory of the enumeration requests from FileMatcher.cs functions for 3 cases.

• Enumeration uses old API from .NET Framework System.IO.
• Enumeration uses old API from Microsoft.IO
• New enumeration, using the new API from Microsoft.IO

Measurements are done for the rebuild of OrchardCore repo, it is average of 3 attempts.

Description	CPU (msec)	Memory (bytes)
System.IO old API	9996	63933
Microsoft.IO old API	4656	44133
Microsoft.IO new API	3927	52133

Considering that the difference is not that big and implementation with old API is much easier (no need to change in our public interfaces or work around it) we decided to use old API from Microsoft.IO.

[Forgind]

I marked the couple things I think are most likely to be the problem. I also see extra binding redirects for some other assemblies in the VS repo that aren't there for M.IO.Redist, so that's a possibility. I haven't found anything that pinpoints the problem, unfortunately, so I can't say that any of them are actually the problem.

[AR-May]

So far, it seems that I was able to resolve problems with the VS experimental insertion.
The absence of the binding redirect was indeed the root cause of the failures that I saw (but not for Microsoft.IO.Redist, for one of the dependency assemblies).
The actual exception "Could not load file or assembly 'System.Buffers, Version=4.0.2.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' or one of its dependencies. The system cannot find the file specified." was covered with a nonsense error "System.ArgumentException: Illegal characters in path." and mislead me.

The other errors that I saw should be flukes or not related, as far as I could see. I will run the final version through the experimental insertion one more time to confirm resolution of the errors.

[Forgind]

I know you said there are still errors, but the code itself LGTM 👍

[ladipro]

I have left a few comments inline, thank you!

[ladipro]

Isn't the FusionLog property available only if fusion logging is actually enabled?

I don't see FileNotFoundException listed as an exception thrown by Directory.Enumerate* so it looks like it should work without the when.

[AR-May]

It works when fusion logging is disabled. The FusionLog in this case consists of a warning "WRN: Assembly binding logging is turned OFF. To enable assembly bind failure logging, set the registry value [HKLM\Software\Microsoft\Fusion!EnableLog] (DWORD) to 1."

If Directory.Enumerate indeed does not throw FileNotFoundException, then additional check in when should not have any performance implications, cause it is used in rare case when we indeed have a failure. And I felt like it is safer to have it than not not have.

But I suppose you are right and we can remove this when from this line.

[ladipro]

[rainersigwald]

Looks awesome! Thanks for all the work it took to get to this point.