Integrate DTS emulator with workspace view

[philliphoff]

Adds a DTS emulator node to the Workspace view of the Azure Resources explorer, which will show running DTS emulator instances. This node offers the ability to start new emulator instances. Emulator nodes, like in the Azure Resources view, offers the abilities:

• Copy connections strings
• Open the corresponding task hub dashboard
• Shutdown the emulator

The DTS settings have been updated to allow customization (i.e. registry, image, tag) of the emulator container image. Emulators started by the VS Code instance will be shutdown when the instance is closed. (Emulators started outside of the VS Code instance will not be shutdown.)

Note: the emulator features are not hidden behind the "preview features" toggle as they are (as of now) available to all.

[nturinski]

Phil, would it be possible to add a command to install/uninstall the emulator similar to Azure Functions Core Tools?

When you activate the extension, it immediately throws an error as well:

I think that it may be a jarring experience for users that do not have the DTS emulator installed or are not engaging with it.

[philliphoff]

@nturinski Thanks for taking a look.

Phil, would it be possible to add a command to install/uninstall the emulator similar to Azure Functions Core Tools?

The emulator is just a Docker container; there's nothing to install or uninstall really (save pulling/removing an image). I'll think about whether we can show/hide the workspace node based on the existence of the image (and then have a command that just pulls it). I feel that's not terribly discoverable, though.

When you activate the extension, it immediately throws an error as well:

Well that's not good; I'll try to repro and resolve that.

[nturinski]

The emulator is just a Docker container; there's nothing to install or uninstall really (save pulling/removing an image). I'll think about whether we can show/hide the workspace node based on the existence of the image (and then have a command that just pulls it). I feel that's not terribly discoverable, though.

I think if the node could instruct users on where/how to get the image, that could be helpful. Like a disabled/enabled state? That way we could still have the discoverability regardless.

[philliphoff]

I think if the node could instruct users on where/how to get the image, that could be helpful. Like a disabled/enabled state? That way we could still have the discoverability regardless.

@nturinski The image will be auto-pulled if/when the user attempts to start the container, so there's nothing they need to do (aside from Docker being running).

That said, I've added some robustness to the Docker management logic, and on errors the DTS Emulators node will show a warning node with the error (e.g. "is Docker installed and running?"). I've also updated the root node to auto-expand only if emulators are already running. This should make the feature a little less "in your face" if you're not actually using it.

[alexweininger]

Would you want to try to start the Docker runtime for the user if it's not already running? I know there are other runtimes, but I think most devs still use Docker. Mostly suggesting it because I was using the dev containers feature in VS Code today and it auto started Docker desktop for me so it's fresh in my mind.

[alexweininger]

Non-blocking feedback here:

Since there aren't that many actions available on the emulator tree item and the task hub item, I think it makes sense to expose the "big" ones as buttons on the tree item itself. Similar to the buttons we have on the Functions local project tree item:

I think at least a stop/start button on the emulator item would make a lot of sense. And an open in dashboard button on the task hub. I figure we might as well make these things as discoverable as possible.

[philliphoff]

Would you want to try to start the Docker runtime for the user if it's not already running? I know there are other runtimes, but I think most devs still use Docker. Mostly suggesting it because I was using the dev containers feature in VS Code today and it auto started Docker desktop for me so it's fresh in my mind.

@alexweininger I talked to the Docker extension team and they, themselves, do not automatically start the container runtime so I'm hesitant to try to do that in this case. (Just trying to understand which runtime is in use and how to start it would be a significant concern--I'm using the Docker extension client library to abstract away the runtime being used, so the extension doesn't actually know.)

[philliphoff]

I think at least a stop/start button on the emulator item would make a lot of sense. And an open in dashboard button on the task hub. I figure we might as well make these things as discoverable as possible.

@alexweininger Those are good ideas and I've added inline commands for opening the taskhub dashboard, as well as for starting and stopping emulator instances.