Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

VS2019 breaks gulp script #467

Closed
af4jm opened this issue Apr 5, 2019 · 11 comments

Comments

@af4jm
Copy link

commented Apr 5, 2019

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

This comment has been minimized.

Copy link
Author

commented Apr 5, 2019

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

This comment has been minimized.

Copy link
Author

commented Apr 5, 2019

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

@nickwesselman

This comment has been minimized.

Copy link
Collaborator

commented Apr 23, 2019

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

This comment has been minimized.

Copy link
Author

commented Apr 23, 2019

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

This comment has been minimized.

Copy link

commented May 8, 2019

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

@af4jm

This comment has been minimized.

Copy link
Author

commented May 11, 2019

@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

This comment has been minimized.

Copy link

commented May 11, 2019

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

@cassidydotdk

This comment has been minimized.

Copy link

commented May 11, 2019

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

This comment has been minimized.

Copy link

commented May 13, 2019

@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

This comment has been minimized.

Copy link
Collaborator

commented May 22, 2019

nickwesselman added a commit that referenced this issue Aug 1, 2019
* simplified gulp file to just publish the full solution
nickwesselman added a commit that referenced this issue Aug 1, 2019
* simplified gulp file to just publish the full solution
@nickwesselman

This comment has been minimized.

Copy link
Collaborator

commented Aug 6, 2019

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.