VS Debugger can't attach to dotnet defined in launchSettings.json

[ViktorHofer]

After we recently switched to the project-system in corefx we lost the ability to debug our test projects inside VS: https://github.com/dotnet/corefx/issues/30913. As a simple workaround till we integrate Test Explorer Integration successfully (and with that also updating xunit) I wanted to add launchSettings.json files to our test projects like @sharwell did for roslyn here https://github.com/dotnet/roslyn/commit/7d91bb391254f4aec786ed3d6cadf1b59741ba77.

Unfortunately that doesn't work for us. "Start without Debugging" works fine, it launches the xunit runner window but start debugging with attaching to the runner doesn't work and results in this error: A fatal error has occurred and debugging needs to be terminated. For more details, please see the Microsoft Help and Support web site. HRESULT=0x8000ffff. ErrorCode=0x0.

launchSettings.json:

{
  "profiles": {
    "xUnit.net Console": {
      "commandName": "Executable",
      "executablePath": "$(StartProgram)", C:\git\corefx3\bin\testhost\netcoreapp-Windows_NT-Debug-x64\dotnet.exe
      "commandLineArgs": "$(StartArguments)", xunit.console.netcore.exe System.Text.RegularExpressions.Tests.dll  -xml testResults.xml -notrait Benchmark=true -notrait category=nonnetcoreapptests -notrait category=nonwindowstests -wait -parallel none
      "workingDirectory": "$(StartWorkingDirectory)" C:\git\corefx3\bin\tests\System.Text.RegularExpressions.Tests\netcoreapp-Windows_NT-Debug-x64\
    }
  }
}

Repro:

git clone https://github.com/ViktorHofer/corefx.git
cd corefx
git checkout launchsettings
.\build.cmd
start src\System.Text.RegularExpressions\tests\System.Text.RegularExpressions.Tests.csproj

Any chance to find out what's going underneath? I can't find any logs that mentioned the failed debugger invocation...

cc @BillHiebert @eerhardt

[danmoseley]

@tmeschter do you have a rough idea when you will be able to take a look? This is quite impactful for us to not be able to launch from VS, and especially for the community. I started debugging msvsmon but didn't get far and I assume the problem is not in there.

[danmoseley]

I can see from procmon that msvsmon successfully launches the exe with the correct parameters. It fails after that. Perhaps it's picking the wrong debugger engine or bitness?

[davkean]

This will be caused by our sniffing of TargetFramework and your lack of usage of it to figure out the correct engine. As mentioned in the past, you are going to be swimming upstream because your projects are missing it - it might be easier in the short term to use TargetFramework/TargetFrameworkIdentifier. If the project contained a TargetFrameworkIdentifier of .NETCoreApp, then we'd pick the right engine.

Longer term, I think we need to have a better mechanism to drive the debugger engines; either by respecting the legacy project-system settings or via a new property that is defaulted in the build by target framework, which projects can change.

[davkean]

The code in particular is this: https://github.com/dotnet/project-system/blob/b3b6ea07cd088926ac7973e1f916ec5be9df55e6/src/Microsoft.VisualStudio.ProjectSystem.Managed.VS/ProjectSystem/VS/Debug/ProjectDebuggerProvider.cs#L73.

[ViktorHofer]

This will be caused by our sniffing of TargetFramework and your lack of usage of it to figure out the correct engine. As mentioned in the past, you are going to be swimming upstream because your projects are missing it - it might be easier in the short term to use TargetFramework/TargetFrameworkIdentifier. If the project contained a TargetFrameworkIdentifier of .NETCoreApp, then we'd pick the right engine.

This will be resolved when my PR goes in which sets the TargetFramework, TargetFrameworkIdentifier (either by the SDK or manually), TargetFrameworkVersion (either by the SDK or manually) and the BaseIntermediateOutputPath and the IntermediateOutputPath.

Longer term, I think we need to have a better mechanism to drive the debugger engines; either by respecting the legacy project-system settings or via a new property that is defaulted in the build by target framework, which projects can change.

Today I stumbled upon this codeline which we set in buildtools which could be realted. Need to investigate why this is being set. https://github.com/dotnet/buildtools/blob/master/src/Microsoft.DotNet.Build.Tasks/PackageFiles/tests.targets#L46

[danmoseley]

For what it's worth I opened #667207 against the debugger to attempt to have a more useful error dialog.

[tmeschter]

@ViktorHofer @danmosemsft It sounds like corefx can work around this by settings TargetFramework et al. Do you think the Project System needs a better solution for 15.9, or can I move this to 16.0?

[ViktorHofer]

The launchSettings.json file now works since we set TargetFramework correctly and the debugger attaches correctly. It's still unfortunate that we need to have a launchSettings.json file per project: (https://github.com/dotnet/corefx/pull/32260). I think we can close this issue now.

[paul1956]

Before closing this can someone document what we are supposed to do to fix this ourselves? "settings TargetFramework et al." is not something I know how to do.

[ViktorHofer]

A default [cs|vb|fs]proj file already contains the TargetFramework therefore I assume customers shouldn't be affected:

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>netcoreapp2.1</TargetFramework>
  </PropertyGroup>

</Project>

[paul1956]

Above is not in the VB Test Project or Microsoft.VisualBasic.vbproj for CoreFx.

<Project Sdk="Microsoft.NET.Sdk">
    <PropertyGroup>
        <ProjectGuid>{da95454e-5f0e-4f8a-871a-25d1ab62867a}</ProjectGuid>
        <Configurations>netstandard-Debug;netstandard-Release</Configurations>
        <OptionStrict>On</OptionStrict>
        <OptionInfer>Off</OptionInfer>
    </PropertyGroup>
    <PropertyGroup Condition="'$(Configuration)|$(Platform)'=='netstandard-Debug|AnyCPU'">
        <NoWarn />
        <WarningsAsErrors>41999,42016,42017,42018,42019,42020,42021,42022,42032,42036</WarningsAsErrors>
    </PropertyGroup>
    <PropertyGroup Condition="'$(Configuration)|$(Platform)'=='netstandard-Release|AnyCPU'">
        <NoWarn />
        <WarningsAsErrors>41999,42016,42017,42018,42019,42020,42021,42022,42032,42036</WarningsAsErrors>
    </PropertyGroup>
    <ItemGroup>
        <Compile Include="FileIOTests.vb" />
    </ItemGroup>
    <ItemGroup>
        <Reference Include="netstandard" />
        <Reference Include="System" />
        <Reference Include="System.Collections" />
        <Reference Include="System.Collections.Specialized" />
        <Reference Include="System.Diagnostics.Debug" />
        <Reference Include="System.Globalization" />
        <Reference Include="System.Dynamic.Runtime" />
        <Reference Include="System.Linq" />
        <Reference Include="System.Linq.Expressions" />
        <Reference Include="System.ObjectModel" />
        <Reference Include="System.Reflection" />
        <Reference Include="System.Reflection.Extensions" />
        <Reference Include="System.Reflection.Primitives" />
        <Reference Include="System.Reflection.TypeExtensions" />
        <Reference Include="System.Resources.ResourceManager" />
        <Reference Include="System.Runtime" />
        <Reference Include="System.Runtime.Extensions" />
        <Reference Include="System.Runtime.InteropServices" />
        <Reference Include="System.Threading" />
    </ItemGroup>
</Project>

[ViktorHofer]

In corefx we set the TFM during the Directory.Build.props evaluation. Not directly in the project file.

[paul1956]

@ViktorHofer I can't debug VB Test code with VS unless I run msbuild /t:rebuildandtest and attach VS Debugger to the dotnet.exe process. So something is wrong.

[ViktorHofer]

Yes that's a known bug in corefx unrelated to this issue.

[paul1956]

@ViktorHofer where is it being tracked, if not here?

[ViktorHofer]

in an offline thread.