Added VS2022 project files.

[AraHaan]

Also replaced Itanium with ARM and ARM64 configurations. Itanium can be added back by those who do have it's build tools fully installed for it (or copied back from the vc14 directory manually).

cc: @madler

[AraHaan]

~~Also this might be a little delayed, I plan to also add a separate workflow to github actions meant to build zlib in windows, linux, and macos (cross compile for every OS) in just 3 jobs, store the results in artifacts, then a last job that then downloads the artifacts and generates a nuget package to zlib (officially) on every tag added to the repository so that way people using .NET can simply reference the nuget package and get the binaries for all of the major OS's they use. Completed.
Because for me on my code depending on someone to install zlib1g might give them the wrong version, likewise, running brew install zlib might give them the wrong version as well with no way to go back (because they scrub the version from the formulae). That is not the end of the problem when it comes to Windows users as well because there is no package manager and prebuilt libraries are too old (1.2.3 and not 1.2.13). As such I feel a nuget package for those using .NET Core is more practical.

note: the nuget packaging step would be as simple as:
dotnet pack -c Release ./contrib/nuget/nuget.sln and will generate: madler.zlib.redist.<version>.nupkg

[AraHaan]

It works on building nuget a nuget package for Windows at the moment.

[AraHaan]

It seems that I cant get ./configure to work on WSL to allow me to cross compile zlib on x64 to x86, x64, arm, and arm64.

[AraHaan]

[AraHaan]

I can test it on my mac when and if I get a chance to recharge it.

[AraHaan]

This will require that @madler or the other contributor (owner) to create a nuget.org account (if one does not already exist) and an api key and add it to their github secrets that github actions can then read.

[AraHaan]

Alright I think this should be ready to merge.

[Neustradamus]

To follow :)

[AraHaan]

And for MacOS I fixed the compile on (tested it on my macbook pro 2015)

[AraHaan]

The packages work on Windows, linux, and osx without issues.

[AraHaan]

So far, I see the changes in this pull request still works when I use them in my experimental zlib implementation that calls into the native library without issues. Infact, I think I have improved code that would normally use .NET System.IO.Compression in a way that allows the developer more control over what they want zlib to do (e.g. create deflate/zlib/gzip streams and any of the compression levels they want to use (because with my code they have access to them all unlike .NET's implementation)).

[AraHaan]

@madler mind reviewing this?

[madler]

I tried applying this before the 1.3 release earlier today, but it ran into a conflict. (Despite the "no conflicts" note below.) I think there was an issue with carriage returns.

[madler]

I checked, and it's only on the changes to contrib/vstudio/readme.txt. That file does consistently have carriage returns, so it seems like it should work, but it does not. Perhaps for now separate out the changes to that file to a different pull request, and I can retry what remains.

[madler]

Perhaps I should purge the carriage returns from all of the contrib/vstudio files. Does Visual Studio need them?

[AraHaan]

Perhaps I should purge the carriage returns from all of the contrib/vstudio files. Does Visual Studio need them?

Visual Studio has a habit of mixing newlines yes, perhaps the best option would be to mark those files specifically as CRLF.

[madler]

My question is: if I remove all of the carriage returns from any Visual Studio files that have them, will they still work ok?

[AraHaan]

My question is: if I remove all of the carriage returns from any Visual Studio files that have them, will they still work ok?

I think so, it's just that when edited when they become CRLF again.

[madler]

Ok. I removed the carriage returns from readme.txt, as well as from the patch, and I was able to apply it.

[AraHaan]

@madler You might want to carefully look at the version numbers in the vc17 folder and also change the vc143 references in the nuget.csproj to vc17 as well so nuget packaging would work.

hint: it says v1.2.13 on those files.

[madler]

Corrected. Thanks.

[Neustradamus]

@AraHaan: Good job for VS2022 support and @madler merging!

cc: @neacsum, @amyspark, @Mr-Clam, @mtl1979, @adamhathcock, @kaoh, @Spatzendame.

Now missing supports are VS2017 (VC15) and VS2019 (VC16).

Time to look for VS2017: @kiyolee, @yumetodo, @Sav0966, @tbeu, @jeking3, @lukasf, @praiskup, @bad-blue-bull, @vveider, @selgas, @sgarske, @vaerksted, @spaette, @AfterWaLifu, @AhmedX6, @irwir:

• Added VS2017 support. #243
• Add vc15 build files to contrib/vstudio. #270
• Update to VS2017 TechSmith/zlib#3
• https://github.com/vaerksted/zlib

Time to look for VS2019: @kouzhudong, @PieboyMcGillicuddy, @adammarks, @0ric1, @Tricky1975, @yyc12345, @jaykrell, @JuYanYan, @1939938853, @mrserb, @zchrissirhcz, @topwizprogramming:

• ReleaseWithoutAsm的编译。 #576
• Maint/migrate to vs2019 TechSmith/zlib#8

[yumetodo]

@Neustradamus
I couldn't catch the reason I was mentioned in this PR. What can I do for this PR which is already closed?

[Neustradamus]

@yumetodo: VS2022 has been added and VS2017/VS2019 are not yet added.
Previously, you have participated in this repository about VS2017 here: #243 :)

[AraHaan]

There will need to be some changes to the vc14 files I think to match the arch changes from here as some cleanup.

[AraHaan]

Also the contrib/nuget files is another place where version of zlib is stored and would need updates too, along with there is a missing .github/workflows/nuget.yml file (probably because of missing nuget api key?)

[madler]

Fixed version and date. I elected to not include the new workflow.

[Mr-Clam]

Regarding the line endings: can you configure git to handle this for you? If you add the specific files to a .gitattibutes file in the root folder with their text type and EOL handling, git on Windows will convert the endings to CRLF on checkout and back to LF when committing. There's even an example for *.vcproj files in the documentation: https://www.git-scm.com/docs/gitattributes

[Neustradamus]

Merged commit:

• d7de597
• 4a47c1b