VsCode's new C# DevKit fails to launch

[brad-jones]

Re: https://github.com/dotnet/project-system/issues/2670#issuecomment-1765914052

Yes FWIW my project includes a Properties/launchSettings.json file & Visual Studio can launch the project just fine.

{
  "iisSettings": {
    "windowsAuthentication": false,
    "anonymousAuthentication": true,
    "iisExpress": {
      "applicationUrl": "http://localhost:51867/",
      "sslPort": 0
    }
  },
  "profiles": {
    "IIS Express": {
      "commandName": "IISExpress",
      "launchBrowser": true,
      "environmentVariables": {
        "ASPNETCORE_ENVIRONMENT": "Development"
      }
    }
  }
}

But the new C# Dev Kit fails with the following.

I'm thinking I might be able to get this working with a VsCode task to manually start IISExpress & then a custom launch config to attach to the process. But it would obviously be nicer if it just worked out of the box like it does in Visual Studio.

[brad-jones]

Ok so this wasn't too painful. Got it working. Here is my VsCode config.

.vscode/tasks.json

{
    "version": "2.0.0",
    "tasks": [
        {
            "label": "build",
            "type": "process",
            "command": "dotnet",
            "options": {
                "cwd": "${workspaceFolder}/project/Payroll.Timesheets.Web"
            },
            "args": [
                "build"
            ],
            "problemMatcher": [
                "$msCompile"
            ],
        },
    ]
}

.vscode/launch.json

{
    "configurations": [
        {
            "name": "IIS Express",
            "type": "clr",
            "request": "launch",
            "preLaunchTask": "build",
            "program": "C:\\Program Files\\IIS Express\\iisexpress.exe",
            "args": [
                "/path:${workspaceFolder}\\project\\Payroll.Timesheets.Web",
                "/port:51867"
            ],
            "env": {
                "ASPNETCORE_ENVIRONMENT": "Development"
            },
            "cwd": "${workspaceFolder}/project/Payroll.Timesheets.Web",
            "serverReadyAction": {
                "pattern": "Successfully registered URL.* \"(https?://\\S+|[0-9]+)\"",
                "uriFormat": "%s",
                "action": "openExternally"
            }
        }
    ]
}

As far as I can tell this is functionally equivalent to the Visual Studio launchSettings.json experience.

[brad-jones]

Another tip for anyone attempting to use VsCode for legacy .NET, here is how to debug your tests. The built in test runner that comes with C# Dev Kit will run your tests but it won't attach a debugger for some reason. This launch config works though.

A few other important points:

• Make sure DebugType is set to portable.
• Make sure you have a 64 bit version of vstest.console.exe
• Don't use /Parallel, /InIsolation or /Platform otherwise the debugger won't pickup break points.

At least that's the advice I got from https://github.com/microsoft/vstest/issues/1835 & it's all working fine for me.

{
    "name": "VsTest",
    "type": "clr",
    "request": "launch",
    "preLaunchTask": "build",
    "cwd": "${workspaceFolder}",
    "program": "C:\\Program Files\\Microsoft Visual Studio\\2022\\Professional\\Common7\\IDE\\Extensions\\TestPlatform\\vstest.console.exe",
    "args": [
        ".\\path\\to\\tests.dll"
    ]
}

[CZEMacLeod]

@brad-jones Do you fancy converting this to a how-to and adding it to the docs in this repo? It would be good to have this information captured. I'm actually slightly surprised that it is working as well as you say, as some of the SDK relies on MSBuild (over dotnet) and framework based DLLs included in VS e.g. https://github.com/CZEMacLeod/MSBuild.SDK.SystemWeb/blob/d176021fdd9fa97accf25105e44cff2c458f8221/src/MSBuild.SDK.SystemWeb/Sdk/Sdk.targets#L31 You might want to check out some of the comments https://github.com/CZEMacLeod/MSBuild.SDK.SystemWeb/issues/21#issuecomment-1478474537 and https://github.com/CZEMacLeod/MSBuild.SDK.SystemWeb/issues/20#issuecomment-910239293 regarding publishing and building.

[brad-jones]

Yeah I do have Visual Studio 2022 installed alongside so that's how those legacy dependencies are being resolved.

I'm pretty sure the Build Tools for Visual Studio package will also provide all the same required legacy dependencies without having to actually install all of Visual Studio.

As it happens I'm in the process of writing up an internal company HowTo for all this, happy to modify it for public consumption & contribute here.

[CZEMacLeod]

@brad-jones Always happy to take documentation PRs, as that is the one big area I am aware that is lacking in this project. I would be interested to know why you want to use VSCode/DevKit over VisualStudio though in this case. Especially as the resulting code is very much tied to Net Framework and Windows, and you need VS (or build tools) installed and a VS licence (even the free Community Edition) for the full DevKit experience anyway.

[brad-jones]

I guess it's just a personal preference thing, I spend my entire day in VsCode working on anything & everything from bash scripts to legacy .NET Framework code. Having to switch out to a different IDE for this one thing was enough of a pain for me to go down this path.

The other thing I am working towards is to attempt to get something like https://coder.com/ working with this legacy stack. The problem with where I work (xero.com) is that we have a mix of both legacy & modern stacks. The legacy ones, while every attempt is being made to re-write them, the reality is that they will be with us for years to come.

Getting ones local environment setup & configured for such a diverse technology landscape is such a pain so I want to put all that config into the cloud with IaC and then just dev in my browser, hell all I'd need is a Chromebook lol. I accept it's not a perfect experience but IMO it's good enough these days.

Especially for the odd time that you need to make a change to some crusty piece of code covered in dust & cobwebs. You just want to get in there, do the change quickly & get out before returning back to the nice modern world where it's sunshine & rainbows haha

[tskarman]

@brad-jones Do you fancy converting this to a how-to and adding it to the docs in this repo? It would be good to have this information captured. I'm actually slightly surprised that it is working as well as you say, as some of the SDK relies on MSBuild (over dotnet) and framework based DLLs included in VS e.g.

https://github.com/CZEMacLeod/MSBuild.SDK.SystemWeb/blob/d176021fdd9fa97accf25105e44cff2c458f8221/src/MSBuild.SDK.SystemWeb/Sdk/Sdk.targets#L31

You might want to check out some of the comments #21 (comment) and #20 (comment) regarding publishing and building.

I wasn't able to get that to work without adding an environment variable override for VSToolsPath.

tasks.json for my .NET Framework 4.8 setup (with .NET 8 as the dotnet version):

{
    "version": "2.0.0",
    "tasks": [
        {
            "label": "build",
            "type": "process",
            "command": "dotnet",
            "options": {
                "cwd": "${workspaceFolder}/some-systemweb-project",
                "env": {
                    "VSToolsPath": "C:\\Program Files\\Microsoft Visual Studio\\2022\\Professional\\Msbuild\\Microsoft\\VisualStudio\\v17.0"
                }
            },
            "args": [
                "msbuild"
            ],
            "problemMatcher": [
                "$msCompile"
            ],
        },
    ]
}

I also prefer the dotnet msbuild command here at the moment. The dotnet build doesn't appear to be caching earlier build results fully and always runs a lengthy restore, so I am doing that separately.

And that path would have to be adjusted for the current system. I.e. it could be anything from the following list for x64 (and more for other VS editions):

• C:\Program Files\Microsoft Visual Studio\2022\Professional\Msbuild\Microsoft\VisualStudio\v17.0
• C:\Program Files\Microsoft Visual Studio\2022\Community\Msbuild\Microsoft\VisualStudio\v17.0
• C:\Program Files\Microsoft Visual Studio\2022\BuildTools\Msbuild\Microsoft\VisualStudio\v17.0

@brad-jones fyi, since you replied to this later on.