search

CZEMacLeod / MSBuild.SDK.SystemWeb

This MSBuild SDK is designed to allow for the easy creation and use of SDK (shortform) projects targeting ASP.NET 4.x using System.Web.
MIT License
161 stars 10 forks source link

VsCode's new C# DevKit fails to launch #71

Open brad-jones opened 1 year ago

brad-jones commented 1 year ago

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.

image

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 commented 1 year ago

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.

image

brad-jones commented 1 year ago

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:

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 commented 1 year ago

@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 commented 1 year ago

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 commented 1 year ago

@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 commented 1 year ago

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 commented 8 months ago

@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):

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