Forum Replies Created
-
Posts
-
Hi,
Sorry, the page inside SSH Connection Manager is called “host-wide settings” and you will need to create an entry for your host in order to configure the timestamp difference.
Hi,
In Visual Studio the include search paths need to be specified explicitly. Just adding headers to Solution Explorer will not automatically let your code discover it. Simply add the directories with headers to VisualGDB Project Properties -> MSBuild -> Include Directories and MSBuild will be able to find them.
You can also use the VisualGDB’s header discovery logic – it should normally locate the missing headers automatically and suggest updating the project properties for you. You can read more about this feature here: https://visualgdb.com/tutorials/intellisense/headers/
Hi,
Most likely your targets have a different time zone from the development machine. Please consider adjusting them, or simply add the timestamp offset via Tools->VisualGDB->Manage SSH Connections->Per-host Settings. You can also disable the tar timestamps completely in the same window if you want to restore the v5.3 behavior (setting timestamps to the time of transfer, not the original time of the files on Windows).
Hi,
Please try checking the registry under HKEY_CURRENT_USER\Software\Sysprogs\GNUToolchains. VisualGDB loads toolchains from the paths listed there. Simply create another key following the SysGCC-<target> pattern and restart Visual Studio (or reopen the VisualGDB Package Manager) to register another toolchain with VisualGDB.
No problem. Unfortunately most of the modern antivirus software is not very practical – it tries to either search every exe file against a large database of regular expressions (triggering random false positives for high-entropy compressed images like the toolchain installers) or to flag every file that would issue HTTP requests (like our session server) as suspicious.
We have briefly rechecked with VirusTotal and Avira doesn’t report it as suspicious, so it’s hard to say why it’s triggering on your side. Please consider submitting a false positive request to them with the exact details of your antivirus version & type (we can only do that if we see false positives from major AV vendors on Virus Total). Also if you are not planning to use the floating license, you can simply delete the file.
Update: we have created a page listing the components that most often trigger false positives with antivirus software: https://visualgdb.com/documentation/falsepositives/
Whoa, that’s a big one. VisualGDB doesn’t really include any special framework for interfacing your embedded code with higher-level languages, so you would likely need to design one or reuse something like protobuf. Generally, as this is a rather generic programming question, than a VisualGDB-specific issue, we would advise creating a question on StackOverflow – there’s a large developer community there and you may get some good ideas from other developers.
Hi,
Yes, it’s a part of the VisualGDB installation responsible for the floating license mechanism. If you are using a floating license, it will run in the background, fetching up-to-date session keys from our licensing server to all running VisualGDB instances.
Hi,
Most likely you have corrupted some XML files during the find-and-replace. Please try restoring your project from a backup and also reinstalling VisualGDB to fix any corrupt global files.
Hi,
No problem, we can help you. The second problem turned out to be our bug introduced by a recent refactoring. It was on our radar, but we were not aware it affects regular (non-ESP32) CMake projects as well. We have fixed it in the following build: http://sysprogs.com/files/tmp/VisualGDB-5.4.100.2765.msi
The first problem might be caused by the CMake (not reporting the correct include directory for the specific file), or by VisualGDB (e.g. mapping the path incorrectly). In order to narrow it down, please follow the steps below:
- Identify the exact location of the missing header.
- Open Clang IntelliSense Diagnostics Console and switch it to the Project view. Locate the source file that triggers the problem and check its CFLAGS. If the CFLAGS are empty, check the project’s CFLAGS. Do the CFLAGS reference the correct directory? If not, do they mention a similar directory (that would result from invalid path mapping)?
- If the directory is not correct, or is missing, please check the CodeModel.json file in the VisualGDBCache directory. This is the code model reported by CMake. Does it report the correct include directory for the correct source file? If you are not sure, please attach the code model file and let us know the path of the source file triggering the problem and and the header file that is missing.
Please provide an actual up-to-date description of the problem in a separate thread. Unfortunately we are not realistically able to pinpoint or fix the problem based on a generic description that Clang IntelliSense doesn’t work for some of the projects. We do have extensive tests covering various aspects of the IntelliSense functionality, so if you are experiencing inconsistencies, they are likely caused by the factors not covered by our tests. We will be happy to investigate and fix this, but we would need to be able to reproduce the problem on our side, or get a detailed description of it that will help us reconstruct the circumstances behind the problem.
Does your project use the ‘\r’ line endings? If yes, VisualGDB should show a bar that allows automatically changing them to ‘\n’. If not, the problem is likely caused by something else. If you could create a separate topic providing a detailed description of the problem you are observing, we will be happy to investigate this and provide a hotfix.
Hi,
No problem. Google indeed removed support for Ant-based builds from the latest Android SDK, switching it to Gradle and CMake.
The latest VisualGDB 5.4 fully supports both Ant-based builds with the older SDKs and the new CMake-based builds with the latest SDKs, so you can use any of those build systems depending on your requirements/preferences.
You can download SDK 2.24.1 directly from Google (we cannot mirror their packages due to copyright restrictions, but are happy to share the official download links): https://dl.google.com/android/installer_r24.4.1-windows.exe
Hi,
The easiest way to do this would be using the Quick Debug feature (see this tutorial). If you are building the code on Windows via a cross-toolchain, ensure you select it in the Quick Debug window and VisualGDB will locate the source files correctly.
A more long-term solution would be to import your existing build into VisualGDB using the Import mode of the Linux Project Wizard. Simply select “Import project built with other tools” and manually point VisualGDB to the final executable (e.g. Unreal exe). If you don’t want VisualGDB to control the build, simply specify a dummy build command line in the wizard (e.g. “echo done”) . Once the project is created, select “Attach to process” in the Debug Settings page of VisualGDB Project Properties and disable automatic deployment via the first page of VisualGDB Project Properties.
Next time you debug the project, VisualGDB will attach to the executable of your choice using the cross-toolchain specified in the project settings.
If this doesn’t work, please let us know and we will be happy to provide further help.
Based on the log file, the test session actually starts, so the “missing test container” error doesn’t make sense. If creating a new project after reinstalling VS helped, most likely some global setting was corrupt and it affected some other setting in the project. If a newly created project works, please consider making a backup of it in case you run into the same problem again.
You could also try deleting the .vs folder in the broken project (also the Debug/Release, VisualGDBCache, etc) to see if that fixes the problem, but it may not be worth the effort if newly created projects work.
Thanks for the log. Looks like Visual Studio throws an error while VisualGDB tries to enumerate the test containers. It might not be related to the original problem, but either way we have added better handling for this here: http://sysprogs.com/files/tmp/VisualGDB-5.4.100.2757.msi
Unfortunately, you did not include the updated log from the regular View->Output->Tests (the registry setting would increase its verbosity), so there might be other issues preventing the tests from starting. If the updated build doesn’t solve the problem, please attach both VisualGDB Diagnostics log and the regular test output log.
Please also consider repairing your VS installation – the problem might be caused by missing components of the VS side.
