Replace the inline drive-casing probe in Workarounds.targets with a maintainable, tested implementation
- Dominant language
- C#
- Stars
- 729
- Forks
- 397
- Avg merge
- 3d 15m
- Merged PRs (30d)
- 149
Description
Follow-up to #17039. That PR shipped a validated but intentionally minimal `MSB4216` workaround that should be hardened now that it''s in `main`.
The logic lives in `src/Microsoft.DotNet.Arcade.Sdk/tools/Workarounds.targets` (~338 lines). It is an inline `RoslynCodeTaskFactory` task (`NormalizeSdkRootDriveCasing`) that determines the SDK volume''s canonical drive-letter casing by generating a temporary MSBuild project — which itself contains a second inline task — and invoking the SDK''s `dotnet.exe` on it.
**Maintainability concerns**
- Inline C# in a `.targets` file isn''t compiled as part of the normal build, has no unit tests, and is hard to review and debug.
- The probe spawns a child `dotnet.exe` process (building a generated throwaway project) on first use per drive.
**Goals**
- Move the C# into a compiled task in the Arcade SDK tasks assembly so it is reviewable, debuggable, and unit-tested.
- Replace the generated-project + child-process probe with an in-process Win32 call that yields the same casing `Environment.ProcessPath` / `GetModuleFileNameW` reports (e.g. investigate `GetVolumePathNamesForVolumeNameW`), removing the per-build process launch.
- Preserve behavior exactly: Windows + `Full` runtime only, casing-only mutation, cached per drive, safe no-op, and the `DisableNetCoreSdkRootDriveCasingWorkaround` / `NetCoreSdkRootDriveCasingOverride` knobs.
- Add tests covering `D:` -> `d:` normalization, the override paths, and the no-op cases.
Contributor guide
Assessment
This issue has not been assessed yet.