Set up launch.json to open each sample in VSCode

[Arlodotexe]

In order to launch and debug in VSCode, the .vscode/Launch.json file needs to be set up for each sample with options to run the project.

The guidance from Uno is one approach, but will quickly bloat the Run dropdown and requires additional user interaction.

Instead, we can take a cue from the Uno QuickStart guide, and set up a small script that takes a project path as passed as an argument. This will allow us to have 1 project per dropdown item.

This script will need to:

1. Run uno-check --non-interactive --target wasm --fix to set ensure the environment is set up properly, without bothering the user.
2. Tell omnisharp to use the selected project (needs investigation)
3. dotnet run the app at the given path and kick off the debug session.

[Arlodotexe]

Keeping a list of notes for future reference:

• The Uno Platform VSCode extension does not always enable the use of uno-check from the command line. This is fine because we can manually install with dotnet tool install --global Uno.Check
• We won't need uno-check if we can configure the dev container to include exactly what we need.R
• Omnisharp must select a project before we do dotnet run.
• The omnisharp dropdown was broken in VSCode recently. We shouldn't need this, but just in case, tracking that issue here.
• As far as I can find, omnisharp doesn't allow for selecting a project programatically via the command line, but we can:
  • Selectively load a specific solution on startup. May need a WASM only solution to avoid popup errors.
  • Load a solution on demand, when the user selects a file. Maybe direct linking to a file on startup, or using a markdown linking to all samples?
• Need to find a way to automatically make exposed ports Public instead of private. The WASM app will fail to load otherwise.
• Omnisharp will automatically find and run CSX files in a directory when loading a project. We can use this if needed.

[Arlodotexe]

Quick update on findings:

• uno-check won't be needed at all, the devcontainer config is more than enough for building WASM.
• No need to select a project with omnisharp before running a project. Worked around this by using a special build command / cert fix extracted from the Uno Quickstart gitpod.
• Still haven't found a way to expose ports as Public automatically. The user will need to do this manually for now.
• Direct linking to specific samples may be possible, but it'll require some tinkering and research to nail down the setup
  • Separate folders can have a different devcontainer files. (Configuring separate containers).
  • You can link directly to a workspace in a codespace like this.