helpme

Forum Replies Created

Viewing 10 posts - 1 through 10 (of 10 total)
  • Author
    Posts
  • in reply to: msbuild.exe a solution on the command line? #20687
    helpme
    Participant

    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.

    in reply to: msbuild.exe a solution on the command line? #20667
    helpme
    Participant

    It 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\bin

     

     

    C:\> dir C:\HashiCorp\Vagrant\bin
    Directory of C:\HashiCorp\Vagrant\bin
    01/29/2018  08:05 PM         2,279,424 vagrant.exe

    in reply to: msbuild.exe a solution on the command line? #20650
    helpme
    Participant

    The 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

    helpme
    Participant

    To 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.

    helpme
    Participant

    To 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.

     

    helpme
    Participant

    There 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.

    helpme
    Participant

    The 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.

    helpme
    Participant

    The 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.

    helpme
    Participant

    The 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.

    in reply to: error compiling on linux WSL with msbuild macros #13198
    helpme
    Participant

    That fixed the issue.

    Thank you,

    Jon

Viewing 10 posts - 1 through 10 (of 10 total)