November 15, 2021 at 08:00 #31777
we have Linux Buildserver running to crosscompile an application for an arm Target. This works quite well in our testing facility with direct access to the server. To be able to build and deploy the application localy on my development-pc (sometimes this is needed when we are working off-site) I installed Unbuntu inside WSL2 (with the appropriate crooscompiling toolchain) and activated sshd for access. Building applications on console works fine. Unfortionately I can not get this running in Visual Studio / VisualGDB. It fails when trying to selct the toolchain:
- Selecting “Specify toolchain manualy by locating GDB executable” shows Ubuntu Filesystem -> GDB-executable can be selected
- New window “Edit Toolchain” opens -> Pathes are set properly
- Hitting “Apply” or “Ok” in the property window throws exception:
VisualGDB version: 184.108.40.20661
------------------ System.NullReferenceException ------------------
System.NullReferenceException: Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt.
bei VisualGDB.Common_GUI.WPF.Property_pages.MSBuildSettingsPage.ControllerImpl.ExportSettings(Object settingsObject, mx2 ectx)
bei VisualGDB.Common_GUI.Configuration_editors.ProjectPropertiesEditModel.c2.j.Export(qh3 b, VisualGDBProjectSettings2 a)
bei VisualGDB.Common_GUI.Configuration_editors.ProjectPropertiesEditModel.r1(c2 b, l a)
bei VisualGDB.Common_GUI.Configuration_editors.ProjectPropertiesEditModel.m(Boolean b, tw a, String d, Action c)
bei VisualGDB.Common_GUI.WPF.ProjectPropertiesWindow3.Apply_Click(Object sender, RoutedEventArgs e)
trace=[VisualGDB.Common_GUI.WPF.Property_pages.MSBuildSettingsPage+ControllerImpl.ExportSettings:4078, VisualGDB.Common_GUI.Configuration_editors.ProjectPropertiesEditModel+c2+j.Export:37, VisualGDB.Common_GUI.Configuration_editors.ProjectPropertiesEditModel.r1:32, VisualGDB.Common_GUI.Configuration_editors.ProjectPropertiesEditModel.m:119, VisualGDB.Common_GUI.WPF.ProjectPropertiesWindow3.Apply_Click:0]
Any ideas what’s going wrong?
NilsNovember 15, 2021 at 08:49 #31778
This looks like VisualGDB could not get fully activated on that computer. Could you please double-check the Help->About VisualGDB window? Does it show the correct activation information? If yes, does opening the About window before editing any settings solve the problem?November 16, 2021 at 01:14 #31783
thank you for your quick response. Please find Screenshots of the “About” dialog and the configuration process enclosed (I actually do not know how to insert an image directly into the post… What do I have to enter as “Source” when using “Insert->Image”?)
Even after opening the “About dialog” the settings are not stored…
NilsNovember 16, 2021 at 18:11 #31792
Thanks for the screenshots. Indeed, the license looks properly loaded and should not be causing this. Could you please double-check whether the problem also happens for other projects, or if it’s specific to this one? Some manual edits to .vgdbsettings and .vcxproj files could cause hard-to-track internal errors.
You can also try using this build: VisualGDB-220.127.116.1192.msi. Please try enabling View->Other Windows->VisualGDB Diagnostics Console before changing the settings, and share the contents of the diagnostics console along with the new error message.December 2, 2021 at 02:55 #31831
I did some more tests as suggested. Unfortunately without success. Please take a look at the attachment.
Nils OssenbrinkDecember 4, 2021 at 16:35 #31846
Thanks, it looks like the problem is somewhere in the logic that writes the new toolchain ID to the project configuration. Please try this build: VisualGDB-18.104.22.16807.msi
It generates much more diagnostic output in that part, so it should help us narrow it down further. Please try attaching an updated log from the diagnostic console (no screenshots/other logs are necessary) and we will try find the root cause.December 6, 2021 at 02:55 #31852
NilsDecember 6, 2021 at 11:11 #31854
Thanks, we have narrowed it down further and updated VisualGDB to show a more informative error message. Please try this build: VisualGDB-22.214.171.12408.msi
If the problem persists, please try following the steps below:
December 7, 2021 at 03:16 #31862
- Enable VisuaGDB Diagnostics Console
- Open VisualGDB Project Properties and re-import the toolchain. This should be done with the diagnostic console enabled.
- Make sure the imported toolchain is selected in the VisualGDB Project Properties window. If it shows “no toolchain selected”, please try selecting it manually.
- If the toolchain doesn’t appear in the list, or if selecting it doesn’t work, please attach the updated diagnostic log. If selecting the toolchain manually solved the problem, feel free to attach a screenshot of the toolchain list and the diagnostic log as well, so that we could check why the automatic selection didn’t happen.
the problem is that the imported Toolchain does not show up. Only the default Toolchains are available even after importing…December 7, 2021 at 10:05 #31866
Thanks for the updated log file. Indeed, VisualGDB is saving the imported toolchain to the location normally used for the Windows toolchains:C++1Saving newly imported toolchain to C:\Users\709218\AppData\Local\VisualGDB\ToolchainProfiles\localhost\com.sysprogs.imported.arm-linux-gnueabihf-4.8.3__r0...
This happens because the project is configured to connect to localhost via the default SSH port, so VisualGDB treats it as a Linux machine name. In order to workaround it, please consider using “127.0.0.1” instead of “localhost”, or specifying the port explicitly, i.e. “localhost:22”.
That said, we normally advise picking the WSL distro directly in the host selector, rather than using SSH. It will enable the special WSL-specific communication mode, that is faster then SSH.December 8, 2021 at 00:19 #31868
using the IP instead of “localhost” seems to work. I will do some more tests and come back with a feedback later. Thank you very much for your support!
NilsDecember 8, 2021 at 11:16 #31871
No problem and good to know it works. We have also updated VisualGDB on our side to suggest the use of the IP address or port when trying to create an SSH connection to ‘localhost’.
You must be logged in to reply to this topic.