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

build,win,msi: support WiX with VS2017 #17101

Closed

Conversation

joaocgreis
Copy link
Member

To support releasing with VS2017, we need to be able to build the MSI with it. This PR:

  • Passes the Windows SDK version to the MSBuild invocation that builds the MSI, to support SDKs other than 8.1.
  • Adds warnings if WiX cannot be used. WiX for VS2017 requires an extension to be installed because of MSBuild changes, this adds a warning if it's missing.
  • Adds a note in the documentation about WiX.

Ref: #13052
Ref: #16969

cc @nodejs/platform-windows

Checklist
  • make -j4 test (UNIX), or vcbuild test (Windows) passes
  • documentation is changed or added
  • commit message follows commit guidelines
Affected core subsystem(s)

build, win, msi

@joaocgreis joaocgreis added build Issues and PRs related to build files or the CI. dont-land-on-v4.x windows Issues and PRs related to the Windows platform. labels Nov 17, 2017
@nodejs-github-bot nodejs-github-bot added build Issues and PRs related to build files or the CI. doc Issues and PRs related to the documentations. windows Issues and PRs related to the Windows platform. labels Nov 17, 2017
@joaocgreis
Copy link
Member Author

@rem check if VS2017 is already setup, and for the requested arch
if "_%VisualStudioVersion%_" == "_15.0_" if "_%VSCMD_ARG_TGT_ARCH%_"=="_%target_arch%_" goto found_vs2017
@rem need to clear VSINSTALLDIR for vcvarsall to work as expected
set "VSINSTALLDIR="
call tools\msvs\vswhere_usability_wrapper.cmd
if "_%VCINSTALLDIR%_" == "__" goto vs-set-2015
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought the idea was to avoid calling vswhere_usability_wrapper.cmd if it's already setup? This will call it every time.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

vcvarsall.bat below is the one to avoid. vswhere is not a problem and is needed for the WiX checks.

@refack
Copy link
Contributor

refack commented Nov 17, 2017

I would actually like to take this opportunity to refactor out all the release-only parts from vcbuild.bat. I'll try to get it done by the start of next week.

if not exist "%WIX%\SDK\VS2017" (
echo Failed to find WiX install for Visual Studio 2017
echo VS2017 support for WiX is only present starting at version 3.11
goto vs-set-2015
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we really fall back to VS2015 (or exit once #16969 lands) if the extension is not installed? Perhaps msi should just be skipped instead?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

MSI is not enabled by default, and this only applies if vcbuild was explicitly called with msi. So, skipping the msi here would be ignoring a parameter. Given that this is for releases, not just a nice to have, I don't think we should skip.

@joaocgreis
Copy link
Member Author

@refack can we go ahead with this here and do the refactor separately? I'd like to move ahead with the VS2017 transition for v10.

@joaocgreis
Copy link
Member Author

@nodejs/platform-windows @nodejs/build PTAL

@@ -209,6 +209,8 @@ Prerequisites:
* Basic Unix tools required for some tests,
[Git for Windows](http://git-scm.com/download/win) includes Git Bash
and tools which can be included in the global `PATH`.
* **Optional** (to build the MSI): the [WiX Toolset v3.11](http://wixtoolset.org/releases/)
and the [Wix Toolset Visual Studio 2017 Extension](https://marketplace.visualstudio.com/items?itemName=RobMensching.WixToolsetVisualStudio2017Extension).
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Building MSI was previously undocumented, correct?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Correct.

@seishun
Copy link
Contributor

seishun commented Nov 26, 2017

WiX for VS2017 requires an extension to be installed because of MSBuild changes

Do you know what changes caused this? The extension wasn't required for VS2015.

Passes the Windows SDK version to the MSBuild invocation that builds the MSI, to support SDKs other than 8.1.

How come this isn't necessary when building node itself?

@joaocgreis
Copy link
Member Author

Do you know what changes caused this? The extension wasn't required for VS2015.

VS2017 introduced the ability to install different editions side-by-side. MSBuild was changed to look for files in the directory relative to the installation in use, and ignore the global directory that was used for VS2015. The extension needs to be installed in the edition of VS2017 that will be used to build the MSI, it installs an extra copy of the targets files in the correct directory for MSBuild to find. Ref: wixtoolset/issues#5525 (comment)

How come this isn't necessary when building node itself?

It is, but Gyp handles that. The project files used to build the MSI are not generated by Gyp, so the SDK version needs to be passed explicitly. (IIRC there were attempts to generate with Gyp in the past, but it's not straightforward because of the WiX specific parts. Since the files are quite simple as they are, the effort is hard to justify.)

Copy link
Contributor

@seishun seishun left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

joaocgreis added a commit that referenced this pull request Nov 28, 2017
PR-URL: #17101
Reviewed-By: Nikolai Vavilov <vvnicholas@gmail.com>
@joaocgreis
Copy link
Member Author

Landed in 04566d3

@seishun thanks for the review! I'll move forward with the releases very soon.

@joaocgreis joaocgreis closed this Nov 28, 2017
MylesBorins pushed a commit that referenced this pull request Dec 12, 2017
PR-URL: #17101
Reviewed-By: Nikolai Vavilov <vvnicholas@gmail.com>
MylesBorins pushed a commit that referenced this pull request Dec 12, 2017
PR-URL: #17101
Reviewed-By: Nikolai Vavilov <vvnicholas@gmail.com>
@MylesBorins MylesBorins mentioned this pull request Dec 12, 2017
@gibfahn
Copy link
Member

gibfahn commented Dec 19, 2017

Any reason not to include this in the next v8.x release?

@joaocgreis
Copy link
Member Author

@gibfahn no, but it's not very important either. Feel free to include it if it lands cleanly.

gibfahn pushed a commit that referenced this pull request Feb 19, 2018
PR-URL: #17101
Reviewed-By: Nikolai Vavilov <vvnicholas@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
build Issues and PRs related to build files or the CI. doc Issues and PRs related to the documentations. windows Issues and PRs related to the Windows platform.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants