Add support for multiple project azds debug configuration on vscode extension

[feroz-ahmmed]

I have a dotnet solution with multiple projects under it. service.sln --> service.API.csproj --> sevice.Model.csproj

How do I crate initial templates for azds for this?

[ynambiar]

Thanks for your question @feroz-ahmmed!

Assuming you've enabled the Azure Dev Spaces extension for VS Code, you should be able to prep the second project by following these steps:

• Open the first project in VS Code
• Add the second project by going to 'File > Add Folder to Workspace...'
• To prepare the config files for the second project, go to 'View > Command Palette > select 'Azure Dev Spaces: Prepare configuration files or Azure Dev Spaces' > select the second project

Hope this works for you!

[feroz-ahmmed]

@ynambiar , I only need azds configuration for service.API project. But this project have reference of service.Model project. My problem is the auto generated files (i.e - Dockerfile) are not considering the referenced projects. I also intend to have support for remote debugging as well on launch configuration for vscode such that I can have my debugger attached on both of my projects.

[feroz-ahmmed]

@ynambiar , It looks like visual studio 2017 is doing everything perfectly with their extension for kubernetes as we have the context of a solution there. But vscode is being a bit naive here.

[ynambiar]

@feroz-ahmmed, that makes sense. We are actually working on this feature now and will update here when it's in production. Thanks!

[robertjf]

@ynambiar I've been looking into this issue as well - is it possible to have the tooling for VS Code generate the launch and tasks in .vscode from a Solution instead of a project? It seems like a logical thing to do for me. When I try to prep the primary project (sitting in a sub directory) it creates the azds.yaml and docker.develop files, but doesn't go far enough to create the debug configuration. I've tried manually creating it from the sample project setup, and have had to tweak the docker.develop file as well, but am stuck with the paths I think - I get the following error after it's succesfully created the docker image:

Starting: "azds" exec --interactive --on-exit-resume-up --verbose -- /vsdbg/vsdbg --interpreter=vscode
Error from pipe program 'azds': No such file or directory

UPDATE: I found the issue - for some reason vsdbg wasn't installed in the image - I had to add the following to my Docker.develop file:

RUN apt update && \
    apt install unzip && \
    curl -sSL https://aka.ms/getvsdbgsh | /bin/sh /dev/stdin -v latest -l /vsdbg

My custom docker.develop file now looks like this:

FROM mcr.microsoft.com/dotnet/core/sdk:2.2
ARG BUILD_CONFIGURATION=Debug
ENV ASPNETCORE_ENVIRONMENT=Development
ENV DOTNET_USE_POLLING_FILE_WATCHER=true
EXPOSE 80

RUN apt update && \
    apt install unzip && \
    curl -sSL https://aka.ms/getvsdbgsh | /bin/sh /dev/stdin -v latest -l /vsdbg

WORKDIR /src
COPY ["src/Services/AddressBook/AddressBook.API", "AddressBook.API/"]
COPY ["src/Services/AddressBook/AddressBook.Infrastructure", "AddressBook.Infrastructure/"]
COPY ["src/Services/AddressBook/AddressBook.Domain", "AddressBook.Domain/"]
COPY ["nuget.develop.config", "AddressBook.API/"]

WORKDIR /src/AddressBook.API
RUN dotnet restore AddressBook.API.csproj --configfile nuget.develop.config

WORKDIR /src/AddressBook.API

RUN dotnet build --no-restore -c $BUILD_CONFIGURATION

ENTRYPOINT ["dotnet", "run", "--no-build", "--no-launch-profile", "-c", "$BUILD_CONFIGURATION", "--"]

This is loosely based on the eShopOnContainers reference project here: https://github.com/dotnet-architecture/eShopOnContainers/blob/dev/src/Services/Ordering/Ordering.API/Dockerfile.develop

So now the question is, why is vsdbg not installed by default in my image, while the sample "mywebapi" project works just fine?

[daniv-msft]

As of today, the easiest way to make solutions work with our VS Code extension is to open its projects as workspaces in Visual Studio Code. That way, it is possible to prep and debug them in a somewhat similar way as what we would have with a solution. Please note though that we don't handle well upgrades of azds.yaml files in multi-workspaces scenarios, which may cause confusion. We have a fix for this, that will be released in the coming days.

@robertjf Regarding your question about vsdbg, I will let other persons knowing more about this answer.

[xinyanmsft]

@robertjf when you have the 'vsdbg' problem with VSCode, there should be a 'azds' process running on your machine, and the command line argument looks something like 'azds daemon ...'. What is the full command line argument for that process? If you are using Windows, go to 'Task Manager' and look for 'azds.exe' processes, one of them should have argument 'azds.exe daemon ...'. If you are using Mac, do 'ps aux | grep azds'. Thanks!

[robertjf]

@xinyanmsft I managed to get it working by setting the VS Code workspace to the API project directory and running the >Azure Dev Spaces: Prepare configuration files for Azure Dev Spaces command from there - everything worked out of the box, all I had to do was delete the generated charts directory as I'm using charts from a different repository and have already set up the azds.yaml file for that.

The problem I have with this approach is that I lose visibility on the supporting project source code. My solution structure is as follows:

- AddressBook.API
    |   AddressBook.sln
    + src
        + Services
            + AddressBook
                + AddressBook.API
                |   azds.yaml
                |   AddressBook.API.csproj
                |   Dockerfile.develop
                |   values.dev.yaml
                |   nuget.develop.config
                + AddressBook.Infrastructure
                |   AddressBook.Infrastructure.csproj
                + AddressBook.Domain
                |   AddressBook.Domain.csproj

Ideally, I'd like to be able to have the workspace mirror this structure and still be able to debug the AddressBook.API project as the entry point.

For reference, my azds.yaml and Dockerfile.develop currently look like this (loosely based on the eShopOnContainers solution):

kind: helm-release
apiVersion: 1.1
build:
  context: ../../../../
  dockerfile: Dockerfile
install:
  chart: ../../../../../HelmCharts/charts/addressbook-api
  set:
    replicaCount: 1
    image:
      tag: $(tag)
      pullPolicy: Never
    ingress:
      annotations:
        kubernetes.io/ingress.class: traefik-azds
      hosts:
      - $(spacePrefix)$(rootSpacePrefix)medipulse$(hostSuffix)
    inf:
      k8s:
        dns: $(spacePrefix)$(rootSpacePrefix)medipulse$(hostSuffix)
  values:
  - values.dev.yaml?
  - secrets.dev.yaml?
  - ../../../../../HelmCharts/charts/inf.yaml
  - ../../../../../HelmCharts/charts/app.yaml
configurations:
  develop:
    build:
      dockerfile: Dockerfile.develop
      useGitIgnore: true
      ignore:
      - “!nuget.develop.config”
      args:
        BUILD_CONFIGURATION: ${BUILD_CONFIGURATION:-Debug}
    container:
      sync:
      - '**/Pages/**'
      - '**/Views/**'
      - '**/wwwroot/**'
      - '!**/*.{sln,csproj}'
      command: [dotnet, run, --no-restore, --no-build, --no-launch-profile, -c, "${BUILD_CONFIGURATION:-Debug}"]
      iterate:
        processesToKill: [dotnet, vsdbg, addressbook]
        buildCommands:
        - [dotnet, build, --no-restore, -c, "${BUILD_CONFIGURATION:-Debug}"]

FROM mcr.microsoft.com/dotnet/core/sdk:2.2
ARG BUILD_CONFIGURATION=Debug
ENV ASPNETCORE_ENVIRONMENT=Development
ENV DOTNET_USE_POLLING_FILE_WATCHER=true
EXPOSE 80

#RUN apt update && \
#    apt install unzip && \
#    curl -sSL https://aka.ms/getvsdbgsh | /bin/sh /dev/stdin -v latest -l /vsdbg

WORKDIR /src
COPY ["src/Services/AddressBook/AddressBook.API", "AddressBook.API/"]
COPY ["src/Services/AddressBook/AddressBook.Infrastructure", "AddressBook.Infrastructure/"]
COPY ["src/Services/AddressBook/AddressBook.Domain", "AddressBook.Domain/"]

WORKDIR /src/AddressBook.API
RUN dotnet restore AddressBook.API.csproj --configfile nuget.develop.config

RUN dotnet build --no-restore -c $BUILD_CONFIGURATION

ENTRYPOINT ["dotnet", "run", "--no-build", "--no-launch-profile", "-c", "$BUILD_CONFIGURATION", "--"]

I've commented out the command to install vsdbg as it's now working correctly in this configuration.

I also noticed that since getting this running at the project level, if I go back to my solution-level Workspace, it now also works with one exception - the debugger launches properly, and azds properly syncs and connects to the dev space; however there is no related Output log I can go to inspect the services and their respective urls:

So not really sure what's changed other than configuring azds at the project level; and I can't replicate the errors I was getting before at the solution level.

For reference, here's my launch and task at the solution level:

launch.json:

{
   "version": "0.2.0",
   "configurations": [
        {
           "name": ".NET Core Launch (AZDS)",
           "type": "coreclr",
           "request": "launch",
           "preLaunchTask": "azds: prelaunch",
           "pipeTransport": {
               "pipeCwd": "${workspaceFolder}/src/Services/AddressBook/AddressBook.API/",
               "pipeProgram": "azds",
               "pipeArgs": [
                   "exec",
                   "--interactive",
                   "--verbose",
                   "--on-exit-resume-up",
                   "--"
               ],
               "debuggerPath": "/vsdbg/vsdbg",
               "quoteArgs": false
           },
           "cwd": "/src/AddressBook.API/",
           "program": "/src/AddressBook.API/bin/Debug/netcoreapp2.2/AddressBook.API.dll",
           "sourceFileMap": {
               "/src": "${workspaceFolder}/src/Services/AddressBook/."
           }
        }
    ]
}

tasks.json:

{
    "version": "2.0.0",
    "tasks": [
        {
            "label": "azds: prelaunch",
            "command": "azds",
            "args": [
                "up",
                "--await-exec",
                "--keep-alive"
            ],
            "options": {
                "cwd": "${workspaceFolder}/src/Services/AddressBook/AddressBook.API/"
            },
            "problemMatcher": "$msCompile"
        }
    ]
}

Edit: as part of the debugging, I updated the azds version using az aks use-dev-spaces --update - I'm wondering whether that has fixed the problem with having the workspace at the solution level?

[xinyanmsft]

@robertjf from your description, it doesn't look like the VSCode extension for DevSpaces is working as intended. I am very curious how you setup your workspaces in VSCode. Here's how I work:

1. In VSCode, open directory src\AddressBook\AddressBook.API.
2. In VSCode, 'Save Workspace As', create something like src\AddressBook\myapp.code-workspace
3. In VSCode, use "add workspace folder", add directory src\AddressBook\AddressBook.Infrastructure and src\AddressBook\AddressBook.Domain. Save workspace.

This will create a workspace that contains all of your code. Then I select "Azure Dev Spaces: Prepare configuration files for Azure Dev Spaces" command, select the src\AddressBook\AddressBook.API project, let it generate the launch.json and tasks.json for AddressBook.API project.

During debug launch, I will select the one 'Launch Server (AZDS) (AddressBook.API)' and it should work properly.

[robertjf]

That's what I've done to get it working - the only difference is that I already had custom azds.yaml and dockerfile.develop files (derived from eShopOnContainers) and my charts are sitting in a different directory; but all I had to do was delete the charts directory that was generated when I ran "Azure Dev Spaces: Prepare configuration files for Azure Dev Spaces" (it left the azds.yaml and dockerfile.develop alone).

My only problem now is that the Dev Spaces log is not available anymore that displays the urls.

[xinyanmsft]

@robertjf Do you have multiple instances of VSCode running at the same time? There is a case if 2 VSCode instances both open src\AddressBook\AddressBook.API, one of them may not see the log.

[robertjf]

Aha - I do use multiple instances constantly. Will do some tests and see if it makes a difference

[xinyanmsft]

@robertjf please let us know what you find. Limiting to a single VSCode instance should resolve your issue. In the meantime I will create a work item in DevSpaces to address multi-instances VSCode scenario.

[robertjf]

@xinyanmsft I closed down all instances (there was only one running) and re-opened VSCode - I then closed the folder and temporary workspace that came up so I had a single empty VSCode window and loaded the AddressBook.API workspace, but still no logs. It seems the log is completely missing.

I've just noticed also that the workspace was at the solution level, not the project level. At this level, there is no azds log.

I then opened up the sample mywebapi project (it already has the bootstrapped dev spaces files with no modification) and went into debug - the log shows up in this instance.

So I then just opened the folder containing the API project instead of the workspace - I had to run the "Azure Dev Spaces: Prepare configuration files for Azure Dev Spaces" command again, and when I go to debug (I had to modify the launch command so it mapped the source and found the dll properly) the azds log shows up.

So it appears that it's reliant on being in the starting project folder. My problem then is that this solution uses multiple projects and I need to be able to browse the code in the other projects to set breakpoints etc.

Another point - when I open the project directory with the dev spaces initialised, I'm greeted with

Azure Dev Spaces CLI

1.0.20190708.7
API v3.2

Azure Dev Spaces daemon started.

in the logs. If I then switch to the workspace at the solution level without closing VS Code, the log disappears. But then I suppose VS Code is reloading everything in this case.

[xinyanmsft]

@robertjf I think the temporary workspace is what make things broken. Can you save the workspace, from VSCode do 'Close Folder' or 'Close Workspace', and quit VSCode? Then open VSCode (make sure it's empty) and open that workspace? VSCode will start new instances when transitioning from temporary workspace to folder or another workspace.

[robertjf]

Hi @xinyanmsft the temporary workspace in the Project Folder worked fine, but the saved one in the solution directory didn't.

When I saved the project workspace and closed it, then quit VSCode and restarted it, I then opened the original workspace at the solution level and tried to debug - I received this error again:

> Executing task in folder AddressBook.API: azds up --await-exec --keep-alive <

Could not locate an applicable session to keep ports and file synchronization alive. If calling from a tool with built-in support for Azure Dev Spaces, restart the tool.
The terminal process terminated with exit code: 1

I tried to do a ps aux | grep azds but nothing showed up, so clearly the azds daemon isn't running (none of the azds.yaml, dockerfile.develop, etc. files are in the root of this workspace so I'm gathering this is relatively normal.)

I then closed the workspace and shutdown VS Code again to get a clean start, and opened the project-level workspace. This time, ps aux | grep azds gave me the following:

Gandalfpellbook:AddressBook.API rob$ ps aux | grep azds
rob               3096   0.0  0.0  4408328    928 s001  S+   11:26am   0:00.00 grep azds
rob               3035   0.0  0.2  7677544  58348   ??  Ss   11:26am   0:01.15 azds daemon --ppid 3024 --import azds/azds-vsdbg:15.4@/vsdbg:/vsdbg
Gandalfpellbook:AddressBook.API rob$ 

Without closing the project-level workspace, I opened up the solution level one in another VS Code window and was successfully able to run the debugger.

[feroz-ahmmed]

@robertjf from your description, it doesn't look like the VSCode extension for DevSpaces is working as intended. I am very curious how you setup your workspaces in VSCode. Here's how I work:

1. In VSCode, open directory src\AddressBook\AddressBook.API.
2. In VSCode, 'Save Workspace As', create something like src\AddressBook\myapp.code-workspace
3. In VSCode, use "add workspace folder", add directory src\AddressBook\AddressBook.Infrastructure and src\AddressBook\AddressBook.Domain. Save workspace.

This will create a workspace that contains all of your code. Then I select "Azure Dev Spaces: Prepare configuration files for Azure Dev Spaces" command, select the src\AddressBook\AddressBook.API project, let it generate the launch.json and tasks.json for AddressBook.API project.

During debug launch, I will select the one 'Launch Server (AZDS) (AddressBook.API)' and it should work properly.

hi @xinyanmsft, followed your steps. But the auto generated files from dev spaces command still same.

[xinyanmsft]

@robertjf @feroz-ahmmed sorry the VSCode extension is having problem with workspace enabled. Here is a work around for this issue.

1. Quit / Close all VSCode windows. Make sure no 'azds' process is running.
2. Open a console terminal, go to the directory where 'azds.yaml' file exists. Run this command (if it's a C# project) azds daemon --import azds/azds-vsdbg:15.3@/vsdbg:/vsdbg or (if it's a node project) azds daemon or (if it's a Java project) azds daemon --import azuredevjava/javadebug:0.2.2@/javadebug:/javadebug
3. Continue using VSCode. The output will come from this console window. You need to manually terminate the 'azds daemon' process once you've closed VSCode.

We will start fixing the problem as soon as possible.

[robertjf]

thanks @xinyanmsft - look forward to a progress update.

[xinyanmsft]

@robertjf we are working on fixing this issue. to make sure we are working on the right problem, can you help me collect some client logs? please:

1. DevSpaces client logs are saved under $TMPDIR/Azure Dev Spaces/ folder. Kill all existing 'azds' processes, clean this directory.
2. Reproduce this bug. Then close all VSCode instances, and verify all 'azds' process are terminated.
3. Send (xinyan@microsoft.com) all the log files under $TMPDIR/Azure Dev Spaces folder. Thanks very much!

[robertjf]

@xinyanmsft can you tell me where to find the log files on OSX perhaps?

[xinyanmsft]

in OSX, the directory is $TMPDIR/Azure\ Dev\ Spaces on my machine, this expands to:

/var/folders/bd/2cvhy2894kq1fsxnr6fms40000gn/T/Azure Dev Spaces

[robertjf]

@xinyanmsft logs attached... I ran this from the Solution directory as mentioned above (https://github.com/Azure/dev-spaces/issues/120#issuecomment-514018247) - let me know what other tests you would like me to do... azds.zip

[xinyanmsft]

@robertjf from your log, it seems DevSpaces VSCode extension didn't launch the daemon process. The VSCode extension looks at the current directory for 'azds.yaml' file, and launch the daemon process if that file exists. In this case, if you open VSCode on the solution directory, it doesn't have azds.yaml file and thus will fail to debug. I don't know how you have launch.json file at the solution level, but it seems to be the problem. In another word, in your launch.json, pipeTransport.pipeCwd should always be "${workspaceFolder}". Here is what I think the VSCode files (app.code-workspace, .vscode/launch.json, .vscode/tasks.json) should be:

• AddressBook.API | AddressBook.sln | app.code-workspace
  • src
    • Services
      • AddressBook

        • AddressBook.API	azds.yaml	+ .vscode		launch.json		tasks.json
          AddressBook.API.csproj
          Dockerfile.develop
          values.dev.yaml
          nuget.develop.config

        • AddressBook.Infrastructure | AddressBook.Infrastructure.csproj
        • AddressBook.Domain | AddressBook.Domain.csproj

And the content of app.code-workspace is something like:

{ "folders": [ { "path": "src/Services/AddressBook/AddressBook.API" }, { "path": "src/Services/AddressBook/AddressBook.Infrastructure" }, { "path": "src/Services/AddressBook/AddressBook.Domain" } ] }

If the above setup does not work, can you please share the logs again? we recently fixed an issue that could impact this area (available to public in roughly 2 weeks), I want to confirm that will work for you. Thanks!

[robertjf]

hi @xinyanmsft that's worked a treat - I had to modify the launch.json cwd and program parameters to match the docker image file structure but all good apart from that.

[rdbartram]

@robertjf did you get this working with breakpoints in your dependent projects. I created a workspace with all the projects added individually...I can now debug the main app and add breakpoints in that project...the sub project breakpoints aren't picked up though in the debug session and are just ignored :(

[robertjf]

@rdbartram I haven't tried for a while tbh, most of the team use Visual Studio, I'm the only one really that uses vscode...