VS2019 breaks gulp script

[af4jm]

Note: for support questions, please use Sitecore Stackexchange or #helix-habitat on Sitecore Community Slack. This repository's issues are reserved for feature requests and bug reports.

Describe the bug
Had 9.0.2 with a helix/habitat based solution working with VS2017. Installed VS2019 and gulp can no longer find MSBuild

Sitecore Version
9.0.2

To Reproduce
Steps to reproduce the behavior:

1. run "gulp default"

Expected behavior
Build as normal

Screenshots
actually, error message from command prompt...

{ Error: spawn C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\MSBuild\15.0\Bin\amd64\MSBuild.exe ENOENT
at Process.ChildProcess._handle.onexit (internal/child_process.js:232:19)
at onErrorNT (internal/child_process.js:407:16)
at process._tickCallback (internal/process/next_tick.js:63:19)

Additional context
To correct the above path, either "2019" changes to "2017" or "15.0" changes to "Current". Issue seems to be with gulp-msbuild, which is no longer maintained. Habitat needs to work on machines with VS2019 installed, regardless of the maintenance status of gulp-msbuild.

A probably related issue (with gulp-msbuild) is that in gulp-config.js, changing "buildToolsVersion" to anything other than "auto" also fails the build. Setting it to "15.0" on a machine with VS2017 only errors that it falls back to version 14.0 & can't find it.

[af4jm]

Found a work-around for situations where VS2017 is also installed, which is to force gulp to use 2017 instead of 2019... in node_modules\gulp-msbuild\lib\msbuild-finder.js line 14 (parameter list for the call to vswhere.exe)... change '-latest' to '-version', '[15.0,16.0)'

[af4jm]

Proposed solution: abandon gulp-msbuild in favor of msbuild (https://github.com/jhaker/nodejs-msbuild)

[nickwesselman]

I have Visual Studio 2019 installed (and still VS17) and cannot reproduce this on the master branch. The default buildToolsVersion in the gulp-config is 15.0.

As announced at SUGCON, Habitat is being retired in favor of a new set of examples, which will likely be 100% MSBuild based with no use of gulp. So we do not plan on any significant changes to the gulp scripts at this time.

We will be doing a small maintenance release for Sitecore 9.2, so if there is an adjustment to the existing scripts that needs to happen that might be possible. Can you identify any additional differences between your scripts and the those on the master branch?

[af4jm]

Great to hear the sample will be gulp-free (fingers crossed it won't need NPM either), we've been considering trying to rid ourselves of Gulp once our hired Sitecore consultants hand off after go live.

When I ran into this I didn't notice any differences around how it calls gulp-msbuild, but I will try to make some time in the next day or 2 to revisit. Unfortunately my successful work-around involved modifying a line of code in gulp-msbuild, which is quite inconvenient since it's NPM-controlled.

[hoquem1]

Instead of Gulp-Msbuild use the following
var _msBuild = require('msbuild');
var msbuild = new _msBuild();

[af4jm]

@hoquem1 that was my initial idea, but the trick is figuring out what else in gulpfile.js also needs to change.. it would be great if one was a drop-in replacement for the other, but it's not... at this point we're likely to try to convert it to straight-up msbuild, no node & no gulp... but not until the 3rd party consultants complete hand-off after go-live (we've got dev, qa, & uat, as well as blue-green with staging & prod, so the risk is relatively low

[hoquem1]

@af4jm take a look at this blog I created. Hopefully this will help you.
http://mohammadhoque.com/?p=296

[cassidydotdk]

Instead of Gulp-Msbuild use the following
var _msBuild = require('msbuild');
var msbuild = new _msBuild();

The existing process loops through .csproj files however and builds them individually. If you switch to build on a .SLN level, project dependencies need to be configured.

Not necessarily saying this is a problem, just raising awareness :)

[hoquem1]

@cassidydotdk
I didn't have to manually do that. It respected the dependency graph from solution file. Now that being said, just because I didn't run into an issue, I can't guarantee that it doesn't exists. I like the fact that someone else was thinking about the same issue as I was :)

[nickwesselman]

Approach using require('msbuild') from @cassidydotdk:

https://gist.github.com/cassidydotdk/d2c72096ee0a1b5cf1e542ee108ce024

[nickwesselman]

This is resolved in v1.8 by switching to require('msbuild') ... thanks for the report and the suggested fixes everyone.