Debugging on Windows fails with "Could not load host policy library"

[DustinCampbell]

Repro Steps:

• Windows 10
• Install VS Code
• Install latest .NET Core SDK from https://dotnetcli.blob.core.windows.net/dotnet/beta/Installers/Latest/dotnet-win-x64.latest.exe
• Install latest C# extension from https://github.com/OmniSharp/omnisharp-vscode/releases/download/v0.3.9/csharp-0.3.9.vsix

At the command line:

• dotnet new to create new project
• code . to open newly-created project in VS Code

In VS Code:

• Click "Yes" on prompt to add required build and debug assets.
• Open project.json and add "debugType": "portable" to "compilationOptions" section
• Open Program.cs and click the margin at line 9 to add a breakpoint on Console.WriteLine("Hello World!");

Expected Result:
Project compiles, runs, and breakpoint is hit.

Actual Result:
Project compiles but breakpoint is not hit. Instead, the following text appears in the Debug Console:

Could not load host policy library [c:\Projects]
The program 'c:\Projects\helloworld/bin/Debug/netstandard1.5/helloworld.dll' has exited with code 131 (0x00000083).

[miguellira]

@DustinCampbell Though you were thorough with your reproduction steps you stopped short from detailing how to configure launch.json to actually debug. Are you saying that as soon as you add the breakpoint a build gets kicked off?

Also, what's your dotnet --info output look like? I ran into this and other issues with netstandard1.5 and my fix was just to move to netcoreapp1.0

[DustinCampbell]

I actually didn't stop short. This step automatically generates a launch.json:

Click "Yes" on prompt to add required build and debug assets.

Note that these same steps work perfectly on OS X. They fail on Windows.

[DustinCampbell]

And note that dotnet --info shows the following on my machine. It's literally the latest bits:

.NET Command Line Tools (1.0.0-beta-002215)

Product Information:
 Version:     1.0.0-beta-002215
 Commit Sha:  f757468dde

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.14295
 OS Platform: Windows
 RID:         win10-x64

[miguellira]

Interesting... I didn't get a prompt to add required build and debug assets on Win10 or OS X. I usually CTRL-F5 or fn+F5 and that asks me to add the launch.json.

[miguellira]

@DustinCampbell Again, I might be missing something because I've only managed to get VS Code debugging by manually configuring the launch.json file based on this write up: https://blogs.msdn.microsoft.com/visualstudioalm/2016/03/10/experimental-net-core-debugging-in-vs-code/

FWIW... I am able to debug the a dotnet new console app with version 1.0.0-beta-002202 of the CLI on Windows 10:

[DustinCampbell]

You won't get that prompt unless you install the latest C# extension per my instructions. You need to follow the installation steps I provided. You also likely need to uninstall old versions of the .NET Core SDK and CLI and possibly delete old versions of the C# extension for VS Code.

If you have to configure something to make this work, it's not right. Using the latest bits, this should work with no configuration.

[miguellira]

My apologies. OS X is my primary machine for the dotnet CLI bits, I just try things out on Win 10 when I run into issues - still on 0.3.7 of the C# plugin.

I'll actually try to repro the issue now. 😳

[DustinCampbell]

😄

[DustinCampbell]

Be sure to change your "csharp.omnisharp" preference to not use your own custom OmniSharp if you have that set.

[miguellira]

Indeed I am also getting this error on Windows 10. 😞

Fortunately, all is well in OS X world 😄 Go figure.

[gregg-miskelly]

@DustinCampbell does the app run for if you just try doing it manually?

I noticed that your steps are missing a 'dotnet restore'. But I am not sure why the build succeeds, so maybe you did that and just didn't mention it?

[DustinCampbell]

@gregg-miskelly, "dotnet restore" happens automatically within OmniSharp if it's missing.

[DustinCampbell]

@gregg-miskelly: and yes, it runs and prints "Hello World" when running it with dotnet run at the command-line.

[DustinCampbell]

@miguellira, thanks for verifying!

[gregg-miskelly]

The issue is that dotnet.exe doesn’t like the fact that the slashes are going the 'wrong' way on Windows. You can work around it by modifying your launch.json to replace ‘/’ with ‘\’. I will change our code to do so automatically.

[DustinCampbell]

That's totally it @gregg-miskelly. 😄

[miguellira]

What's the workflow when you change the target fx - say from netstandard1.5 to netcoreapp1.0?

Right now the extension creates the launch.json with the current fx in project.json. Will the extension also update the path accordingly if a user changes fx?

[gregg-miskelly]

No, if you update it, you would need to manually change launch.json.

[gregg-miskelly]

(Obviously you could also delete launch.json and have VS Code re-create it)

[DustinCampbell]

I was thinking about ways we might address that some point, but it's tricky to get right.

[MattGertz]

For closure: the (bidirectional) fix for the slash issue was approved for Escrow.