Ensure that a virtual project doesn't pick up BaseOutputPath/BaseIntermediateOutputPath from Directory.Build.props

[RikkiGibson]

See microsoft/vscode-dotnettools#2443 (comment)

I think when a Directory.Build.props specifies BaseOutputPath, BaseIntermediateOutputPath, or ArtifactsPath, it should basically be ignored in virtual projects. The reason is that we strongly want to avoid putting the artifacts for those projects in the source tree with a file-based app.

Right now the test is failing, I need to come back and investigate in more details. I also think the <ArtifactsPath> in D.B.props case should be tested, I didn't see an existing test.

Opening PR now to try and share understanding of the issue and get buy-in on proposed solution.

[RikkiGibson]

@jjonescz I am currently trying to debug the new test and understand what is happening with the virtual project.. but, it looks like the test works by spawning a subprocess, which debugger is not attached to. Do you have any suggestions for how to debug efficiently when working in this area?

[jjonescz]

I debug by adding a new launch profile to src\Cli\dotnet\Properties\launchSettings.json, something like:

{
  "profiles": {
    "dotnet": {
      "commandName": "Project"
    },
    "redist": {
      "commandName": "Executable",
      "executablePath": "dotnet",
      "commandLineArgs": "exec $(SolutionDir)artifacts\\bin\\redist\\Debug\\dotnet\\sdk\\10.0.200-dev\\dotnet.dll run Program.cs",
      "workingDirectory": "$(SolutionDir)artifacts\\tmp\\Debug\\testing\\ProjectRefere---C5C43CCB",
      "environmentVariables": {
        "DOTNET_CLI_CONTEXT_VERBOSE": "true",
        "MSBUILDTERMINALLOGGER": "off",
        "CI": "true"
      }
    }
  }
}

The working directory comes from the test which sets up the scenario. Of course you also need to set the command line args correctly. And then just debug with VS.

[baronfel]

I do similar with a vscode launch.json :D