-
Notifications
You must be signed in to change notification settings - Fork 19
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
GPII-4355: Updated build scripts and projects to use VS2017 build tools #181
base: master
Are you sure you want to change the base?
Conversation
Could one of the admins verify that these changes are reasonable to test? If so, please reply with "ok to test". |
ok to test |
CI job failed: https://ci.gpii.net/job/gpii-app-tests/981/ |
While we're waiting to update CI to use VS2017 build tools (instead of VS2013/VS2015), here is the log of a manual VS2017 checkout/build from a local VM. [Build successful] And a screenshot of the results of "npm start" (and then clicking on the Morphic icon to bring up the QuickStrip). |
CI job failed: https://ci.gpii.net/job/gpii-app-tests/982/ |
ok to test THis happened the other day, too:
|
CI job failed: https://ci.gpii.net/job/gpii-app-tests/983/ |
This can be fixed, in gpii-windows, with GPII/windows@29440be
|
SG> This can be fixed, in gpii-windows, with GPII/windows@29440be On my test machine, the 4.5.1 SDK's mscorlib is at that location regardless of ia32, amd64 or arm64 architecture (with the "(x86)" missing on ia32...which the updated build script accounts for). Are we missing the .NET 4.5.1 Framework SDK in the build machine install? Are the files located somewhere else in CI? What was the reason for the path override originally? |
This PR, combined with the windows/GPII-4355 PR, should fully enable Morphic for Windows to compile using modern (VS2017) developer tools and Node.js v10.16.3.
Please note that this branch updates package.json to pull in the respective windows GPII-4355 repo; that should of course be modified to point to the proper merged "windows" repo in github.com/GPII.
Critical: developers must upgrade their developer environment to Visual Studio 2017. The new build scripts use Microsoft's new "vswhere" utility (included with VS2017+) to locate MSBuild, CSC, environment variables, etc. This is a hard fork in the road...and we will need all the developers on our team (plus the CI environment) to move to VS2017 when this goes "live" in master.
For the future: The $visualStudioVersion PowerShell variable has been designed to support either a specific version (e.g. "15.0" for VS2017) or a range (e.g. "[15.0,16.0)" as an inclusive range for any VS2017'ish releases from v15.0 to v15.9999999999). This means that as we want to start adding support for VS2019 or other newer releases, we can simplly update the $visualStudioVersion variable to include a wider range of compiler versions. Our build may indeed be compatible with VS2019 as well, but I have not tested with VS2019 due to the fact that Electron still uses VS2017 in their documentation.