Use VS Code's built-in launch configuration detection

[stewartadam]

When opening up a large project that consists of several C# projects (including some Azure Functions), the extension will never detect/offer to produce settings. One must open the specific folder containing the Azure Function .csproj file for it to offer to build launch configuration, meaning users need to either (1) do so and then merge that configuration, adjusting paths, into their parent workspace; or (2) keep two editor windows open - one for editing the broader solution, and a second for launching the Azure Function.

Asks:

1. The extension should find and offer to produce missing launch configurations for any Azure Function csproj files in the workspace, not just the top-level opened folder.
2. It would be nice if the Function detection could be built-in to the existing VS Code launch configuration detection instead of using its own separate configuration detection.

[ejizba]

We do have a setting "azureFunctions.projectSubpath" which is supposed to help for this situation. Basically, set that to the subpath of the functions project, run the "Initialize Project for Use with VS Code" command (we prompt users to do this in a few places, or you can access it from the command palette), and things should just start working

The extension should find and offer to produce missing launch configurations for any Azure Function csproj files in the workspace, not just the top-level opened folder.

We automatically look for projects at the root of the workspace or 1 folder level down. This detection logic happens when users first open a VS Code window and we didn't want to search the entire workspace because that could negatively affect startup performance.

It would be nice if the Function detection could be built-in to the existing VS Code launch configuration detection instead of using its own separate configuration detection.

This is worth looking into. I think I tried it a while ago and the VS Code API wasn't quite good enough. For example I think it only let us specify content to go into the "launch.json" file and we would need to edit the "tasks.json" and "settings.json" files as well.

[stewartadam]

We do have a setting "azureFunctions.projectSubpath"

Am I correct in understanding that this would only work/assume you have a single Azure Function in the workspace? Although detecting Functions a few folders level deep is part of the request, the other is that projects often have several functions so it'd be nice to have the configs detected and setup for more than just one hardcoded in azureFunctions.projectSubpath.

[ejizba]

There's a bit of confusion here in terminology between "function" and "project". That setting should point to the root of your project, where the "host.json" file is, but that project can contain multiple functions.

If you want to debug multiple projects at once, we have this doc on how to do it: https://github.com/microsoft/vscode-azurefunctions/wiki/Multiple-function-projects

[stewartadam]

That's correct, sorry I should have clarified multiple Azure Function projects (which as you point out can each supply multiple individual functions) -- so it looks like Option 2 is the path forward for now.

However this is unfortunate because it requires initialization of the Functions one-by-one, then grouping them into a workspace which Omnisharp will fail to support (OmniSharp/omnisharp-roslyn#909) leaving a very poor developer experience.

[ejizba]

The issue you linked in OmniSharp is pretty sparse and old, so I'm not sure how relevant it is. What exactly doesn't work with OmniSharp multi-root workspaces?

[stewartadam]

Taking a step back, what I'm trying to convey is that the developer experience around editing anything more than a single azure function (particularly if across solutions) is very poor.

Specifically around omnisharp - issue linked is indeed old but still relevant, multiple solutions are not supported by OmniSharp and you have to switch between which standalone projects or solution file is currently being served. So if you have something like:

src/
  src/soln1/
    soln1.sln
    library_project/
      library_project.csproj
      ...
    azfunc/
      azfunc.csproj
      ...
  src/soln2/
    soln2.sln
    library_project/
      library_project.csproj
      ...
    azfunc/
      azfunc.csproj
      ...

and open the folder containing this structure in VS Code, the user gets broken problem detection for a good chunk of your codebase.

The functions also won't get detected and configured. You have to open each one individually i.e. code src/soln1/azfunc to get the prompt to generate its launch configuration (however functions are detected multiple projects exist directly in the current folder, not nested deep or in separate solutions).

If you use a multi-root workspaces, then you're just re-adding subfolders as top-level one and now you've got duplicated files trees, etc.

I also tested with a simpler structure, two blank HTTP Functions in a local folder with:

mkdir foo
cd foo

for i in 1 2;do
  mkdir -p azfunc${i} && pushd azfunc${i}
  func init --dotnet
  func new --template 'HTTP Trigger' --name azfunc
  code --add .
  popd
done

VS Code does detect them for initialization with code foo, but since their configurations are called the same ("Attach to Azure Functions") you still have to manually meddle with their launch files to build the composite launch config as described in the multi-root workspace doc.

Lastly, through this testing I accidentally clicked "Don't show again" to the initialize for VS Code prompt and now it's never returned, despite my user + workspace setting for "Show Project Warning" being enabled.

[scgbear]

Internal Tracking

devdivcsef 412378

[AzCode-Bot]

This issue has become stale and is at risk of being closed. The community has 60 days to upvote the issue. If it receives 5 upvotes we will keep it open and take another look. If not, we will close it. To learn more about how we handle issues, please see our documentation.

Happy Coding!