Torizon IDE Extensions Issue Tracker

Description: The IDE 1 is in maintenance mode, and new projects must use the IDE 2. To clarify this with new users, the version 1 is being set as deprecated on the VS Code marketplace, so you don't install it by mistake and start using it on a new project.

Description: As reported on Pyhton app ownership issue, the release Dockerfiles for Python pass the wrong argument to "setup.sh", leading to a wrong app ownership issue.

Description: To make it easier for you to set up your own CI pipeline from a project built with VS Code, we plan to write documentation and create an example.

Update: documentation is available on Visual Studio Code Extension for Torizon - Continuous Integration and Conntinuous Delivery.

Description: If the release image is not available or has never been built, an error is raised. The extensions should ask if the user wants to build a container, instead. If the container exists, ask if the user wants to rebuild it.

Description: When trying to execute the command Torizon: Build release container for the applicationon Qt-based C/C++ projects the source code does not compile, showing the following error: make: *** No rule to make target 'install'. Stop.

Workaround: Workaround: Switching to the release configuration with the command `Torizon C/C++: Switch to release configuration`, executing the default build, deploy and run on debug mode command by pressing `F5` and them running the command `Torizon: Build release container for the application`

Description: Even though support for Qt data types has been added, it doesn't seem to be working as expected in debug mode.

Description: When creating a new C/C++ project of type QT/Widgets, and then trying to run the build, the error "command 'torizon.ccpp.getTargetFolder' not found" happens.

Workaround: This has been addressed and the issue has been fixed.

Description: When trying to build a Python Qt UI project the following error is shown: "Variable ${config:python.pythonPath} can not be resolved because setting 'python.pythonPath' not found."

Description: There was a report that the build_release for Qt-based projects is not working. We will investigate it and, if the bug is confirmed, fix it.

Workaround: You can edit the ".vscode/tasks.json" manually and add the missing property "dependsOn: qmake_release" to the "build_release" task.

Description: This can be fixed by forcing the different controls using during app creation to ignore focus change. The user will have to press ESC to abort project creation.

Description: Add support to Colibri iMX6ULL in the IDE extensions.

Description: Add support to generated Dockerfiles and docker-compose files in the IDE Extensions.

Description: The versions of .NET Core 3 and .NET 6 must be bumped to the latest. This is in preparation for our upcoming stable release.

Description: We have found a high-severity vulnerability in the NPM package simple-get tracked by CVE-2022-0355 when running "npm audit" in our CI pipeline. If you are using the extension V1.3.0, please switch to the latest early access release.

Description: When creating a new ASP.net application, you will see the following error: Internal server error :: Error (500) - 'PlatformConfig' object has no attribute 'init_validation_tables'

Description: When trying to set device_cgroup_rules in the extraparams property, a syntax validation error prevents from proceeding.
If setting up the property as device_cgroup_rule just to be able to continue and after that edit the YAML, another syntax validation error happens when trying to set the rules to \[ "c 199:* rmw" , "c 226:* rmw" ].

Workaround: Edit the property manually inside the file "appconfig_0/config.yaml".

Description: When creating a new volume in the Torizon properties, if the value of the property is set to an absolute path (for example /tmp), the extension will not allow that with the error: "Value does not appear to be a valid relative file path."

Description: Adding the YAML extension required for some projects as a global dependency causes the extension to fail to start inside the development container for C/C++ projects.

Workaround: Update to the latest version of the VS Code extension for Torizon (early access).

Description: To make the user experience with the extensions more reliable, we have introduced input fields validation. With it, file paths with some characters like dot (.) and dash (-) were evaluated as invalid, even though they are actually valid.

Description: A customer reported that when he tries to deploy his application using the VS Code Extension, it was taking way too long. He noticed that each time he tried to build the image, a new appconfig_0 folder would be created inside of the previous one, in a loop-like format. This issue only affects .NET projects.

Description: Currently when developing Qt applications there seems to be a limitation with debugging Qt data types/objects. For example when debugging the value of a `QString`, you'll see basic information like the size of the data, but it won't actually show the value of the string. This is due to Qt implementing somewhat complex data types that can't be easily parsed by GDB. So we should seek to improve the debugging experience for Qt applications, by at least allowing proper debugging of Qt-specific data types, if possible.

Description: If the release image is not available or has never been built, an error is raised. The extensions should ask if the user wants to build a container, instead. If the container exists, ask if the user wants to rebuild it.

Description: The Torizon Platform is envisioned to be an easy-to-use platform for embedded systems. To achieve this goal, Toradex provides the TorizonCore OS as a binary distribution, which means you don't need to build it from source with the Yocto Project, for instance.
To help you customize TorizonCore without having to rebuild the OS, we provide the TorizonCore Builder tool. It is a command-line tool that allows customizing the OS behavior, device tree, splash screen, among other features.
As a further step to improve your end-to-end development experience, we are creating an integration between TorizonCore Builder and the Visual Studio Code Extension for Torizon. This integration will abstract the calls to command-line commands and make it easier and faster to deploy and test your changes to the board, among other benefits.

Learn how to get started on TorizonCore Builder VS Code Integration

Description: The project name specified by the uset is not taken in account by the template that uses dummy-000 as base name.

Workaround: Change the CMakeList.txt files manually and set the exename property to the right file name.

Description: Verdin iMX8M Plus support in the IDE Extensions.

Description: After installing the latest Early Access on Visual Studio Code, every time Visual Studio Code is opened, the user is prompt to accept the NXP EULA.

Description: Using VSCode version 1.55.2 or newer a random invalid device appears in the devices list and features like starting the debugger or creating a new project stop working.

Description: When the extra-parameter "network_mode" is set to "host" the debugger stops working.

Workaround: Issue has been fixed in v1.3.117, available via early access on marketplace.

Description: Our template code does not append a newline after the message, this means that no output is visible in the output terminal until a new line is printed or execution terminates. Since this may be confusing for new users doing step-by-step execution, we should add a line ending to fix the issue.

Description: If a user configured git to convert line ending from the original format to Windows CR+LF this will change the setup.sh and cleanup.sh scripts, generating an error when those are executed in the Linux container during build.

Workaround: Convert startup.sh, cleanup.sh and requirements.txt to unix-style line endings.

Description: the torizon.ccpp.getHostTriplet command that can be used in tasks returns a string that is missing the last character, this can lead to build errors.

Description: This may happen when a device is deleted or when the information is refreshed, the info panel content is not refreshed and may show old information.

Workaround: Click on the object to refresh the information.

Description: In C/C++ projects when changing configuration from arm32 to arm64 or vice-versa the system may not rebuild the final executable (depending on the build system) and this may lead to a wrong exe being executed on the target during debug/release.

Workaround: Manually rebuild application when changing active configuration.

Description: Uno Platform templates integrated into the IDE Extensions.

Description: Fix a change in packages for vivante-imx8 specific libraries that broke the platform template used by the extension.

Description: When exporting a docker-compose file you get the error:

ValueError: too many values to unpack (expected 2)

Description: Using a local Docker registry improves performance and decreases dependencies on external projects.

Description: The IDE extensions should be able to push container image to a registry.

Description: When building an image, during the apt-get update command execution you may get the following error: {code:bash} Release file for http://snapshot.debian.org/archive/debian/20200908T070000Z/dists/bullseye/InRelease is not valid yet (invalid for another 18513d 2h 11min 31s). Updates for this repository will not be applied. {code} When this happens time on the linux/arm platform seem to be set to the wrong date (usually the beginning of unix epoch). You can test this by running a standard debian image: {code:bash} docker run -it --rm --platform linux/arm debian:bullseye-slim Unable to find image 'debian:bullseye-slim' locally bullseye-slim: Pulling from library/debian 5ed966da184b: Pull complete Digest: sha256:6dd2509b000570c24fbf0dd6ea4c907227e36f77b8a7ca2b818464bbff8287dc Status: Downloaded newer image for debian:bullseye-slim root@cb280c464483:/# date Thu Jan 1 00:00:00 UTC 1970 {code}

Workaround: Usually just running the container build multiple times solves the issue. Restarting docker also works, but if you are using VSCode inside a container this will force you to exit the system.

Description: Run "Torizon: Rebuild SDK and reload in container" results in an EPERM error (3).

Description: When debugger is started the project is correctly built and deployed, but then debugger fails to start

Workaround: Add .local as suffix to the device hostname or replace hostname with the device IP address.

Description: When building an image, during the apt-get update command execution you may get the following error: {code:bash} Release file for http://snapshot.debian.org/archive/debian/20200908T070000Z/dists/bullseye/InRelease is not valid yet (invalid for another 18513d 2h 11min 31s). Updates for this repository will not be applied. {code} When this happens time on the linux/arm platform seem to be set to the wrong date (usually the beginning of unix epoch). You can test this by running a standard debian image: {code:bash} docker run -it --rm --platform linux/arm debian:bullseye-slim Unable to find image 'debian:bullseye-slim' locally bullseye-slim: Pulling from library/debian 5ed966da184b: Pull complete Digest: sha256:6dd2509b000570c24fbf0dd6ea4c907227e36f77b8a7ca2b818464bbff8287dc Status: Downloaded newer image for debian:bullseye-slim root@cb280c464483:/# date Thu Jan 1 00:00:00 UTC 1970 {code}

Workaround: Usually just running the container build multiple times solves the issue. Restarting docker also works, but if you are using VSCode inside a container this will force you to exit the system.

Description: No need public description, this is a development issue, we need to update the npm library lodash

Workaround: No need public description, this is a development issue, we need to update the npm library lodash

Description: When a .NET Console project is created using VS Code extension, the program.cs file is not created with the correct indentation

Workaround: Select the block with the incorrect indentation and apply a TAB

Description: The extension registers itself to run inside the container by creating a subfolder in the folder where VSCode keeps its extensions. Unfortunately this path is different between stable and insiders builds and so extension does not run there.

Description: When "network_mode" extraproperty of configuration is set to "host" the container runs in host mode, but debugger can't connect.

Description: When developing a .NET application that is stored in a folder that is not under the user home or is accessible to all users, you get an error when trying to start debugger. On the debug console you can see an error message from SSH complaining about the fact that the permissions for the key file are too open.

Workaround: Move your project under your home folder or change it's access rights to make it accessible only from your user.

Description: An error was causing a weird behavior in the appconfig_0 folder of the VSCode plugin.

Description: On Windows 10 Home and WSL 2, when deploying to a device, the following error occurs several times: "Error (545) - Can't find a valid IP for board name". NOTE: Windows 10 Home and WSL 2 are not supported at the moment.

Workaround: Retry to deploy (press F5 for instance) until it works. It may work on 1 out of 10 tries.

Description: 64-bit .NET Core container does not work

Description: When a C/C++ project is opened inside a container on VS Code - which is common - it is not possible to enable ARM emulation. This is because ARM emulation must be enabled on the host.

Workaround: Either (1) close the remote container and run the command again or (2) run the command from the command-line.

Description: The EnvironmentName on an ASP.NET project is being defined as Production even if you are developing in Debug Mode.

Update: there are no plans to fix this potential bug, because it is considered a configuration issue. A potential fix might adversely impact other customers' projects.

Workaround: Add the following line to your project's ".vscode/launch.json" file:

"env": { "ASPNETCORE_ENVIRONMENT": "Development" },

Description: An end-user has a specific application that uses WebSockets to connect back to a PC running a standalone application. When running their app in a container manually on the target, the connections to the PC go through. However, when debugging their app from within the IDE extension, those connections are never seen by the PC.

Update: this task has been rejected because the issue was on misuse of "System.Net.WebSockets". As general advice, if you face a similar issue, and you can use a library that provides a higher level of abstraction, that might help prevent such type of error.

Description: Running version 1.4.271 of the IDE extension under VSCode for Windows, a customer trying to deploy a .NET Core console “hello world” app gets a popup that “The pipe program ‘ssh’ exited unexpectedly with code 255.”

Starting: "ssh" -T -p %{port} -i %{keypath} -o StrictHostKeyChecking=no -o "UserKnownHostsFile /dev/null" %{devicelogin} "/vsdbg/vsdbg --interpreter=vscode"
Error from pipe program 'ssh': Bad port '%{port}'
The pipe program 'ssh' exited unexpectedly with code 255.

Description: Currently, when exporting a Docker Compose file, the default name is "# docker-compose.yml", but sometimes it is reported by users that the file name defaults to whatever name of the directory you plan to save it to.

Workaround: Rename your file before saving it for the first time. If you have already saved it with the wrong name, rename the file to your liking.

Description: It was only possible to reproduce it in the case that the tag parameter was set as "" instead of "/". But this is not a bug, as the proper way to push images to Dockerhub (or another registry) is by using the tag as "/".

Refer to the Docker tag reference for more information.

Description: As of now, the IDE extensions provide a field name "extraparams" that allows users to pass extra arguments to the Docker calls when running a container. Those extra arguments are expected in the Docker Python API syntax, since it is the same API used by Moses, the IDE back-end.

This is a bit confusing, since everywhere else in our documentation we use the command-line syntax instead. Therefore, to bridge this gap, we are introducing a configuration field named "dockercmdline" that has the same purpose as "extraparams" but accepts the command-line syntax instead of the Python API syntax.

Workaround: Use "extraparams" with the Docker Python API syntax

Description: In the VS Code IDE Extension info panel, some memory numbers are presented in full, instead of using engineering notation (for example kB, MB, GB, etc.). This makes it hard to read those numbers.

Description: It's possible to fix the issue by configuring a custom port in launch.json (replacing the ${port} entry) and by adding to buildcommands a command that changes it in sshd configuration.

Description: A customer with 7 keys in their SSH agent has reported that the IDE Extension fails to connect to the board with the error "Received disconnect from 192.168.17.89 port 22:2: Too many authentication failures".

Workaround: Some SSH servers have a configurable option for the number of authentication failures before it throws an error. To overcome that, you may either (1) change the config to a bigger number or (2) remove some keys from your agent.

Description: When exporting a docker-compose.yml using the VS Code extension, the "cap_add" field is formatted in a way that makes the YML file invalid. This required manual intervention to fix the file syntax after exporting it.
There are many scenarios where you'd need to set the "cap_add" field. One of them would be to configure the container to use the host network, required for using the CAN on TorizonCore.

Workaround: Manually fix the syntax issue.

Description: When opening a project that has no SDK container the tool should prompt for a rebuild. Unfortunately this does not happen 100% of the times.

Workaround: Rebuild SDK container manually when re-opening the project on a different machine or after having removed containers from your development machine.