Update the documents in the repo/product per MS corporate governance guidelines, including the LICENSE, NOTICE, README, and CONTRIBUTING documents. Also ensure all source contains its proper copyright header.

While trying to setup a multiprocess debugging of several DAPR-enabled services, I came across this particular issue: the DAPRD tasks do not expand VSCode variables. E.g. specifying

{
    "appId": "userservice",
    "appPort": 5001,
    "label": "daprd-userservice",
    "type": "daprd",
    "dependsOn": ["build-userservice"],
    "metricsPort": 9091,
    "grpcPort": 50002,
    "httpPort": 3501,
    "componentsPath": "${workspaceFolder}\\DotNetBa.Dapr.UserService\\components",
}

will produce the following task execution:
Executing command: daprd --app-id "userservice" --app-port "5001" --components-path "${workspaceFolder}\DotNetBa.Dapr.UserService\components" --dapr-grpc-port "50002" --dapr-http-port "3501" --metrics-port "9091" --placement-address "localhost:50005"

I think variable expansion should be allowed for these tasks.

Currently, Python projects being Dapr-ized will default to port 8000, which is typically fine for Django but not for Flask (which typically uses port 5000). We should add a little more smarts to the scaffolder to try to differentiate between Flask and Django applications, and then default to the appropriate port.

Currently the Dapr tasks scaffolder uses the environment variable DAPR_NETWORK to determine whether scaffold the Redis-related Dapr components file addresses using localhost (not present) or redis (present). However, the latter may not match the actual Redis host name in that network (e.g. the Dev Container template uses dapr_redis). Instead, the scaffolder should use DAPR_REDIS_HOST which is generally expected to be set when using a custom network.

The extension currently defaults to port 80, when scaffolding Dapr tasks for Java applications. We should look at making the scaffolder smarter, e.g. choosing 8080 in the case of a canonical Spring-based, Tomcat-running application.

Dapr 0.4.0 brings breaking changes to the state store component configuration (to support multiple state stores). As a result, the standalone component configuration scaffolded by the CLI is different (both in naming and content). The equivalent scaffolding in the extension needs to change to match.

The daprd task uses a custom problem matcher such that the task "completes" (from VS Code's point of view) when it outputs that it's waiting for the associated application to startup, which then allows VS Code to spin up the application in the debugger. However, if the application is not a web application (e.g. a console application that just uses the Dapr SDK), then daprd does not wait for the application and simply goes to its "initialized" state. The problem matcher then doesn't understand this and therefore task "hangs".

We may need to have two problem matchers for each application type if we cannot support both scenarios in the same matcher (via a more complex Regex).

In the meantime, a workaround is to customize the problem matcher for the console application, as so:

{
           "appId": "app",
            "label": "daprd-debug",
            "type": "daprd",     
            "dependsOn": "build",
            "grpcPort": 53310,
            "problemMatcher": {
                "pattern": [
			{
				"regexp": ".",
				"file": 1,
				"location": 2,
				"message": 3
			}
		],
		"background": {
			"beginsPattern": "^.*starting Dapr Runtime",
			"endsPattern": "^.*dapr initialized"
		}
            }
        }

Before we accumulate too much untested code, update the infrastructure for running tests:

• Move test running to the new Gulp pipeline
• Allow true "unit" tests to run outside of the VS Code instance (for performance reasons)
• Allow debugging unit tests

When no Dapr applications appear to be running, the extension checks (1) whether Dapr appears to be installed and (2) whether Dapr appears to be initialized. The latter is done by looking for a running Docker container based on the daprio/dapr image. However, if the extension is running within the context of a Dev Container, the extension does not appear to find the daprio/dapr image, and so reports that Dapr may not be initialized. (Running a Dapr application within the Dev Container will cause the application to be displayed within the extension.)

It looks like the Docker inspect .Image property may not be consistent in all environments (i.e. a SHA image name is specified instead); we may need to additionally check .Config.Image.

Presumably this is because you run daprd.exe with parameters and app is not launched with "dapr run" command which is what dapr list requires. It would be good to see if we can find a way to make dapr list work int this debugging scenario.

Update the CI dependencies (e.g. version of Node.js, Ubuntu, etc.) as they're becoming out of date.

On Windows, no applications are shown in the Dapr applications tree view even when verified running. Also, the daprd-down task is not able to kill running Dapr applications.

OS: Windows
Build Version: 20200228.2
Node.js Version: 12.x.x

Repro Steps:

1. Create and initialize a new Express.js application by below:

npx express-generator nodeapp
cd nodeapp
npm install

2. Open this application folder in VS Code --> Switch to the debug tab -->Select "create a launch.json" file --> Select "Node.js" when asked to select an environment.
3. Select "Dapr: Scaffold Dapr Tasks" from Command Palette --> Select "Launch Program" when asked to select a configuration --> Enter an application ID --> Enter an application port.
4. Open the ".vscode/tasks.json" file --> Check whether there is a dependency ("dependsOn") and it should set to "build".

Expect:
There is a dependency ("dependsOn") and it has been set to "build".

Actual:
There is no a dependency named "dependsOn".

• vscode 1.44.2
• dapr 0.6.0
• vscode dapr 0.2.1
• vscode python 2020.4.74986

Reproduction steps:

• clone the python sdk repo
• open example.py in the repo
• click create a launch.json file in the vscode activity bar and choose Python File
• run Dapr: Scaffold Dapr Tasks on the Python: Current File config that was created; use default app id and port
• in the generated tasks.json, comment the line "appPort": 8000,
• select example.py in vscode and run the generated Python: Current File with Dapr config

I would expect the python file to be run after daprd is finished but based on the vscode ui, it looks like the task is blocking. Uncommenting the "appPort": 8000, line allows the python file to run but, for example, the example.py in the python sdk isn't a service that is invokable by dapr and simply houses a dapr client, so the appPort shouldn't be required.

Thanks for the extension, it's great!
I have a few feature suggestion that would be nice to have:

• View / attach to logs from an application, maybe just like the VS Code Docker extension, right click and view logs.
• View / attach to published events.
• View running/sleeping actors.

Add an option to kill a running Dapr application (i.e. its dapr or daprd instance) from the Dapr applications tree view. If the application does not shut down nominally after debugging, it's not always obvious how/where to stop it so that the user can restart without fear of strange conflicts. (Especially since the dapr CLI does not show arbitrarily started daprd instances.)

The applications tree view could offer a "kill" context menu command (at least for instances that it, itself, started) to allow for quick, forced shutdowns and restarts.

Issue Type: Bug

1. Create an actor service and the actor client: https://github.com/dapr/dotnet-sdk/blob/master/docs/get-started-dapr-actor.md
2. Start the service with dapr:
   dapr run --port 3500 --app-id demo_actor --app-port 5001 dotnet run
3. Start MyActorClient => Successfull
4. Stop the dapr task
5. Add a .net core task in visual studio code
6. Scaffold a task using the dapr addin. AppPort: 5001
7. Start the new task
8. Start MyActorClient => Exceptions
   Unhandled exception. Dapr.Actors.DaprException: error finding address for actor type MyActor with id 1
   at Dapr.Actors.DaprHttpInteractor.SendAsyncHandleUnsuccessfulResponse(Func`1 requestFunc, String relativeUri, String requestId, CancellationToken cancellationToken)
9. Stop debugging, open file tasks.json and set "httpPort" explicit to "3500". Start the debugger again
10. Start MyActorClient => Same exception:
    Extension version: 0.1.0
    VS Code version: Code 1.42.1 (c47d83b293181d9be64f27ff093689e8e7aed054, 2020-02-11T14:45:59.656Z)
    OS version: Windows_NT x64 10.0.18363

The command Dapr: Scaffold Dapr Tasks produces the error Open a folder or workspace with a debug launch configuration. in vscode's workspace view (after doing a Open Workspace...). The command works as expected in the folder view (after doing a Open Folder...) with the same folders that are in the workspace.

This is on vscode 1.44.2 with the 0.2.1 extension.

The recently released Dapr 0.5.0 has several breaking changes, one of which is changing the daprd argument --dapr-id to --app-id. This causes the extension to generate incorrect command lines when launching daprd tasks as well as fail to properly detect running daprd processes.

We'll need to update the task as well as process provider components to match, and either release 0.2.0 early or create a patch release with this one fix. This also likely means locking the extension to 0.5.0 (and above)--there seems little reason to go to the effort to support both 0.4.0 and >= 0.5.0.

Dapr 0.5.0 Release Notes

With Dapr 0.5.0, the Dapr CLI (dapr) should now allow being started without actually starting an application, which should negate the need for the extension to start daprd directly. Switching to dapr-based tasks should have additional benefits in that the extension need no longer scaffold component files (as dapr does that itself), as well as plays a little nicer with dapr list.

OS: Windows
Build Version: 20200228.2
Node.js Version: 12.x.x

Repro Steps:

1. Create a new .NET Core 3.1 ASP.NET Web API application by "dotnet new webapi --no-https --name netwebapp".
2. Open the application in VS Code --> Select "Dapr: Scaffold Dapr Tasks" from Command Palette --> Select ".NET Core Launch (web)" when asked to select a configuration --> Enter an application ID --> Enter an application port.
3. Debug with ".NET Core Launch (web) with Dapr".
4. Navigate to the Dapr Explorer --> Right click the application --> Select "Invoke (Get) Application Method" --> Enter the application method "users".

Expect:
Succeed to invoke the application method.

Actual:
Pop up an error.

More Info:
This error also reproduces for node.js project.

The publish-all command is appearing on tree views (with no other items)--it should appear only on the applications tree view. Appropriate use of the when property in package.json will probably fix that.

Wrap the extension commands using the common library function that captures telemetry related to the commands.

Add a "topics" child node to each Dapr application, which itself has child nodes for each subscribed topic. These topic nodes should have a context menu command for publishing an event to that specific topic. Both topics and topic nodes should use appropriate icons.

With the release of Dapr 0.5.0, the daprd command contains several new arguments (e.g. --enable-metrics and --metrics-port). We need to add support for these arguments to the daprd task. In particular, because the metrics port defaults to a single, well-known port (rather than an random port), it prevents the tasks from being used to support debugging multiple Dapr applications on the same machine at the same time.

OS: Windows
Build Version: 20200228.2
Node.js Version: 12.x.x

Repro Steps:

1. Create and initialize a new Express.js application by below:

npx express-generator nodeapp
cd nodeapp
npm install

2. Open this application folder in VS Code --> Switch to the debug tab -->Select "create a launch.json" file --> Select "Node.js" when asked to select an environment.
3. Select "Dapr: Scaffold Dapr Tasks" from Command Palette --> Select "Launch Program" when asked to select a configuration --> Enter an application ID --> Enter an application port.
4. Open the ".vscode/tasks.json" file.

Expect:
There is no any warning/error after opening the tasks.json.

Actual:
Miss property "version" of tasks.json.

.

If the user is debugging an application within a Docker container (e.g. using the Docker extension for VS Code), the dapr and daprd tasks cannot be used as they invoke Dapr on the workspace machine, not within the container. We should investigate the feasibility of scaffolding a set of tasks that can start Dapr within that container.

One option could be to continue to open Dapr on the workspace machine and rely on port mapping/forwarding for the Dapr sidecar to reach the application. (Dynamic mapping may be complicated; fixed mapping should work.) Another option would be to create a Docker-ized flavor of the dapr and daprd tasks (or simply add a flag) that would instead run the commands within a specific container. (Dynamic container names may be complicated; fixed container names should work.)

To make it easy for users to get to Dapr-related documents, help, and provide feedback, add a "help" tree view to the Dapr tab which exposes (at least) these commands:

• A link to Dapr-related docs (likely in the main Dapr repo)
• A link for reporting Dapr-related issues to GitHub (likely our extension repo)

TSLint is deprecated in favor of ESLint (with TypeScript-specific rule extensions). We should make the switch while the codebase is small enough to manage a migration.

As event publication isn't (currently) tied to a specific application, we should expose the publish command at the top, tree view level in addition to the application node context menu.

Invocation of methods via Dapr fails with a certificate validation error when using Dapr with a .NET Core ASP.NET application configured for (forcing) SSL. As the default for newly scaffolded .NET Core ASP.NET applications is to use SSL, we should see if we can make that "just work".

Hi all,

i recently played around with Dapr and the vscode plugin, i installed the most recent runtime / CLI https://github.com/dapr/dapr/releases/tag/v0.5.0
https://github.com/dapr/dapr/releases/tag/v0.5.1

My sample application runs without any major problems if I manually user daprd, dapr and attach the debugger. However, after installing the extension I did "scaffold dapr tasks" and i do run in the following error when executing the task:

> Executing task: daprd-debug <

> Executing command: daprd --app-id "GamedevFabric" --app-port "3000" --placement-address "localhost:50005" <

time="2020-03-29T22:08:36.1516971+02:00" level=info msg="starting Dapr Runtime -- version 0.5.1 -- commit v0.3.0-rc.0-160-g514f806-dirty" app_id=GamedevFabric instance=Andreas-Desktop scope=dapr.runtime type=log ver=0.5.1
time="2020-03-29T22:08:36.1516971+02:00" level=info msg="log level set to: info" app_id=GamedevFabric instance=Andreas-Desktop scope=dapr.runtime type=log ver=0.5.1
time="2020-03-29T22:08:36.1516971+02:00" level=info msg="metrics server started on :9090/" app_id=GamedevFabric instance=Andreas-Desktop scope=dapr.metrics type=log ver=0.5.1
time="2020-03-29T22:08:36.1516971+02:00" level=info msg="standalone mode configured" app_id=GamedevFabric instance=Andreas-Desktop scope=dapr.runtime type=log ver=0.5.1
time="2020-03-29T22:08:36.1516971+02:00" level=info msg="dapr id: GamedevFabric" app_id=GamedevFabric instance=Andreas-Desktop scope=dapr.runtime type=log ver=0.5.1
time="2020-03-29T22:08:36.1516971+02:00" level=info msg="mTLS is disabled. Skipping certificate request and tls validation" app_id=GamedevFabric instance=Andreas-Desktop scope=dapr.runtime type=log ver=0.5.1
time="2020-03-29T22:08:36.1556975+02:00" level=info msg="found component statestore (state.redis)" app_id=GamedevFabric instance=Andreas-Desktop scope=dapr.runtime type=log ver=0.5.1
time="2020-03-29T22:08:36.1556975+02:00" level=info msg="found component messagebus (pubsub.redis)" app_id=GamedevFabric instance=Andreas-Desktop scope=dapr.runtime type=log ver=0.5.1
time="2020-03-29T22:08:36.1556975+02:00" level=info msg="application protocol: http. waiting on port 3000" app_id=GamedevFabric instance=Andreas-Desktop scope=dapr.runtime type=log ver=0.5.1
time="2020-03-29T22:08:37.2586963+02:00" level=info msg="application discovered on port 3000" app_id=GamedevFabric instance=Andreas-Desktop scope=dapr.runtime type=log ver=0.5.1
time="2020-03-29T22:08:37.3036962+02:00" level=info msg="application configuration loaded" app_id=GamedevFabric instance=Andreas-Desktop scope=dapr.runtime type=log ver=0.5.1
2020-03-29 22:08:37.303696 I | redis: connecting to localhost:6379
2020-03-29 22:08:37.305698 I | redis: connected to localhost:6379 (localAddr: [::1]:63717, remAddr: [::1]:6379)
time="2020-03-29T22:08:37.3166978+02:00" level=info msg="App is subscribed to the following topics: []" app_id=GamedevFabric instance=Andreas-Desktop scope=dapr.runtime type=log ver=0.5.1
time="2020-03-29T22:08:37.3166978+02:00" level=info msg="Initialized service discovery to standalone" app_id=GamedevFabric instance=Andreas-Desktop scope=dapr.runtime type=log ver=0.5.1
time="2020-03-29T22:08:37.3166978+02:00" level=info msg="actor runtime started. actor idle timeout: 1h0m0s. actor scan interval: 30s" app_id=GamedevFabric instance=Andreas-Desktop scope=dapr.runtime.actor type=log ver=0.5.1
time="2020-03-29T22:08:37.3166978+02:00" level=info msg="starting connection attempt to placement service at localhost:50005" app_id=GamedevFabric instance=Andreas-Desktop scope=dapr.runtime.actor type=log ver=0.5.1
time="2020-03-29T22:08:37.3166978+02:00" level=info msg="enabled metrics grpc middleware" app_id=GamedevFabric instance=Andreas-Desktop scope=dapr.runtime.grpc type=log ver=0.5.1
time="2020-03-29T22:08:37.3166978+02:00" level=info msg="gRPC server is running on port 50001" app_id=GamedevFabric instance=Andreas-Desktop scope=dapr.runtime type=log ver=0.5.1
time="2020-03-29T22:08:37.3166978+02:00" level=info msg="enabled cors http middleware" app_id=GamedevFabric instance=Andreas-Desktop scope=dapr.runtime.http type=log ver=0.5.1
time="2020-03-29T22:08:37.3166978+02:00" level=info msg="enabled proxy http middleware" app_id=GamedevFabric instance=Andreas-Desktop scope=dapr.runtime.http type=log ver=0.5.1
time="2020-03-29T22:08:37.3166978+02:00" level=info msg="enabled metrics http middleware" app_id=GamedevFabric instance=Andreas-Desktop scope=dapr.runtime.http type=log ver=0.5.1
time="2020-03-29T22:08:37.3166978+02:00" level=info msg="http server is running on port 3500" app_id=GamedevFabric instance=Andreas-Desktop scope=dapr.runtime type=log ver=0.5.1
time="2020-03-29T22:08:37.3166978+02:00" level=info msg="local service entry announced" app_id=GamedevFabric instance=Andreas-Desktop scope=dapr.runtime type=log ver=0.5.1
time="2020-03-29T22:08:37.3166978+02:00" level=info msg="dapr initialized. Status: Running. Init Elapsed 1165.0007ms" app_id=GamedevFabric instance=Andreas-Desktop scope=dapr.runtime type=log ver=0.5.1
time="2020-03-29T22:08:39.6246965+02:00" level=warning msg="error establishing client to placement service: rpc error: code = Unavailable desc = connection error: desc = \"transport: Error while dialing dial tcp [::1]:50005: connectex: No connection could be made because the target machine actively refused it.\"" app_id=GamedevFabric instance=Andreas-Desktop scope=dapr.runtime.actor type=log ver=0.5.1
time="2020-03-29T22:08:42.182696+02:00" level=warning msg="error establishing client to placement service: rpc error: code = Unavailable desc = connection error: desc = \"transport: Error while dialing dial tcp [::1]:50005: connectex: No connection could be made because the target machine actively refused it.\"" app_id=GamedevFabric instance=Andreas-Desktop scope=dapr.runtime.actor type=log ver=0.5.1

As a note here, if I start daprd, dapr manually i only use the following:

daprd --app-id "GamedevFabric" --app-port "3000"
dapr run --port 3501 --app-id GamedevFabric --app-port 3000 dotnet run

and I can attach my debugger to it without any problems. The main difference here is that i do not define a placement service address which is done automatically when i use the extension.

This problem might be very well related to my setup, what I'm struggling with is the amount of control i have to fix this through the plugin as I could not find a way to not set a placement-address through configuration (which might be just missing knowledge)

My launch.json:

{
        "name": "Custom Run with Dapr",
        "type": "coreclr",
        "request": "launch",
        "preLaunchTask": "daprd-debug",
        "program": "${workspaceFolder}/GamedevFabric/PlayerService/PlayerActor/bin/Debug/netcoreapp3.1/PlayerActor.dll",
        "args": [],
        "cwd": "${workspaceFolder}/GamedevFabric/PlayerService/PlayerActor",
        "console": "internalConsole",
        "stopAtEntry": false,
        "postDebugTask": "daprd-down"
    }

and my tasks.json

{
            "appId": "GamedevFabric",
            "appPort": 3000,
            "label": "daprd-debug",
            "type": "daprd",
            "dependsOn": "build"
        },
        {
            "appId": "GamedevFabric",
            "label": "daprd-down",
            "type": "daprd-down"
        }

Enable the VS Code Bot for this repo to get automatic issue management (e.g. need-more-info-issue-auto-close) used in our other repos:

https://github.com/apps/vscodebot

Currently the Dapr tab applications tree view will display that no applications are running (when none are detected). However, if Dapr is not actually installed or initialized, we could provide a more accurate warning.

Push any remaining stray package.json text into the localization file, such as the extension description.

We should add the following metadata to our telemetry events:

• In general, whether a command was invoked via the palette or a tree view node context menu.
• For scaffolding, what was the type (i.e. platform/stack) of launch configuration augmented with Dapr tasks.

Add an icon to the application node of the Dapr applications tree view.

For some reason, the "localized" value for the extension description isn't getting resolved when shown in the Marketplace (or in VS Code's extensions gallery), despite being setup the same way as the Docker extension. This looks ugly, though doesn't have any product impact as best I can tell.

While the README will contain an overview of Dapr extension features, we should also have a longer, start-to-finish document in our wiki (to start) that covers taking an application, scaffolding the Dapr assets, and debugging with Dapr (including invoking methods and/or publishing).

Add (localizable) descriptions for each of the configuration properties for the dapr, daprd, and daprd-down custom tasks.

It would be great to be able to invoke & publish through a richer maybe Webview backed UI. It would be slightly nicer to work with and may things like request bodies and formatting responses much easier.

The README.MD should be updated--replacing the scaffolded content with more specific information about the product.

Before too many strings find their way into the product, we should integrate localizability into the product development and build process. We know we'll need it eventually; better to start now.

Now that the extension is public, pre-install the extension in the Dapr Dev Container templates.

dapr run ... will create a set of default Dapr components in the ./components folder on first run to enable standalone use of the Dapr state store and pub/sub. These files are expected when invoking daprd. Currently there is no way to force the creation of these files outside of dapr run (see dapr/cli#234), so our scaffolding should do so (for now).

Currently, the daprd task defaults to localhost:50005 for the placementAddress configuration property. However, if the task is running in a custom Docker network (e.g. a Dev Container), then the placement host is likely not localhost and must therefore be explicitly set in order for a completely successful startup. There is a well-defined environment variable, DAPR_PLACEMENT_HOST, used by the dapr CLI to override the default; the extension daprd task should check this environment variable and, if present, use the value before falling back to localhost.

Have PMs and UX review the color theme and iconography in the extension and update as necessary.

Among the items to review:

• Marketplace icon and gallery banner theme/color
• Dapr tab icon
• Dapr tree view node icons

The initial attempt to localize the extension description (in package.json) did not succeed; it was not resolved when shown in the VS Code extension gallery or on the VS Code Marketplace. We need to investigate why. E.g. is that property actually localizable?

Currently, if the target tasks/configurations created during scaffolding already exist, they will be silently overwritten. The extension should instead better manage those conflicts either by prompting to override and/or using different task/configuration names.

Use webpack to bundle extension assets to reduce VSIX size and improve load performance.