Forum Replies Created
-
AuthorPosts
-
helpmeParticipant
I previously tried to set the full path in Tools->Options->VisualGDB, but it didn’t work. The key was to restart Visual Studio after changing the path.
I’m using the default msbuild rules and property sheets, so nothing is overridden on purpose and other tools in the %PATH% work fine…just not VisualGDB trying to find vagrant.exe. I have it working now by modifying the options, so thank you.
helpmeParticipantIt is odd that visualgdb works fine when using devenv.com, but fails with msbuild being unable to find vagrant.exe (both programs started from the same command prompt so the permissions are identical).
What msbuild options did you use to get the build to succeed?
Are you using VS2017?
Here is the latest output:
“C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\15.0\Bin\msbuild.exe” foo.sln /p:Configuration=Release /p:Platform=VisualGDB /m /l:FileLogger,Microsoft.Build.Engine;logfile=C:\foo.txt /verbosity:d
.
.
.
Using “LaunchVisualGDB” task from assembly “C:\Program Files (x86)\Sysprogs\VisualGDB\Sysprogs.Build.Tasks.dll”.
Task “LaunchVisualGDB”
VisualGDB version 5.4.1.2164
System.Reflection.TargetInvocationException
System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. —> System.Exception: Cannot find vagrant.exe in PATH directories. Please specify its path manually via Tools->Options->VisualGDB. Checked PATH: ; Explicit location: C:\HashiCorp\Vagrant\bin
at uf1.h()
at uf1.b(l a, o02 b)
at xi2.h1(String b, String a)
at xi2.e.i(String b, String a, g c)
at xi2.e1(RemoteHostSettings a)
at pc.d(RemoteHostSettings b, Boolean a)
at g6.q4(SourceTransferAction a, SourceCache b, zd2 c)
at hx1.a_2(Boolean a, Boolean& b)
at ik.j(BuildMode b, f a)
at ik.i(BuildMode a)
at pr1.a(String c, BuildMode a, c b)
at VisualGDB.MSBuild.BuildHelper.LaunchBuildAction(String action, String settingsFile, String generatedMakefile, String targetPath, String cancelEventName, IBuildCallbacks callbacks, Boolean suppressErrorParsing)
at Sysprogs.build.tasks.shared.LaunchVisualGDB.<>c__DisplayClass21_0.<Execute>b__0()
— End of inner exception stack trace —
at Sysprogs.build.tasks.shared.LaunchVisualGDB.Execute()
—Inner exception—
System.Exception: Cannot find vagrant.exe in PATH directories. Please specify its path manually via Tools->Options->VisualGDB. Checked PATH: ; Explicit location: C:\HashiCorp\Vagrant\binC:\> dir C:\HashiCorp\Vagrant\bin
Directory of C:\HashiCorp\Vagrant\bin
01/29/2018 08:05 PM 2,279,424 vagrant.exehelpmeParticipantThe PATH in the command prompt contains the vagrant.exe and it works, but when using msbuild, VisualGDB can’t find the vagrant.exe. The user account is the same.
Does msbuild work for you? Even though msbuild fails, I was able to use devenv.com successfully in the same command prompt window. Does VisualGDB require the Visual Studio IDE to load properly?
This worked:
“\Program Files (x86)\Microsoft Visual Studio\2017\Professional\Common7\IDE\devenv.com” foo.sln /rebuild “Release|VisualGDB” /Out foo.log
February 15, 2018 at 21:10 in reply to: VisualGDB: Error: Bash process exited before connecting to output port #20117helpmeParticipantTo reproduce, you also need to switch between the WSL configurations and compile. You can do this with the wslconfig command.
Something must be getting cached and not updated in appdata\VisualGDB, because as soon as I deleted this directory the existing issue went away.
February 15, 2018 at 20:17 in reply to: VisualGDB: Error: Bash process exited before connecting to output port #20116helpmeParticipantTo reproduce:
Install Windows Fall Creator Edition.
Use the Windows Store to install Ubuntu and opensuse.
Compile a test project and review the header usage to see the issue.
February 9, 2018 at 23:36 in reply to: VisualGDB: Error: Bash process exited before connecting to output port #20028helpmeParticipantThere is something wrong with how the toolchain is configured. I setup a vagrant centos image, and visualgdb uses the vagrant gcc, but somehow the Ubuntu WSL ld. That is pretty scary that visualgdb is combining the tools from Vagrant and WSL.
February 2, 2018 at 17:41 in reply to: VisualGDB: Error: Bash process exited before connecting to output port #19914helpmeParticipantThe wsl default was never set to opensuse, so I don’t think that was the reason visualgdb was using the Ubuntu and openSUSE paths at the same time. I would guess that is a real bug that needs to be tested.
February 1, 2018 at 21:19 in reply to: VisualGDB: Error: Bash process exited before connecting to output port #19908helpmeParticipantThe latest installer worked, but I lost the visualgdb properties menu within visual studio. I’ve tried reinstalling and repairing to no avail. Any ideas how to get this back?
Installing the latest visualgdb appeared to work with the new WSL image, but there appears to be another issue. I have Ubuntu and OpenSuse wsl images installed. Ubuntu is set as the default as shown by wslconfig and by checking the registry. When compiling it appears to use the Ubuntu image for most of the work, but I also noticed this within the output:
1>C:\Users\me\AppData\Local\Packages\46932SUSE.openSUSELeap42.2_022rs5jcyhyac\LocalState\rootfs\usr\include\c++\5\bits\c++0x_warning.h(32,2): error : …
Note that it is referencing the OpenSUSE image, not the Ubuntu. If I had to guess, the openSUSE BasePath is being used as that guid shows up first alphabetically within the registry:
openSUSE: HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Lxss\{3106b4e7-c41e-4509-a3b9-195bc72b945b}
Ubuntu: HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Lxss\{3c61b403-dbbb-405f-991a-ef51079d0207}
Would you please test multiple WSL installs? It seems there are quite a few issues.
January 30, 2018 at 18:36 in reply to: VisualGDB: Error: Bash process exited before connecting to output port #19886helpmeParticipantThe registry key points at the appropriate version of WSL. Please test an updated WSL image from the Windows Store when running the Windows Fall Creator’s Update (<span class=”ng-isolate-scope”><span class=”ng-scope”>Windows 10, version 1709</span></span>). This appears to have issues.
VisualGDB was able to access the WSL through localhost:portnumber, but that may not be ideal for multiple developer machines with different sshd configs.
1>System.Reflection.TargetInvocationException
1>System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. —> System.Exception: Bash process exited before connecting to output port
1> at ju1.r.f1(CommandLineAction b, CommandFlags a, Boolean c)
1> at ju1.r..ctor(CommandLineAction d, CommandFlags b, d41 a, Boolean c)
1> at ju1.h_4(d41 b, String a, String c, String e, ExpandedEnvironment f, CommandFlags d)
1> at ym1.k1(String e, String d, String g, ModifiedEnvirionment c, o9 f, Int32 a, CommandFlags b)
1> at m21.g(String b, String a)
1> at q22.i(BuildMode a, f b)
1> at q22.h(BuildMode a)
1> at cn1.b(String b, BuildMode c, e a)
1> at VisualGDB.MSBuild.BuildHelper.LaunchBuildAction(String action, String settingsFile, String generatedMakefile, String targetPath, String cancelEventName, IBuildCallbacks callbacks, Boolean suppressErrorParsing)
1> at Sysprogs.build.tasks.shared.LaunchVisualGDB.<>c__DisplayClass21_0.<Execute>b__0()
1> — End of inner exception stack trace —
1> at Sysprogs.build.tasks.shared.LaunchVisualGDB.Execute()
1>—Inner exception—
1>System.Exception: Bash process exited before connecting to output port
1> at ju1.r.f1(CommandLineAction b, CommandFlags a, Boolean c)
1> at ju1.r..ctor(CommandLineAction d, CommandFlags b, d41 a, Boolean c)
1> at ju1.h_4(d41 b, String a, String c, String e, ExpandedEnvironment f, CommandFlags d)
1> at ym1.k1(String e, String d, String g, ModifiedEnvirionment c, o9 f, Int32 a, CommandFlags b)
1> at m21.g(String b, String a)
1> at q22.i(BuildMode a, f b)
1> at q22.h(BuildMode a)
1> at cn1.b(String b, BuildMode c, e a)
1> at VisualGDB.MSBuild.BuildHelper.LaunchBuildAction(String action, String settingsFile, String generatedMakefile, String targetPath, String cancelEventName, IBuildCallbacks callbacks, Boolean suppressErrorParsing)
1> at Sysprogs.build.tasks.shared.LaunchVisualGDB.<>c__DisplayClass21_0.<Execute>b__0()
1>C:\Program Files (x86)\Sysprogs\VisualGDB\MSBuild\Targets\remote.targets(15,2): error : Exception has been thrown by the target of an invocation.helpmeParticipantThat fixed the issue.
Thank you,
Jon
-
AuthorPosts