adjust CI and docker for VS2019 compatibility using VS2022 #2640
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
ericoporto
force-pushed
the
win-docker-vs2019
branch
from
66a8c19 to
100dcea
Compare
|
There is something wrong, I tried to run in a clean environment using the new Windows Sandbox feature, and got the above error. I also noticed that the AGS installer needs to be adjusted in the entry because the VC Redist is named as VC 2015, but it's the VC 2015+ now (also known as Microsoft Visual C++ 2015-2019 Redistributable (x86) - 14.29.30133). It does run on my machine though, just not in the clean one, so I guess it has to do with the VC Redist.
I don't know what is wrong yet... I think the important things it the following But I don't get yet what is wrong. Edit: turns out using the vc redist corresponding to v143, 14.42.34433, actually fixes this |
ericoporto
force-pushed
the
win-docker-vs2019
branch
from
7f1d078 to
fa287de
Compare
ericoporto
force-pushed
the
win-docker-vs2019
branch
3 times, most recently
from
52b454d to
9ee1950
Compare
- Upgraded PlatformToolset from v140 to v142 - Updated Windows SDK version from 8.1 to 10.0
- Upgraded PlatformToolset from v140 to v142; and v141_xp for _XP configs. - Updated Windows SDK version from 8.1 to 10.0 - In .props files change references to LIB locations, by adding _VS19 prefix; this is to be able to have both VS15 and VS19 versions of libs in the same enviroment.
- adjust vc redistributables for used VC toolsets (and also adjust sha256 in verification script) - upgrade nuget command line to 6.12.1 - new base docker with Visual Studio 2022 Community - fix env vars for new vs2019 lib compatibility - chocolatey deprecated shims, use proper `choco install` - use VsDevCmd instead of vsvarall, but don't specify host arch - drop Win8.1 sdk
ericoporto
force-pushed
the
win-docker-vs2019
branch
from
9ee1950 to
18a66ee
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
fix #1508
built on top of #2591
Some notes:
Visual Studio 2022 build tools image did not work with CMake. It seems the big issue is that Visual Studio 2022 Build Tools doesn't correctly installs all VC tools, the 142 (VS 2019, aka VC 14.29) vc tools seems to install most correctly but it doesn't seem to proper have the CLI/C++ tools working, and the VC 143 (VS 2022, aka VC 14.43) doesn't properly create the cl.exe in place.
I used VS 2022 community instead, which worked fine on the Windows container and properly install packages - though this means the image is slightly larger (21.96 GB in the base image). Here is the docker file for the base image
https://raw.githubusercontent.com/ericoporto/min-ags-dev-env/211537671e66f8e6df0c6fcd0826a529b535acd5/Dockerfile
I opted to build this package separately because installation of VS2022 takes a long time - a little more than an hour, enough to fail Cirrus CI. I built this image in my computer too, since the GHA that currently exists for docker fails with Windows Containers.
I also kept the Windows Server 2019, in theory it could work with a newer windows (and move from the LTSC2019 base), but the cirrus ci official windows container images are still those, so I opted to keep with what is currently tested.
The resulting image has
TO-DO:
"windows-container"repository right in the organization so that I can move the base image to there (using the GitHub Packages feature), this would also be an opportunity to document a how-to on windows containers to explain things