Sitecore / Habitat

Sitecore Modular Architecture Example
Other
413 stars 397 forks source link

VS2019 breaks gulp script #467

Closed af4jm closed 5 years ago

af4jm commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

nickwesselman commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

af4jm commented 5 years ago

@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 commented 5 years ago

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

cassidydotdk commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

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

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

nickwesselman commented 5 years ago

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