I am working through the Quickstart Guide for Colibri iMX6, Colibri Evaluation Board, Computer on Module OS Torizon, Development PC OS Windows.
I do have Win10 Version 1909 (OS Build 18363.1316). I managed to set up WSL2, DockerDesktop and “Toradex Torizon C/C++ Support” in VS2019 Pro 16.8.4.
Now, I open the “Torizon Devices” Window. I could add my Colibri by typing the IP address.
However, the solution created according to the Quickstart Guide does not correctly build.
first question: If in VS2019 window Torizon Devices I click the “Detect device on the network” icon and then button Detect, after some time, a window with an error message appears “Error during device detection: OS error: [Errno None] Unable to connect to port 22 on 169.254.64.157, 172.17.155.177” and some more IP addresses also in IPV6 format. The working Colibri address is 192.168.0.15. Why can the autodetect feature not detect the attached working Colibri?
second question: in VS2019, per default the new solution is set to Platform=x64. Is this the correct Platform for creating a container for execution on the Colibri? If I switch to Platform=ARM, sometimes the Platform automatically switches again to x64. I also noted that in the VisualStudio printscreens in the QuickStart Guide the Platform setting is not consistent.
third question: when building the solution the status line reports “Build succeeded” but in the Output window the exception message is displayed:
*Error running SDK container.
Code: 500
Description: Internal server error
Message: 500 Server Error: Internal Server Error (“b’Ports are not available: listen tcp 0.0.0.0:49153: bind: An attempt was made to access a socket in a way forbidden by its access permissions.'”)
Error starting SDK container.
Backend service and docker are up and running, enabling Torizon features.
Error loading Torizon application configuration.
Exception: System.NullReferenceException: Object reference not set to an instance of an object.
at TorizonVSExtension.CPPSolutionManager.d__55.MoveNext() in C:\GitLab-Runner\builds\sAyebikf\0\rd\torizon-core\ide-plugins\vs-plugin\TorizonVSExtension\CPPProjects\CPPSolutionManager.cs:line 1039
— End of stack trace from previous location where exception was thrown —
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at TorizonVSExtension.CPPSolutionManager.d__54.MoveNext() in C:\GitLab-Runner\builds\sAyebikf\0\rd\torizon-core\ide-plugins\vs-plugin\TorizonVSExtension\CPPProjects\CPPSolutionManager.cs:line 1022
Message:Object reference not set to an instance of an object.
Stack trace:
at TorizonVSExtension.CPPSolutionManager.d__55.MoveNext() in C:\GitLab-Runner\builds\sAyebikf\0\rd\torizon-core\ide-plugins\vs-plugin\TorizonVSExtension\CPPProjects\CPPSolutionManager.cs:line 1039
— End of stack trace from previous location where exception was thrown —
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at TorizonVSExtension.CPPSolutionManager.d__54.MoveNext() in C:\GitLab-Runner\builds\sAyebikf\0\rd\torizon-core\ide-plugins\vs-plugin\TorizonVSExtension\CPPProjects\CPPSolutionManager.cs:line 1022
Error loading application configuration.*
Is this expected behaviour? Or should I not use Build from the solution/project context menu but only use Torizon Toolbar icons?
fourth question: when selecting the “TorizonApp1 (Linux)” project and clicking the “Build Torizon Application” on the Torizon Toolbar, in the Error List window the text “Could not reconnect to the remote system. Please verify your connection settings, and that your machine is on the network and reachable.” The Platform is switched to x64 automatically. The Torizon Devices window shows the Colibri and Refresh works OK. Why no connection?
fifth question: the window did never appear after creating a new solution as supposed in the QuickStart Guide. Is this a VS2019 Pro issue?
sixth question: in the VS2019 project properties for TorizonApp1 (Linux), what should I set for Configuration Properties - Debugging - Remote Debug Machine? Currently, it is" Remote GDB Debugger, 127.0.0.1 (username=build, port=49153, authentication=Password)". In Configuration Properties - Torizon ARM C/C++ Application the correct Target device is shown.
Let me answer your questions one by one here. Though let me start out by saying that I was unable to reproduce this issue on my side. However I am using the community edition of VS, but then again this really shouldn’t make a difference.
first question
Not sure if I understood you here correctly, you can or can’t add a Torizon device? You initially said you could. Also “autodetect” feature. I’m not sure if I follow you correctly. If you add a device by detecting via network you always need to explicitly provide either an IP address or hostname.
second question
Long story short you should never need to manually change the platform setting. The extension should handle all the cross-platform configurations and settings.
third question
This error log appears to be the bulk of your build issues. Our extension creates an SDK container via Docker it’s in this container that your application gets built as specified. Though for whatever reason as the logs states there’s issues trying to run this SDK container. Just going off the logs it seems some ports that are used for communication are being blocked possibly. Do you have any network restrictions/firewalls that may be responsible for this? The backend process for the extension is called moses.exe so if you see an such process being blocked you should allow it. Also regarding the Torizon tool bar, it’s recommended to use this for building/interacting with your project.
Though this is just a theory and we may need more logs to debug this. One thing you can do is turn on the debug Window for our extension. This can be done by going to Visual Studio and, Tools > Options > Torizon > Show backend console > True. Once that has been set and applied, restart Visual Studio. You may also need to end the moses.exe process via task manager for this change to take effect. But once applied and restarted there should now be a command prompt window that shows all the API calls made by our extension. Can you please run through the quickstart guide with this Window open, up until you experience the build error. Then can you copy and paste the logs back to me here.
fourth question
This goes back to my answer on the third question where there might be some network configuration or firewall that is blocking communications from the extension. Again if you could activate the debug window and get the logs from that it would help.
fifth question
I assume this window never appears because the build process errors out before it reaches this point.
sixth question
This isn’t something you should need to set yourself manually. The extension should configure this for you. Unless the quickstart/documentation says you need to configure something it’s best to leave any unmentioned configurations untouched.
So yes please provide me with the logs from the debug window I mentioned and then we can have a better chance at debugging your build issues.
Backend console is a good clue. Here is the output:
Serving on http://vmware-localhost:5000
INFO:root:REST -> /api/version/docker
INFO:root:REST <- /api/version/docker - 200
INFO:root:REST -> /api/eulas
INFO:root:REST <- /api/eulas - 200
INFO:root:REST -> /api/platforms
INFO:root:REST <- /api/platforms - 200
INFO:root:REST -> /api/applications/create
processed file: C:\TMP\Torizon\TorizonApp1\appconfig_0\id_rsa
Successfully processed 1 files; Failed processing 0 files
processed file: C:\TMP\Torizon\TorizonApp1\appconfig_0\id_rsa
Successfully processed 1 files; Failed processing 0 files
processed file: C:\TMP\Torizon\TorizonApp1\appconfig_0\id_rsa
Successfully processed 1 files; Failed processing 0 files
INFO:root:REST <- /api/applications/create - 200
INFO:root:REST -> /api/applications/37115a69-cdbd-48f0-b312-0b057ebf34ed
WARNING:root:REST - Attempt to change value of property images
WARNING:root:REST - Attempt to change value of property sdkimages
INFO:root:REST <- /api/applications/37115a69-cdbd-48f0-b312-0b057ebf34ed - 200
INFO:root:REST -> /api/applications/load
INFO:root:REST <- /api/applications/load - 200
INFO:root:REST -> /api/platforms
INFO:root:REST <- /api/platforms - 200
INFO:root:REST -> /api/applications/37115a69-cdbd-48f0-b312-0b057ebf34ed/sdk/run
ERROR:root:Error: 520 Container image not found on local host. Image torizonapp1_arm32v7-debian_bullseye_debug_37115a69-cdbd-48f0-b312-0b057ebf34ed_sdk_image is not available.
INFO:root:REST <- /api/applications/37115a69-cdbd-48f0-b312-0b057ebf34ed/sdk/run - 520
INFO:root:REST -> /api/version/docker
INFO:root:REST <- /api/version/docker - 200
INFO:root:REST -> /api/devices
INFO:root:REST <- /api/devices - 200
INFO:root:REST -> /api/devices/05087470
INFO:root:REST <- /api/devices/05087470 - 200
INFO:root:REST -> /api/devices/05087470/images
INFO:root:SSH - Creating tunnel to 05087470
2021-01-29 08:54:25,831| ERROR | Could not establish connection from ('127.0.0.1', 49965) to remote side of the tunnel
ERROR:sshtunnel.SSHTunnelForwarder:Could not establish connection from ('127.0.0.1', 49965) to remote side of the tunnel
INFO:root:SSH - Creating tunnel to 05087470
2021-01-29 08:54:27,091| ERROR | Could not establish connection from ('127.0.0.1', 49968) to remote side of the tunnel
ERROR:sshtunnel.SSHTunnelForwarder:Could not establish connection from ('127.0.0.1', 49968) to remote side of the tunnel
INFO:root:SSH - Creating tunnel to 05087470
WARNING:paramiko.transport:Success for unrequested channel! [??]
WARNING:paramiko.transport:Success for unrequested channel! [??]
INFO:root:SSH - Tunnel to 05087470 activated
INFO:root:REST <- /api/devices/05087470/images - 200
INFO:root:REST -> /api/devices/05087470/containers
INFO:root:REST <- /api/devices/05087470/containers - 200
INFO:root:REST -> /api/devices/05087470/processes
INFO:root:SSH - Connecting to device 05087470
INFO:root:SSH - Connected to device 05087470
INFO:root:REST <- /api/devices/05087470/processes - 200
INFO:root:REST -> /api/devices/05087470/storage
INFO:root:REST <- /api/devices/05087470/storage - 200
INFO:root:REST -> /api/devices/05087470/memory
INFO:root:REST <- /api/devices/05087470/memory - 200
INFO:root:REST -> /api/devices/05087470
INFO:root:REST <- /api/devices/05087470 - 200
INFO:root:REST -> /api/devices/05087470/images
INFO:root:REST <- /api/devices/05087470/images - 200
INFO:root:REST -> /api/devices/05087470/containers
INFO:root:REST <- /api/devices/05087470/containers - 200
INFO:root:REST -> /api/devices/05087470/processes
INFO:root:REST <- /api/devices/05087470/processes - 200
INFO:root:REST -> /api/devices/05087470/storage
INFO:root:REST <- /api/devices/05087470/storage - 200
INFO:root:REST -> /api/devices/05087470/memory
INFO:root:REST <- /api/devices/05087470/memory - 200
Apparently it cannot find container image torizonapp1_arm32v7-debian_bullseye_debug_37115a69-cdbd-48f0-b312-0b057ebf34ed_sdk_image, I can see in DockerDesktop there are two images running, but not this exact required image (see printscreen)
[upload|jVr9cajTlBif4ALFySTUTM+w2CA=]
In VS2019Pro, the Torizon Build output is:
SDK container hasn't been built yet, this may prevent intellisense and auto-completion from working. It will work after a rebuild of the application.
Error starting SDK container.
The traget hardware seems to work correctly, the Torizon Devices shows:
[upload|PaKkyF2EKtEcjM90eWnUNBycsmc=]
Thank you for providing the logs. I had someone from our IDE team take a look at all the logs you’ve provided. What was most concerning to them was actually in your original message:
Message: 500 Server Error: Internal
Server Error (“b’Ports are not
available: listen tcp 0.0.0.0:49153:
bind: An attempt was made to access a
socket in a way forbidden by its
access permissions.'”)
This would indicate that some communications from our extension are being blocked which might cause other parts of the extension to not work correctly. Could you please check if there’s any firewalls or network restrictions that may cause this? The backend process for our extension is called “moses.exe”.
You were right, the main problem is firewall and antivirus software running on the laptop.
I can build and deploy an application now on a laptop with only Windows Defender Firewall installed. The firewall got inbound rules for Docker Desktop Backend and moses. Unfortunately firewall and antivirus is managed by another department of our company so it takes a while for a minor change.
I would like there were a listing of Windows Defender Firewall of ports and protocols I could hand-over to the ICT department.
In addition, while building the Torizon application I recognized a temporary batch file, for example C:\TMP\tmpddebc95cdae544d99e521417e43e25b7.exec.cmd. Is there a way to redirect this file to another directory?
Is the exception “The given key was not present in the dictionary” in the build output an error or just an info?
Loading application configuration...
Loading application configuration...
Deployment started...
Loading application configuration...
Device is not configured in project properties, prompting user to select a device.
Checking container state...
Deploying and starting remote container (it may take some time after a build or the first time you connect to a device)...Image not found on target device.
Exporting local image.
Image exported, deploying to the target.
Loading layer - 22f6502754e1
Loading layer - 22f6502754e1
Loading layer - 7c36f09225a9
Loading layer - 7c36f09225a9
Loading layer - 7c36f09225a9
Loading layer - 7c36f09225a9
Loading layer - 7c36f09225a9
Loading layer - 7c36f09225a9
Loading layer - 7c36f09225a9
Loading layer - 7c36f09225a9
Loading layer - 7c36f09225a9
Loading layer - 7c36f09225a9
Loading layer - 7c36f09225a9
Loading layer - 7c36f09225a9
Loading layer - 7c36f09225a9
Loading layer - 7c36f09225a9
Loading layer - 7c36f09225a9
Loading layer - 7c36f09225a9
Loading layer - 7c36f09225a9
Loading layer - 7c36f09225a9
Loading layer - 7c36f09225a9
Loading layer - 7c36f09225a9
Loading layer - 7c36f09225a9
Loading layer - 7c36f09225a9
Loading layer - 7c36f09225a9
Loading layer - 7c36f09225a9
Loading layer - 7c36f09225a9
Loading layer - 7c36f09225a9
Loading layer - 7c36f09225a9
Loading layer - 7c36f09225a9
Loading layer - 7c36f09225a9
Loading layer - 7c36f09225a9
Loading layer - 7c36f09225a9
Loading layer - 7c36f09225a9
Loading layer - 7c36f09225a9
Loading layer - 7c36f09225a9
Loading layer - 7c36f09225a9
Loading layer - 7c36f09225a9
Loading layer - 7c36f09225a9
Loading layer - 7c36f09225a9
Loading layer - 7c36f09225a9
Loading layer - 7c36f09225a9
Loading layer - 7c36f09225a9
Loading layer - 7c36f09225a9
Loading layer - 7c36f09225a9
Loading layer - 7c36f09225a9
Loading layer - 7c36f09225a9
Loading layer - 7c36f09225a9
Loading layer - 7c36f09225a9
Loading layer - 7c36f09225a9
Loading layer - 7c36f09225a9
Loading layer - 7c36f09225a9
Loading layer - 7c36f09225a9
Loading layer - 7c36f09225a9
Loading layer - 7c36f09225a9
Loading layer - 7c36f09225a9
Loading layer - 7c36f09225a9
Loading layer - 7c36f09225a9
Loading layer - 7c36f09225a9
Loading layer - 7c36f09225a9
Loading layer - 7c36f09225a9
Loading layer - 7c36f09225a9
Loading layer - 7c36f09225a9
Loading layer - 7c36f09225a9
Loading layer - 7c36f09225a9
Loading layer - 7c36f09225a9
Loading layer - 7c36f09225a9
Loading layer - 7c36f09225a9
Loading layer - 7c36f09225a9
Loading layer - 7c36f09225a9
Loading layer - 7c36f09225a9
Loading layer - 7c36f09225a9
Loading layer - 7c36f09225a9
Loading layer - 7c36f09225a9
Loading layer - 7c36f09225a9
Loading layer - 7c36f09225a9
Loading layer - 7c36f09225a9
Loading layer - 7c36f09225a9
Loading layer - 7c36f09225a9
Loading layer - 7c36f09225a9
Loading layer - 7c36f09225a9
Loading layer - 7c36f09225a9
Loading layer - 7c36f09225a9
Loading layer - 7c36f09225a9
Loading layer - 7c36f09225a9
Loading layer - 7c36f09225a9
Loading layer - 7c36f09225a9
Loading layer - 7c36f09225a9
Loading layer - 7c36f09225a9
Loading layer - 7c36f09225a9
Loading layer - 7c36f09225a9
Loading layer - 7c36f09225a9
Loading layer - 7c36f09225a9
Loading layer - 7c36f09225a9
Loading layer - 7c36f09225a9
Loading layer - 7c36f09225a9
Loading layer - 7c36f09225a9
Loading layer - 7c36f09225a9
Loading layer - 7c36f09225a9
Loading layer - 7c36f09225a9
Loading layer - 7c36f09225a9
Loading layer - 7c36f09225a9
Loading layer - 7c36f09225a9
Loading layer - 7c36f09225a9
Loading layer - 7c36f09225a9
Loading layer - 7c36f09225a9
Loading layer - beea2beaba56
Loading layer - beea2beaba56
Loading layer - 683dc12275c4
Loading layer - 683dc12275c4
Loading layer - 8dd5826ebb9e
Loading layer - 8dd5826ebb9e
Loading layer - 8dd5826ebb9e
Loading layer - 8dd5826ebb9e
Loading layer - 8dd5826ebb9e
Loading layer - 8dd5826ebb9e
Loaded image ID: sha256:b9cce0ed5f233a1eba2f3d0e60561b678da53c079452ca4538693635c98c63df
Image deployed.
Done
running startup script...
Starting new instance...
Done
Configuring project...
Error configuring remote debugging target
Exception: System.Collections.Generic.KeyNotFoundException: The given key was not present in the dictionary.
at System.Collections.Generic.Dictionary`2.get_Item(TKey key)
at TorizonVSExtension.CPPSolutionManager.<InternalDeployAsync>d__50.MoveNext() in C:\GitLab-Runner\builds\sAyebikf\0\rd\torizon-core\ide-plugins\vs-plugin\TorizonVSExtension\CPPProjects\CPPSolutionManager.cs:line 743
Message:The given key was not present in the dictionary.
Stack trace:
at System.Collections.Generic.Dictionary`2.get_Item(TKey key)
at TorizonVSExtension.CPPSolutionManager.<InternalDeployAsync>d__50.MoveNext() in C:\GitLab-Runner\builds\sAyebikf\0\rd\torizon-core\ide-plugins\vs-plugin\TorizonVSExtension\CPPProjects\CPPSolutionManager.cs:line 743
sending incremental file list
created directory /home/torizon//TorizonApp1
main.cpp
bin/
bin/ARM/
bin/ARM/Debug_debian_arm32v7_bullseye/
bin/ARM/Debug_debian_arm32v7_bullseye/TorizonApp1.out
bin/x64/
bin/x64/Debug_debian_arm32v7_bullseye/
bin/x64/Debug_debian_arm32v7_bullseye/TorizonApp1.out
obj/
obj/ARM/
obj/ARM/Debug_debian_arm32v7_bullseye/
obj/ARM/Debug_debian_arm32v7_bullseye/main.o
obj/x64/
obj/x64/Debug_debian_arm32v7_bullseye/
obj/x64/Debug_debian_arm32v7_bullseye/main.o
sent 7,176 bytes received 208 bytes 4,922.67 bytes/sec
total size is 40,161 speedup is 5.44
Done
Application container is up and running, connection configuration has been updated.
Application has been deployed.
Loading application configuration...
Deployment started...
Loading application configuration...
Device is not configured in project properties, prompting user to select a device.
Checking container state...
Deploying and starting remote container (it may take some time after a build or the first time you connect to a device)...Image on target is already up to date.
Done
Stopping current instance...
running startup script...
Starting new instance...
Done
Configuring project...
Error configuring remote debugging target
Exception: System.Collections.Generic.KeyNotFoundException: The given key was not present in the dictionary.
at System.Collections.Generic.Dictionary`2.get_Item(TKey key)
at TorizonVSExtension.CPPSolutionManager.<InternalDeployAsync>d__50.MoveNext() in C:\GitLab-Runner\builds\sAyebikf\0\rd\torizon-core\ide-plugins\vs-plugin\TorizonVSExtension\CPPProjects\CPPSolutionManager.cs:line 743
Message:The given key was not present in the dictionary.
Stack trace:
at System.Collections.Generic.Dictionary`2.get_Item(TKey key)
at TorizonVSExtension.CPPSolutionManager.<InternalDeployAsync>d__50.MoveNext() in C:\GitLab-Runner\builds\sAyebikf\0\rd\torizon-core\ide-plugins\vs-plugin\TorizonVSExtension\CPPProjects\CPPSolutionManager.cs:line 743
sending incremental file list
created directory /home/torizon//TorizonApp1
main.cpp
bin/
bin/ARM/
bin/ARM/Debug_debian_arm32v7_bullseye/
bin/ARM/Debug_debian_arm32v7_bullseye/TorizonApp1.out
bin/x64/
bin/x64/Debug_debian_arm32v7_bullseye/
bin/x64/Debug_debian_arm32v7_bullseye/TorizonApp1.out
obj/
obj/ARM/
obj/ARM/Debug_debian_arm32v7_bullseye/
obj/ARM/Debug_debian_arm32v7_bullseye/main.o
obj/x64/
obj/x64/Debug_debian_arm32v7_bullseye/
obj/x64/Debug_debian_arm32v7_bullseye/main.o
sent 7,187 bytes received 208 bytes 4,930.00 bytes/sec
total size is 40,169 speedup is 5.43
Done
Application container is up and running, connection configuration has been updated.
Application has been deployed.
Loading application configuration...
Deployment started...
Loading application configuration...
Device is not configured in project properties, prompting user to select a device.
Checking container state...
Deploying and starting remote container (it may take some time after a build or the first time you connect to a device)...Image on target is already up to date.
Done
Stopping current instance...
running startup script...
Starting new instance...
Done
Configuring project...
Error configuring remote debugging target
Exception: System.Collections.Generic.KeyNotFoundException: The given key was not present in the dictionary.
at System.Collections.Generic.Dictionary`2.get_Item(TKey key)
at TorizonVSExtension.CPPSolutionManager.<InternalDeployAsync>d__50.MoveNext() in C:\GitLab-Runner\builds\sAyebikf\0\rd\torizon-core\ide-plugins\vs-plugin\TorizonVSExtension\CPPProjects\CPPSolutionManager.cs:line 743
Message:The given key was not present in the dictionary.
Stack trace:
at System.Collections.Generic.Dictionary`2.get_Item(TKey key)
at TorizonVSExtension.CPPSolutionManager.<InternalDeployAsync>d__50.MoveNext() in C:\GitLab-Runner\builds\sAyebikf\0\rd\torizon-core\ide-plugins\vs-plugin\TorizonVSExtension\CPPProjects\CPPSolutionManager.cs:line 743
sending incremental file list
created directory /home/torizon//TorizonApp1
main.cpp
bin/
bin/ARM/
bin/ARM/Debug_debian_arm32v7_bullseye/
bin/ARM/Debug_debian_arm32v7_bullseye/TorizonApp1.out
bin/x64/
bin/x64/Debug_debian_arm32v7_bullseye/
bin/x64/Debug_debian_arm32v7_bullseye/TorizonApp1.out
obj/
obj/ARM/
obj/ARM/Debug_debian_arm32v7_bullseye/
obj/ARM/Debug_debian_arm32v7_bullseye/main.o
obj/x64/
obj/x64/Debug_debian_arm32v7_bullseye/
obj/x64/Debug_debian_arm32v7_bullseye/main.o
sent 7,179 bytes received 204 bytes 4,922.00 bytes/sec
total size is 40,161 speedup is 5.44
Done
Application container is up and running, connection configuration has been updated.
Application has been deployed.
Loading application configuration...
Deployment started...
Loading application configuration...
Device is not configured in project properties, prompting user to select a device.
Checking container state...
Deploying and starting remote container (it may take some time after a build or the first time you connect to a device)...Image on target is already up to date.
Done
Stopping current instance...
running startup script...
Starting new instance...
Done
Configuring project...
Error configuring remote debugging target
Exception: System.Collections.Generic.KeyNotFoundException: The given key was not present in the dictionary.
at System.Collections.Generic.Dictionary`2.get_Item(TKey key)
at TorizonVSExtension.CPPSolutionManager.<InternalDeployAsync>d__50.MoveNext() in C:\GitLab-Runner\builds\sAyebikf\0\rd\torizon-core\ide-plugins\vs-plugin\TorizonVSExtension\CPPProjects\CPPSolutionManager.cs:line 743
Message:The given key was not present in the dictionary.
Stack trace:
at System.Collections.Generic.Dictionary`2.get_Item(TKey key)
at TorizonVSExtension.CPPSolutionManager.<InternalDeployAsync>d__50.MoveNext() in C:\GitLab-Runner\builds\sAyebikf\0\rd\torizon-core\ide-plugins\vs-plugin\TorizonVSExtension\CPPProjects\CPPSolutionManager.cs:line 743
Glad we were able to get to the root of the issue.
I would like there were a listing of
Windows Defender Firewall of ports and
protocols I could hand-over to the ICT
department.
This is actually a good idea, I’ll see if we can document this publicly for everyone’s sake.
In addition, while building the
Torizon application I recognized a
temporary batch file, for example
C:\TMP\tmpddebc95cdae544d99e521417e43e25b7.exec.cmd.
Is there a way to redirect this file
to another directory?
I’m not sure what this tmp file is I’ll need to check, but I assume it’s location is generated by the extension backend itself. Therefore I’m not sure if redirecting it is something that can be done without changing the backend itself. What is the reason you’d want to change the location of this tmp file by the way?
Is the exception “The given key was
not present in the dictionary” in the
build output an error or just an info?
Just to make sure I understand, this exception appears in the logs but the process goes well anyways? Does the exception seem to affect anything at all?
The reason for changing the directory of the script is to allow executables from a certain directory (security reasons). As it is now, we have to allow *.cmd in the TMP directory. Things were different if the script always had the same filename, then TMP would be ok
I do not notice any effects caused by the exception reported in the log
I spoke with the team about that temp file, and as far as they know our extension shouldn’t be generating such files. At least directly it doesn’t generate any in the TMP directory.
Could you please share the contents of one of these temp files? So that we can determine what it is and maybe what is generating it.
did never appear after creating a new solution as supposed in the QuickStart Guide. Is this a VS2019 Pro issue?