I am having problems building a C++ application under VS 2019, following the steps under
Build and Run your First C Application
This sounds similar to the problem at Cannot build Visual Studeo 2019 project for the very first time with Torizon extension - Technical Support - Toradex Community , but my configuration is different, and some symptoms are different.
I am using Microsoft Visual Studio Community 2019, Version 16.8.2. On the MX8 board, my /etc/os-release file is:
ID=torizon
NAME=“TorizonCore”
VERSION=“5.1.0-devel-202011+build.4 (dunfell)”
VERSION_ID=5.1.0-devel-202011-build.4
PRETTY_NAME=“TorizonCore 5.1.0-devel-202011+build.4 (dunfell)”
BUILD_ID=“4”
ANSI_COLOR=“1;34”
My problems start at Step 11. The ‘Select support platforms:’ window is supposed to provide me with four variants: bullseye or buster, 32-bit vs 64. But the only choices I get are “debian buster-slim arm32v7 - 1.0” and “debian buster-slim arm64v8 - 1.0”, as seen in the attachment VS_platforms.png. So I choose the arm64v8 variant.
When project creation is complete, I get a popup (screenshot attached Project_error.png) saying “Error creating project, may not work as expected.” I click OK.
For Step 12, there is no ‘Debug > Linux Console’ menu item.
For Step 13, I open the main.cpp file, but I don’t worry about modifying the program because of more basic issues. As seen in Error_list.png, cstdio and printf cannot be found, indicating missing libraries. And the Output pane in Output_pane.png shows a missing config.yaml file. I see no mention of this YAML file in the instructions, and I don’t know what to put in it.
I set the configuration to Debug/ARM, but I get the same results with Debug/x64. This setting wasn’t mentioned in the instructions.
I can see where all my problems are caused by the incorrect platforms, but I am just following the instructions, and not sure how to fix this.link text
Greetings @gloverbarker,
We believe we may have fixed the issues with the extension. However it will take some time to validate and test these fixes. If you’d like to work with these fixes, you can have access to them by installing the early access version of the extension from the Visual Studio marketplace.
Since this is an early access version some things may look different then how it’s currently documented but the process should still be the same. Also as can be expected from early access there may be some bugs here and there still present. Apologies for the inconvenience.
Best Regards,
Jeremias
@jeremias.tx @malley
I installed the new early access version, but it didn’t help much, although Step 11 is better. I DO get the correct platform variants, ‘debian arm32v7’ bullseye and ‘debian arm64v8 bullseye’, so I choose the 64-bit version.
But I still get the “Error creating project, may not work as expected.” popup window. And I still get errors with cstdio and printf in main.cpp, and I am still missing config.yaml.
Thanks for the effort so far, but there are still problems.
Ok this is unusual, I wasn’t able to recreate this on my side and am able to go through the getting started with the early access version.
Can you enable the debug window for our Extension so that I can get more information about this issue. 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 and there should now be a command prompt window that shows all the API calls made by our extension. You may also need to stop the extension process, moses.exe, via task manager after changing the option before the debug window shows up properly.
Once that is going can you run through the process again up to the point of failure then provide the output of the debug window.
Best Regards,
Jeremias
@jeremias.tx Sorry, I didn’t see your response until now.
I enabled the debug window as requested. Now when I run VS 2019 in Step 11, a separate moses.exe window pops up, with the following contents, which I assume is the desired debug output.
And in the same step, I get the “Error creating project, may not work as expected.” popup.
In the VS2019 output pane for Torizon Build, I get
Testing if backend service and docker are up and running...
Backend service and docker are up and running, enabling Torizon features.
Error loading Torizon application configuration.
Code: 500
Description: Internal server error
Message: [Errno 2] No such file or directory: 'C:\\Users\\glover.barker\\source\\repos\\HelloWorld6\\config.yaml'
Error loading application configuration.
And in the output pane for Solution I get
C:\Users\glover.barker\source\repos\HelloWorld6\HelloWorld6.vcxproj : warning : Platform 'ARM' referenced in the project file 'HelloWorld6' cannot be found.
C:\Users\glover.barker\source\repos\HelloWorld6\HelloWorld6.vcxproj : warning : Platform 'x64' referenced in the project file 'HelloWorld6' cannot be found.
Also, I enabled VS logging by setting the TRACEDESIGNTIME variable to true. The attached log file *.designtime.loglink text is the result. On line 2257, I get in part:
The OutputPath property is not set for project 'HelloWorld6.vcxproj'.
So in VS I added output paths in Configuration Properties > General > Output Directory. The TRACEDESIGNTIME log no longer shows an error, but all of the other errors still occur (cstdio and printf not found).
I still suspect that the lack of config.yaml is causing the later symptoms.
Yes given all this information I believe you’re on the right track with something strange going with the project files particularly config.yaml. Does “C:\Users\glover.barker\source\repos\HelloWorld6\config.yaml” exist for you? Or is it like the errors say and it doesn’t exist?
What’s also confusing is that in the output pane it references project HelloWorld6 but in the extension’s debug window it references HelloWorld5.
Honestly it might be better to start this from scratch and clean everything up to have a clean environment.
Let’s try this uninstall the extension. After that make sure to kill any “moses.exe” processes that may still be running. Then delete all your previous project folders at this location “C:\Users\glover.barker\source\repos\”. After that reinstall the early access version again and try again from the start.
Also as a side note cstdio and printf not found is normal the extension only fixes it after the first build and sync.
Best Regards,
Jeremias
@jeremias.tx
Sorry my samples were from different projects. I have tried the same thing so many times they got mixed up.
So, as requested, I uninstalled the extension, deleted all project folders, restarted the PC, reinstalled the early access version, and started the exercise again. The results were the same.
There is no config.yaml in the project folder. As a test, I created a non-Torizon VS project, and it worked fine, and had no config.yaml file. So I assume the yaml file is supposed to be created by your plugin, maybe for Docker.
Can you please pursue the issue of what is supposed to happen with config.yaml, and what might keep it from being created?
@jeremias.tx
Sorry my samples were from different projects. I have run the same thing so many times they got mixed up.
So, as requested, I uninstalled the extension, deleted all project folders, restarted the PC, reinstalled the extension, and started the exercise again. The results were the same.
There is no config.yaml file created in the project folder. As an experiment, I created a non-Torizon project, which worked fine, and it did not create a config.yaml. So I assume the yaml file is created by your plugin, probably for Docker.
Can you please pursue the issue of what is supposed to happen with config.yaml, and what might keep it from being created?
I’m going to contact one of our IDE engineers to examine your issue here.
Just to preemptively answer your questions yes the config.yaml is specific to our extension and contains your project’s configurations for our extension to parse. Normally this file should be created under a “app_config” folder in your project folder. What strikes me as odd is that according to your logs they’re just searching for config.yaml under your project folder and not under app_config. For example in my personal setup the config.yaml is found here: C:\Users\jeremias.cordoba\source\repos\HelloWorld\appconfig_0\config.yaml
I guess for out of curiosity now what is the contents of your HelloWorld project folder? I’m now wondering if anything else was generated incorrectly.
Best Regards,
Jeremias
@jeremias.tx
Attached link text is a zip of my HelloWorld project folder, from C:\Users*\source\repos.
I should restate that I am working with Visual Studio 2019, not Visual Studio Code. I mention that because I earlier tried to integrate the MX8 with Visual Studio Code, and that package DID create config.yaml under appconfig_0. But I had other problems, so I am trying VS 2019, since that integration is better documented, or so I thought.
This is really strange for us we’ve never had a scenario where the config.yaml was just not being generated in the project. It’s difficult to tell why your setup is producing such results.
You mentioned you had problems with the Visual Studio Code extension? Could you elaborate please? The VSCode and VS extensions use a common backend. Therefore maybe learning about your issues with VSCode may provide new information on what’s going on with your setup and our extension.
Best Regards,
Jeremias
@jeremias.tx
I tried reproducing my problems in Visual Studio Code. I saw that there was a new Early Access version, v1.2.86, of your extension, so I installed that.
I started out with the exercise “Build and Run Your First Python Application” at
Build and Run Your First Python Application
This exercise was for a different board, and for Python instead of C++, but it helped me get started with VSC. I successfully ran the Python test program from VSC on the MX8 board. And a config.yaml file was created under appconfig_0.
Then I tried to follow “C/C++ Development and Debugging on TorizonCore Using Visual Studio Code”, for Torizon 5.0.0, at
C/C++ Development and Debugging on TorizonCore Using Visual Studio Code | Toradex Developer Center
I then started messages something like “Unable to create SSL tunnel” to the board. And I was unable to created a new project. Thinking the problem was my environment, I tried creating additional new projects, rebooting the MX8 board, restarting the PC, restarting VSC, and reinstalling the extension. But I was no longer able to access the board from VSC, even though I could still login to it through a serial port.
Next I tried re-installing Visual Studio Code, which was a mistake because now I need to re-install all the plugins, WSL, Docker, etc. I don’t have more time to spend on this right now. Please inform me when you have an updated Stable version.
Apologies for the experience. We are currently testing a new stable version which will promote the current early access to the stable feeds. Hopefully the new version will resolve your issue or give us better insight into what you’re experiencing.
I downloaded and installed the new VS 2019 (not VS Code) plugin dated 1/8/2021, the stable version (not early access). I got the same behavior as in my 12/4/2020 post: popup says “Error creating project, may not work as expected”, no appconfig_0 folder, no config.yaml file.
When I try to run the project, I get :
Error loading Torizon application configuration.
Code: 500
Description: Internal server error
Message: [Errno 2] No such file or directory: ‘C:\Users\glover.barker\source\repos\HelloWorld\config.yaml’
Can you tell me if more stable versions are planned to fix bugs? If not, please tell me how to proceed. Maybe you can tell me what might cause the popup “Error creating project, may not work as expected”, and we can work backward from there.
Greetings @gloverbarker,
This is quite puzzling as this issue never came up during testing with the latest stable extension version that just released. Since you’ve experienced this issue before with the old version and even now, this leads me to believe that there may be something more to this.
Can you please provide the output from the Moses debug window as you’ve done before. I’ll pass this on to the IDE team for analysis. Make sure to capture the entire session logs from the start of the process up to where the error occurs. Also if you could please copy/paste the logs or attach them as plain text that would be appreciated as well, it just makes it easier for us to parse.
Best Regards,
Jeremias
@jeremias.tx
Attached link text is the requested Moses output. It occurs in Step 11, at the same time I receive the “Error creating project, may not work as expected” popup. Let me know if you need anything else.
Thank you for the debug logs. I’ll pass this on to the team and hopefully we can figure out what kind of configuration causes the issue you are seeing here.
Best Regards,
Jeremias
@jeremias.tx
Is there any status on this issue?
Based on your last log we were still unable to find the root cause of your missing config.yml file.
However since then we came up with a new alternative to debug so let’s try this and see if it gives any different/new info.
- First of all start Visual Studio
code and make sure the moses console
is up and running.
- Then open your internet browser and go to
http://localhost:5000/api/ui/. If this page comes up cleanly then we’re good to proceed.
- Now navigate to
http://localhost:5000/api/ui/#/Applications/applications_create
- Click the
Try Out button on this page
- Below this there should be some fields, for
platform_id input arm64v8-debian_bullseye
- For
path insert some test folder like C:\\Users\\glover.barker\\source\\repos\\HelloWorld. Make sure this path exists fully and the end folder is empty.
- Finally
username put torizon
- Once all 3 fields are populated hit the execute button. This will run a test executing of creating a project/application.
- Please take note of and copy all the contents that appeared in the moses console during this.
- Also check your test folder. This process should have created an
appconfig_0 folder with a config.yaml file in that.
Alright so try this process and let me know what the contents are of your test folder at the end as well as what the output of the moses debug console is.
Best Regards,
Jeremias
