Working folder when debugging a .NET Core app changing bizarrely

[Pilchie]

From @adamralph on June 1, 2018 22:33

Continuing from Twitter.

Note that the breakpoint is before the call to Directory.SetCurrentDirectory()!

Copied from original issue: dotnet/project-system#3609

[Pilchie]

From @adamralph on June 1, 2018 22:35

@davkean if you want to try it yourself, the repo is https://github.com/adamralph/liteguard

I'm using VS 15.7.1.

[Pilchie]

From @adamralph on June 1, 2018 22:40

Also, this is when I create a blank console project in a fresh instance of VS:

[Pilchie]

From @adamralph on June 1, 2018 22:43

And again, as soon as I add a call to Directory, it changes, before the call to Directory has happened_.

[Pilchie]

From @adamralph on June 1, 2018 22:44

@davkean I suspect that to produce the screenshot in your tweet, you called Directory.GetCurrentDirectory(), hence the reason you saw the project output folder.

[Pilchie]

From @steveharter on June 4, 2018 16:29

I can confirm this is an issue with 2.0.x. I also have a "random" location in a simple app: C:\\Program Files\\dotnet\\shared\\Microsoft.NETCore.App\\2.0.7\\System.Private.CoreL when there aren't any references to a System.IO type (or perhaps others; I didn't try) in the code block.

However with 2.1.0 I couldn't repro the issue because the immediate window won't run a Directory.GetCurrentDirectory() without an assembly reference: error CS0234: The type or namespace name 'Directory' does not exist in the namespace 'System.IO' (are you missing an assembly reference?)

I suggest moving this issue to coreclr repo since it appears to be related to type initialization.

[Pilchie]

Moved based on @steveharter's suggestion.

[jkotas]

This is caused by https://github.com/dotnet/corefx/issues/16229.

In .NET Core 2.0, the intermediate window is picking up the internal untested System.IO.Directory type in CoreLib. This has been cleaned up in .NET Core 2.1 and that's why you are not able to reproduce it.

There are still some duplicate types in .NET Core 2.1 for which this continues to be a problem.

[danmoseley]

This specific issue seems fixed, and hypothetical other issues tracked by dotnet/corefx#16229