Open atsvetkov opened 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.
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):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 thateditbin
can be called after that. Batch file isn't found, thereforeeditbin
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 inC:\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 findeditbin
- apparently, for VS2017 its path isn't set in scope of this batch file. I was able to find it manually inC:\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).