search

goldshtn / msos

Command-line environment a-la WinDbg for executing SOS commands without having SOS available.
Other
96 stars 21 forks source link

msos.sln doesn't compile without Visual Studio 2015 (14.0) installed locally #72

Open atsvetkov opened 7 years ago

atsvetkov commented 7 years ago

Tried cloning the repo and building it on a machine with only VS 2017 installed - and got these errors (both when doing msbuild msos.sln from command line and when building in VS):

PostBuildEvent:
  call "C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\Tools\vsvars32.bat"
  editbin /largeaddressaware "C:\Users\Alex\Documents\github\goldshtn\msos\msos\bin\x64\Debug\msos.exe"
  '"C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\Tools\vsvars32.bat"' is not recognized as an internal or external command,
  operable program or batch file.
  'editbin' is not recognized as an internal or external command,
  operable program or batch file.
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\bin\Microsoft.Common.CurrentVersion.targets(5020,5): error MSB3073: The command "call "C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\Tools\vsvars3
2.bat" [C:\Users\Alex\Documents\github\goldshtn\msos\msos\msos.csproj]
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\bin\Microsoft.Common.CurrentVersion.targets(5020,5): error MSB3073: editbin /largeaddressaware "C:\Users\Alex\Documents\github\goldshtn\msos\msos\bin\x64\Debug\
msos.exe"" exited with code 9009. [C:\Users\Alex\Documents\github\goldshtn\msos\msos\msos.csproj]
Done Building Project "C:\Users\Alex\Documents\github\goldshtn\msos\msos\msos.csproj" (default targets) -- FAILED.

Done Building Project "C:\Users\Alex\Documents\github\goldshtn\msos\msos.sln" (default targets) -- FAILED.

Build FAILED.

"C:\Users\Alex\Documents\github\goldshtn\msos\msos.sln" (default target) (1) ->
"C:\Users\Alex\Documents\github\goldshtn\msos\msos\msos.csproj" (default target) (2) ->
(PostBuildEvent target) ->
  C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\bin\Microsoft.Common.CurrentVersion.targets(5020,5): error MSB3073: The command "call "C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\Tools\vsvar
s32.bat" [C:\Users\Alex\Documents\github\goldshtn\msos\msos\msos.csproj]
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\bin\Microsoft.Common.CurrentVersion.targets(5020,5): error MSB3073: editbin /largeaddressaware "C:\Users\Alex\Documents\github\goldshtn\msos\msos\bin\x64\Debug\
msos.exe"" exited with code 9009. [C:\Users\Alex\Documents\github\goldshtn\msos\msos\msos.csproj]

    0 Warning(s)
    1 Error(s)

The reason seems to be clear: a post-build event in msos.csproj tries to set path environment variables by calling vsvars32.bat from a VS2015-specific directory (C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\Tools\vsvars32.bat), so that editbin can be called after that. Batch file isn't found, therefore editbin cannot be found either and the event fails.

For VS2017, there is a different batch file VsDevCmd.bat with a similar purpose, and it is located in C:\Program Files (x86)\Microsoft Visual Studio\2017\{VS_EDITION}\Common7\Tools. But when I tried to call this one in the post-build event instead, it still didn't find editbin - apparently, for VS2017 its path isn't set in scope of this batch file. I was able to find it manually in C:\Program Files (x86)\Microsoft Visual Studio\2017\{VS_EDITION}\SDK\ScopeCppSDK\VC\bin folder, so putting the whole path in post-build event finally fixed the error. Obviously, this isn't a solution, but at least it proved to me that the required toolset can be found when having VS2017 only.

Has anyone else experienced this?

I don't know much about editbin.exe, but it seems to be part of some C++ SDK installed with VS2017 by default, since I don't do C++ and definitely didn't include it in VS installer. So, I assume that any VS2017 installation will have it in the same place where I found it. There's still some trickery required to automatically determine which edition of VS2017 user has, since it is a part of the path now. But I think it can be done, vswhere being one of the options.

@goldshtn, do you think this is worth fixing? If so, I could try to make it work and submit a PR. Of course, it should still keep working for VS2015-only machines too (although this would be harder for me to verify).

goldshtn commented 7 years ago

Thanks for the report. I was always worried about invoking editbin. BTW it's not really required for the 64-bit build, only for the 32-bit one (I'm using it for /LARGEADDRESSAWARE, which gives msos a 4GB address space when running as a 32-bit application on a 64-bit OS).

Perhaps a better long-term solution would be to modify the binary header without using editbin. I haven't looked into it yet. In the meantime, if you'd like to prepare a PR that makes it work on 2017, it would be much appreciated.