VsCode Assistant Maker extension – Dynamics 365 Business Central Community

In VScode standard you can setup tasks. For developers is very usual to execute automated jobs with command lines. For this purpose, you can launch these commands from Terminal panel in the bottom of VSCode window:

A step beyond is take a very repetitive command and create a VSCode task to set this command and execute it without writing it over and over. I use them to execute shell, and PowerShell scripts. There is an excellent introduction to VSCode tasks in this site: Tasks in Visual Studio Code I didn´t do it, but tasks can also be chained with other tasks.

Standard VSCode tasks bring to my head another idea: make a task definitor, but not only for shell execution, but also for execute other extension commands, open documents to review and modify them, and open folders and web sites to check their content. I thought about that because I needed these features, as we will see in use case below.

When I finished working with a VSCode app developing work, I always follow a set of steps, that can be different depending on type of application, App Source target, per-tenant, a utility, etc. An example of this set of steps, could be these bellow:

  • Delete previous .app file, in my local workspace.
  • Open app.json file to increase version number.
  • Create the package, invoking extension command F1+“AL Package”.
  • Execute my translations extension, with extension command F1+JAM Executes translations steps.
  • Review pending translations in the remaining translations csv file. Open a csv file to review it, and check that the translations are OK.
  • Generate translations again, invoking the same previous extension command.
  • Generate package again with translations. Another extension command as well as previous step.
  • Copy the app to a shared folder. Execute a shell to copy app file from my workspace to another folder.
  • Commit Git. Execute Git extension command
  • Push to Git. Execute another Git extension command (Push).
  • Launch a PowerShell script to sign the application. Execute a shell.
  • Copy the App from my local workspace to net shared folder. This way will be accessible for consultants. Execute a shell.
  • Open shared app folder. Open the target folder of app copy to check all is OK.

So. What do we need?

Extracting common factors for all these steps, we get four kind of actions:

  • Execute a task or shell statement: in the use case, delete my local workspace .app file, copy it to a folder, execute a PowerShell script.
  • Open documents to review or modify, as we do in the step to increase the version in app.json or translation review.
  • Execute a command extension as GIT Commit, GIT push, my own translation extension or AL package command.
  • Open an external folder or URL to check there the copies, deletes or even open AppSource URL to begin version publishing process.

I think this is very similar to pipelines in DevOps, but slightly different, because DevOps work begin when you exit form VSCode. This automatization is for finish the inside VSCode work.

  • Define some steps in chain that performs a task execution, an extension command, open a document or review a folder or URL address.
  • Execute these tasks with a visual assistant, with the classic Next button.

You can see how to create the json file for step definition and how to execute the assistant in extension README, by I will introduce it with a simple example.

A simple hello world of this extension would be the step definition for repetitive actions to release a new version of a per tenant app. This a simplification of all the steps I use to define to finish this task but is a good “hello world”, with all kind of steps, execute a shell, an extension command, open a document and open an external element as a folder:

  • Delete my local workspace app file to recreate with a newer version number.
  • Open app.json to set a newer version number.
  • Recreate app with AL extension command “AL: Package”.
  • Copy the app file to a shared folder this way the team can take it.
  • Open the shared folder bellow to check the copy is alright.

So let´s do the assistant json file to set this features. For this purpose, we have two snippets, TJAMInitStepFile to create the scaffolding of the entire file, and TJAMScriptStep for help in the making of the single step:

So, this way ,make step 1, delete local app file, to rebuilt it in a further step:

“Description”: “Delete current app file”,}

{scriptExecType: executeCommandShell},

{scriptArgument: “del *.app”

The value ofscriptExecType“is”executeCommandShell“. That means that we will write in “scriptArgumentis a shell statement. I makeexecuteCommandShellafter create “task” option. We could think that these two options are the same but have a difference: with the task we have to make a VSCODE definition and write its name in the argument definition. With the other option “executeCommandShell”, you write directly the shell command to execute. In argument definition of all others “ScriptExecType“ options, we have some help with”tselArguments“snippet. This snippet helps us to select an argument depending on step type, we will see on the further steps of the “hello word” example. The only help in the command shell option is the snippet”tpowerShellExcution”, that helps us to write a shell execution of a PowerShell file. I thought this could bring us stronger possibilities of execution.

In the setp 2 we want to open the app.json to increase released number:

We typeTJAMScriptStep“and set”scriptExectype to “OpenDocument”. In the scriptArgument value we can select a file with a file dialog with the snippetTselArguments“.

In the step we want to package again the app, with the release version settled in app.json. Again, we type “TJAMScriptStep” snippet, and set in ”scriptExecType” “extensionCommand” but in tselArguments snippet we will see a different behavior that previous step. Now the snippet will deploy a multiple choice of all extension commands available:

The next step is copy generated app file to a shared folder. This is a repetitive stuff from step 1, when we did delete of app file excutin a shell, so I will not put a gif to this step, only the final step result:

{“Description”: “Copy app file to share folder”},

{scriptExecType: executeCommandShell},

{scriptArgument: “copy *.app C:/Shared/”}

The final step is open the target folder to check everything is ok. Maybe does not make a lot of sense, but for didactical purposes of the step definition is interesting to show the last kind of exec type, “Open External”. This kind of step open a URL address or a folder, and “tselArgumentsA snippet in this case will show us a folder selection dialog to pick the target folder to open:

{“Description”: “Open target folder”},

{scriptExecType: openExternal},

{scriptArgument: “c:/Shared”}

We have the final result in .json definition file, and we can execute this script with “JAM: Execute current VsCode Script” command, going with F1 to command palette:

This tool helps me to remember all the steps for repetitive task sequences and execute them in an easy assistant. The tool can cover scenarios that you do not want, or you can´t, using pipelines with Devops.

Also for me is important technologies and concepts I played with to do that. The extension has two additional tools, load a .json file in a tree view and discover commands in all installed extensions, even commands not visible with VSCode command palette. In a further post I will explain these two features and breakdown how I did them.

Leave a Comment