hoffi/gulp-msbuild

Default path to msbuild no longer valid after VS2017 install

Closed this issue · 5 comments

shadowmint commented

After installing VS2017, the path to msbuild seems to have changed, resulting in:

Error: spawn C:\WINDOWS\microsoft.net\Framework64\vundefined\msbuild.exe ENOENT
    at exports._errnoException (util.js:1012:11)
    at Process.ChildProcess._handle.onexit (internal/child_process.js:182:32)
    at onErrorNT (internal/child_process.js:348:16)
    at _combinedTickCallback (internal/process/next_tick.js:74:11)
    at process._tickDomainCallback (internal/process/next_tick.js:122:9)

This seem to be because its falling back to the windows folder because the latest framework version (15), doesn't have an MSBuild.exe under C:\Program Files\MSBuild\15.0:

$ du -a /c/Program\ Files\ \(x86\)/MSBuild/15.0/
24      /c/Program Files (x86)/MSBuild/15.0/FileTracker/1028/FileTracker32UI.dll
24      /c/Program Files (x86)/MSBuild/15.0/FileTracker/1028/FileTracker64UI.dll
48      /c/Program Files (x86)/MSBuild/15.0/FileTracker/1028
24      /c/Program Files (x86)/MSBuild/15.0/FileTracker/1031/FileTracker32UI.dll
24      /c/Program Files (x86)/MSBuild/15.0/FileTracker/1031/FileTracker64UI.dll
48      /c/Program Files (x86)/MSBuild/15.0/FileTracker/1031
24      /c/Program Files (x86)/MSBuild/15.0/FileTracker/1033/FileTracker32UI.dll
24      /c/Program Files (x86)/MSBuild/15.0/FileTracker/1033/FileTracker64UI.dll
48      /c/Program Files (x86)/MSBuild/15.0/FileTracker/1033
24      /c/Program Files (x86)/MSBuild/15.0/FileTracker/1036/FileTracker32UI.dll
24      /c/Program Files (x86)/MSBuild/15.0/FileTracker/1036/FileTracker64UI.dll
48      /c/Program Files (x86)/MSBuild/15.0/FileTracker/1036
24      /c/Program Files (x86)/MSBuild/15.0/FileTracker/1040/FileTracker32UI.dll
24      /c/Program Files (x86)/MSBuild/15.0/FileTracker/1040/FileTracker64UI.dll
48      /c/Program Files (x86)/MSBuild/15.0/FileTracker/1040
24      /c/Program Files (x86)/MSBuild/15.0/FileTracker/1041/FileTracker32UI.dll
24      /c/Program Files (x86)/MSBuild/15.0/FileTracker/1041/FileTracker64UI.dll
48      /c/Program Files (x86)/MSBuild/15.0/FileTracker/1041
24      /c/Program Files (x86)/MSBuild/15.0/FileTracker/1042/FileTracker32UI.dll
24      /c/Program Files (x86)/MSBuild/15.0/FileTracker/1042/FileTracker64UI.dll
48      /c/Program Files (x86)/MSBuild/15.0/FileTracker/1042
24      /c/Program Files (x86)/MSBuild/15.0/FileTracker/1049/FileTracker32UI.dll
24      /c/Program Files (x86)/MSBuild/15.0/FileTracker/1049/FileTracker64UI.dll
48      /c/Program Files (x86)/MSBuild/15.0/FileTracker/1049
24      /c/Program Files (x86)/MSBuild/15.0/FileTracker/2052/FileTracker32UI.dll
24      /c/Program Files (x86)/MSBuild/15.0/FileTracker/2052/FileTracker64UI.dll
48      /c/Program Files (x86)/MSBuild/15.0/FileTracker/2052
24      /c/Program Files (x86)/MSBuild/15.0/FileTracker/3082/FileTracker32UI.dll
24      /c/Program Files (x86)/MSBuild/15.0/FileTracker/3082/FileTracker64UI.dll
48      /c/Program Files (x86)/MSBuild/15.0/FileTracker/3082
232     /c/Program Files (x86)/MSBuild/15.0/FileTracker/FileTracker32.dll
296     /c/Program Files (x86)/MSBuild/15.0/FileTracker/FileTracker64.dll
1012    /c/Program Files (x86)/MSBuild/15.0/FileTracker
1012    /c/Program Files (x86)/MSBuild/15.0/

This appears to be a new VS2017 issue and frankly after reading the documentation, I'm not actually sure what the correct behaviour even should be, but if you want to track it, there are a bunch of people talking about the issue here:

...for now, I've just uninstalled VS2017 to remove the '15' framework version to get things working again.

hoffi commented

There is a specific handling for VS 2017 here which was introduced in #47.

When you provide toolsVersion: 15.0, it should not look under C:/Program Files (x86)/MSBuild anymore.
Maybe this helps?

shadowmint commented

my bad, I've opened this issue on entirely the wrong issue tracker.

Yup, that works for me~

I was using msbuild not gulp-msbuild, and that doesn't work.

CesarD commented

"auto" option not working correctly with VS2017. I don't think the solution provided here would be the correct one.
If I have people in a team working with mixed versions (ie.: VS2015 & 2017), "auto" should be able to find the correct version for each environment, and now it doesn't. I have to manually specify the specific version on each environment when "auto" should be enough, because right now it defaults to 4.0 (like the OP mentioned originally).

Can msbuilder-finder.js be improved to better detect the VS2017 environment? You are already doing the correct thing when you manually specify toolsVersion: 15.0, so you should only modify the code accordingly for the correct detection.

hoffi commented

@CesarD thanks, I have released a new version that prefers newer MSBuild-Versions in the auto detection.

  • 👍1
CesarD commented

Cool, now it works perfectly! Thank you very much!