Thread: VS2022: Support Visual Studio 2022 on Windows

During testing of the new Visual Studio 2022 Preview Version 4.1 from Microsoft I also tried PG14.0 on it.

The x64 version built without error!.

Even when this is only a preview version (the real thing is to expected soon) it seems appropriate to include the
supportto Postgres msvc tools directory. 

I followed the guideline of the patch msvc-2019-support-v4.patch for VS2019 support. New patch attached.

The only thing that will change later in the first non-preview release is the exact version number, which seems to
changeallways on every minor VS upgrade and is not used explicitely: 

$self->{VisualStudioVersion}        = '17.0.31717.71';

The patch is not invasive, so it should follow the practice of backpatching it to (most) supported versions.

I have tested the x64 compile and install with the release source code of PG14.0 from 2021-09-30.

Due to bad development environment I did not a full run of all tests afterwords.


Visual Studio is co-installable to an already existing VS version on the same machine (I had VS2019 installed) and is
separatelychoosable as compile environment. 

Compilation time and file sizes are almost identical, but the GUI promises a native 64bit implementation, so it may
appealingto use the new version. 

HELP NEEDED:

Please could somebody test the patch and enter it to the next commit fest?
(Only my second patch, not much experience with the tool chain :-( )

Another point is the failure of using VS2019/VS2022 for building the 32bit version, but this has to be discussed in
anotherthread (if the Windows 32bit Version is still important to support on newer VS Versions) 

Thanks for looking at it

Hans Buschmann

On Fri, 2021-10-01 at 15:15 +0000, Hans Buschmann wrote:
> During testing of the new Visual Studio 2022 Preview Version 4.1 from Microsoft I also tried PG14.0 on it.
> The x64 version built without error!.
> 
> Even when this is only a preview version (the real thing is to expected soon) it seems appropriate to include the
supportto Postgres msvc tools directory.
 
> 
> I followed the guideline of the patch msvc-2019-support-v4.patch for VS2019 support. New patch attached.
[...]
> HELP NEEDED:
> 
> Please could somebody test the patch and enter it to the next commit fest?

Thanks for that work; help with Windows is always welcome.

Please go ahead and add the patch to the commitfest yourself.
Testing will (hopefully) be done by a reviewer who has access to MSVC 2022.

Yours,
Laurenz Albe

On 10/4/21 6:13 AM, Laurenz Albe wrote:
> On Fri, 2021-10-01 at 15:15 +0000, Hans Buschmann wrote:
>> During testing of the new Visual Studio 2022 Preview Version 4.1 from Microsoft I also tried PG14.0 on it.
>> The x64 version built without error!.
>>
>> Even when this is only a preview version (the real thing is to expected soon) it seems appropriate to include the
supportto Postgres msvc tools directory.
 
>>
>> I followed the guideline of the patch msvc-2019-support-v4.patch for VS2019 support. New patch attached.
> [...]
>> HELP NEEDED:
>>
>> Please could somebody test the patch and enter it to the next commit fest?
> Thanks for that work; help with Windows is always welcome.
>
> Please go ahead and add the patch to the commitfest yourself.
> Testing will (hopefully) be done by a reviewer who has access to MSVC 2022.
>

I think we'll want to wait for the official release before we add
support for it.


cheers


andew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com

On Mon, Oct 04, 2021 at 08:21:52AM -0400, Andrew Dunstan wrote:
> I think we'll want to wait for the official release before we add
> support for it.

Agreed.  I am pretty sure that the version strings this patch is using
are going to change until the release happens.
--
Michael

During October Patchday 2021 the Visual Studio components where upraded too.

Now VS2022 Preview 5 is out, also Visual Studio 2022 RC is available to be used for production use (seems like our RC
withrespect to features). 

In the long of this process Microsoft announced the general availability of VS200 for Monday, November 8, see

https://devblogs.microsoft.com/visualstudio/join-us-november-8th-for-the-launch-of-visual-studio-2022/

This date is just some hours after the wrapup for our minor release on November 11.

Barring any objections I suggest to apply the patch just before this weekend in November to have the support for
MicrosoftsDeveloper Suite for the following 3 months available. (PS: no one is OBLIGUED to use the new version of VS,
theinterest for PG14 will grow with PG14.1 and this support effects only experienced users self-compiling on windows). 

I will watch the development in the first week of November and will update the patch to include the latest version
number.

It seems clear that VS2022 will take the 14.30 range as Version number (seen from the VC runtime versions installed)

Only the VisualStudioVersion (17.0.31717.71) will be changed like on EVERY update of a Visual Studio
installation/upgrade.

VS2019 is now on 16.11.5, Postgres never upgrades this number for older versions and always uses the initial number
whenintroduced (here 16.0.28729.10 for VS2019). 

So it seems safe to use a number of a version which can be used for building PG without errors.

Thanks

Hans Buschmann

________________________________________
Von: Michael Paquier <michael@paquier.xyz>
Gesendet: Montag, 11. Oktober 2021 08:03
An: Andrew Dunstan
Cc: Laurenz Albe; Hans Buschmann; pgsql-hackers@postgresql.org
Betreff: Re: VS2022: Support Visual Studio 2022 on Windows

On Mon, Oct 04, 2021 at 08:21:52AM -0400, Andrew Dunstan wrote:
> I think we'll want to wait for the official release before we add
> support for it.

Agreed.  I am pretty sure that the version strings this patch is using
are going to change until the release happens.
--
Michael

Hans Buschmann <buschmann@nidsa.net> writes:
> In the long of this process Microsoft announced the general availability of VS200 for Monday, November 8, see
> https://devblogs.microsoft.com/visualstudio/join-us-november-8th-for-the-launch-of-visual-studio-2022/
> This date is just some hours after the wrapup for our minor release on November 11.

Ugh, bad timing.

> Barring any objections I suggest to apply the patch just before this weekend in November to have the support for
MicrosoftsDeveloper Suite for the following 3 months available. 

Immediately before a release is the worst possible time to be applying
non-critical patches.  I think better options are to
(1) commit now, using the RC release's version as the minimum, or
(2) wait till just after our release cycle.

Of course, if we only plan to commit to HEAD and not back-patch,
this is all moot.

            regards, tom lane

On 10/13/21 3:49 PM, Tom Lane wrote:
> Hans Buschmann <buschmann@nidsa.net> writes:
>> In the long of this process Microsoft announced the general availability of VS200 for Monday, November 8, see
>> https://devblogs.microsoft.com/visualstudio/join-us-november-8th-for-the-launch-of-visual-studio-2022/
>> This date is just some hours after the wrapup for our minor release on November 11.
> Ugh, bad timing.
>
>> Barring any objections I suggest to apply the patch just before this weekend in November to have the support for
MicrosoftsDeveloper Suite for the following 3 months available.
 
> Immediately before a release is the worst possible time to be applying
> non-critical patches.  I think better options are to
> (1) commit now, using the RC release's version as the minimum, or
> (2) wait till just after our release cycle.
>
> Of course, if we only plan to commit to HEAD and not back-patch,
> this is all moot.
>
>         


No, we always try to backpatch these so that we can have buildfarm
animals that build all live branches.


I really don't see that we need to be in a hurry with this. There is no
requirement that we support VS2022 on day one of its release. Three
months really won't matter. Impatience doesn't serve us well here.


cheers


andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com

Now it is three days before release of VS2022.

I updated to the latest Preview 7 (= RC3) and recompiled PG14 64bit Release without issues.
There seem to be not many internal differences from previous versions in the tools used for building Postgres.

My intention for an early support is to catch the momentum for signalling to any user:  "We support current tools".
The risks seem non-existent.

Updated the patch to reflect the VisualStudioVersion for Preview 7, which is the version number compiled into the main
devenv.exeimage. 
This version number seems to be of no interest elsewhere in the postgres source tree.

I will reflect any updates after official release on monday, November 8

Hans Buschmann

> On 6 Nov 2021, at 10:29, Hans Buschmann <buschmann@nidsa.net> wrote:

> Updated the patch to reflect the VisualStudioVersion for Preview 7, which is the version number compiled into the
main devenv.exe image. 
> This version number seems to be of no interest elsewhere in the postgres source tree.

This patch fails to apply as it's anchored beneath the root of the source tree,
please create the patch from inside the sourcetree such that others (and the CF
patch tester) can apply it without tweaking:

--- a/postgresql-14.0_orig/doc/src/sgml/install-windows.sgml
+++ b/postgresql-14.0_vs2022/doc/src/sgml/install-windows.sgml

Also note that patches should be against Git HEAD unless fixing a bug only
present in a backbranch.

> I will reflect any updates after official release on monday, November 8

Any updates on this following the November 8 release?

--
Daniel Gustafsson        https://vmware.com/

Hello Daniel,

Thank you for looking into it.

My skills with git are minmal yet and I am working on a correct development platform, so sorry for any inconveniances
frommy side . 

When upgraded Microsoft jumped directly from Preview 7 to Preview 7.1 of VS2022 by skipping the release version of 7.0.

I had to install it on a different machine to test it with the final VS2022 version from november 8.

On both platforms the build of snapshot from 19.11.2021 is successfull but gives the following  warnings which seem not
correlatedto the proposed patch: 

Der Buildvorgang wurde erfolgreich ausgeführt.

"C:\pgdev\postgresql-15devel\pgsql.sln" (Standardziel) (1) ->
"C:\pgdev\postgresql-15devel\postgres.vcxproj" (Standardziel) (2) ->
(ClCompile Ziel) ->
  C:\pgdev\postgresql-15devel\src\backend\access\heap\pruneheap.c(858,18): warning C4101: "htup": Unreferenzierte
lokaleVariable [C:\pgdev\postgresql-15devel\postgres.vcxproj] 
  C:\pgdev\postgresql-15devel\src\backend\access\heap\pruneheap.c(870,11): warning C4101: "tolp": Unreferenzierte
lokaleVariable [C:\pgdev\postgresql-15devel\postgres.vcxproj] 

    2 Warnung(en)
    0 Fehler

(Meaning 2 unreferenced local variables in pruneheap.c)

The build produced .vcxproj files with ToolsVersion="17.0", so it recognized the new environment correctly.

I corrected some ommissions in _GetVisualStudioVersion in VSObjectFactory.pm.

Please find attached the corrected patch version v4.

Due to my restricted devlopment environment I appreciate if anybody can test the resulting binaries (but MS seems not
havechanged much on the C Build environment internally). 

Thanks

Hans Buschmann

On Sat, Nov 20, 2021 at 05:54:30PM +0000, Hans Buschmann wrote:
> My skills with git are minmal yet and I am working on a correct
> development platform, so sorry for any inconveniances from my side.

No need to worry here.  We all learn all the time.  I have been able
to apply your patch with a "patch -p2", which is fine enough.  If you
want to generate cleaner diffs, you could use a "git diff" or a "git
format-patch".  Folks around here rely on those commands heavily when
generating patches.

> On both platforms the build of snapshot from 19.11.2021 is
> successfull but gives the following  warnings which seem not
> correlated to the proposed patch:

That's fine by me.

> Der Buildvorgang wurde erfolgreich ausgeführt.
>
> "C:\pgdev\postgresql-15devel\pgsql.sln" (Standardziel) (1) ->
> "C:\pgdev\postgresql-15devel\postgres.vcxproj" (Standardziel) (2) ->
> (ClCompile Ziel) ->
>   C:\pgdev\postgresql-15devel\src\backend\access\heap\pruneheap.c(858,18): warning C4101: "htup": Unreferenzierte
lokaleVariable [C:\pgdev\postgresql-15devel\postgres.vcxproj] 
>   C:\pgdev\postgresql-15devel\src\backend\access\heap\pruneheap.c(870,11): warning C4101: "tolp": Unreferenzierte
lokaleVariable [C:\pgdev\postgresql-15devel\postgres.vcxproj] 
>
>     2 Warnung(en)
>     0 Fehler
>
> (Meaning 2 unreferenced local variables in pruneheap.c)

Those warnings are knows.  A commit from Peter G is at the origin of
that but nothing has been done about these yet:
https://www.postgresql.org/message-id/YYTTuYykpVXEfnOr@paquier.xyz

So don't worry about that :)

Glad to see that we should have nothing to do about locales this
time.  I have not tested, but I think that you covering all the areas
that need a refresh here.  Nice work.

+   # The version of nmake bundled in Visual Studio 2022 is greater
+   # than 14.30 and less than 14.40.  And the version number is
+   # actually 17.00.
+   elsif (
+       ($visualStudioVersion ge '14.30' && $visualStudioVersion lt '14.40')
+       || $visualStudioVersion eq '17.00')
+   {
+       return new VS2022Solution(@_);
+   }
Wow, really?  MSVC has not yet simplified their version numbering with
nmake.

+VC2017Project,VC2019Project or VC2022Project from MSBuildProject.pm) to it.
Nit: you should use a space when listing elements in a comma-separated
list.

-      method for compressing table or WAL data. Binaries and source can be
+      method for compressing the table data. Binaries and source can be
Diff unrelated to your patch.

I'll double-check your patch later, but that looks rather good to me.
Will try to apply and back-patch, and it would be better to check the
version numbers assigned in the patch, as well.
--
Michael

On Sun, Nov 21, 2021 at 10:41:17AM +0900, Michael Paquier wrote:
> I'll double-check your patch later, but that looks rather good to me.
> Will try to apply and back-patch, and it would be better to check the
> version numbers assigned in the patch, as well.

I have spent a couple of hours on that today, and applied that down to
10 so as all branches benefit from that.  There was a hidden problem
in 10 and 11, where we need to be careful to use VC2012Project as base
in MSBuildProject.pm.

Thanks, Hans!
--
Michael

Hello Michael,

thanks for your hard work and quick response!
It is very convenient to only use VS2022 for Windows from now on...

>Diff unrelated to your patch.

Sorry for the copysoft problem from the first version.

>Glad to see that we should have nothing to do about locales this
>time.  I have not tested, but I think that you covering all the areas
>that need a refresh here.  Nice work.

I think it is almost impossible to overestimate the value of such support from experienced hackers to others starting
theirjourney right now... 

I hope I can motivate you (and other experienced hackers) to give me some more support on my real project arriving
anytimesoon. It addresses hex_encoding (and more) targetting mostly pg_dump, but requires also some deeper knowledge of
generalinfrastructure and building (also on Windows). Stay tuned! 

PS: Does anybody have good relations to EDB suggesting them to target VS2022 as the build environment for the upcoming
PG15release? 

postgres=# select version ();
                          version
------------------------------------------------------------
 PostgreSQL 14.1, compiled by Visual C++ build 1931, 64-bit
(1 row)

Thanks!

Hans Buschmann

On Wed, Nov 24, 2021 at 10:00:19AM +0000, Dave Page wrote:
> It's extremely unlikely that we'd shift to such a new version for PG15. We
> build many components aside from PostgreSQL, and need to use the same
> toolchain for all of them (we've had very painful experiences with mix n
> match CRT versions in the past) so it's not just PG that needs to support
> VS2022 as far as we're concerned

Yes, I can understand that upgrading the base version of VS used is a
very difficult exercise.  I have been through that, on Windows for
Postgres..  As well as for the compilation of all its dependencies.

> - Perl, Python, TCL, MIT Kerberos,
> OpenSSL, libxml2, libxslt etc. are all built with the same toolchain for
> consistency.

Dave, do you include LZ4 in 14?  Just asking, as a matter of
curiosity.
--
Michael