Update VS2019 to latest

[isuruf]

https://aka.ms/vs/16/release/vc_redist.x64.exe has a newer version

[h-vetinari]

Should we merge #46 first so this doesn't create conflicts?

[h-vetinari]

https://aka.ms/vs/16/release/vc_redist.x64.exe has a newer version

Quick question, why not /17 instead of /16? The microsoft docs say:

The Redistributable version must be at least as recent as the MSVC build toolset used to build your app. We recommend you use the latest Redistributable available for your version [...]
[...]
We recommend you install this version [/17] for all applications created using Visual Studio 2015, 2017, 2019, or 2022.

[h-vetinari]

Gentle ping @isuruf

[isuruf]

Because #46 is stalled at the moment.

[h-vetinari]

Because #46 is stalled at the moment.

Genuine question, how is it stalled? It looks ready and @mariusvniekerk seems to think so too? What would need to happen to unblock it?

[h-vetinari]

Because #46 is stalled at the moment.

Sidenote: If by chance you were responding to my "Quick question, why not /17 instead of /16?", then I did mean using the redistributable of VS17 for 2019 (instead of the native 16), because Microsoft says that the newest redistributable is still fine also for older toolchains.

Second sidenote: I'd be happy to create a PR that just does a vanilla update of 2019 with VS16, but I don't know how to extract the correct hashes.

[isuruf]

Sidenote: If by chance you were responding to my "Quick question, why not /17 instead of /16?", then I did mean using the redistributable of VS17 for 2019 (instead of the native 16), because Microsoft says that the newest redistributable is still fine also for older toolchains.

I don't know what this means.

Second sidenote: I'd be happy to create a PR that just does a vanilla update of 2019 with VS16, but I don't know how to extract the correct hashes.

See the comment at https://github.com/conda-forge/vc-feedstock/blob/main/recipe/meta.yaml#L22

[h-vetinari]

I don't know what this means.

Visual Studio has many versions; e.g. "Visual Studio 2019 16.11". I was considering if we should take the VS2022 redistributable (link with "/17" in it) even for the VS2019 toolchain (normally v16), because it's what Microsoft recommends. Also fine if we don't 🤷

[isuruf]

I still don't understand. What are you suggesting codewise?

[isuruf]

We were already using VS2019 redistributable for VS2017 toolchain. We'll do the same when #46 is merged.

[h-vetinari]

https://aka.ms/vs/16/release/vc_redist.x64.exe has a newer version
[...]
I still don't understand. What are you suggesting codewise?

I was suggesting to take the VS2019 redistributable from https://aka.ms/vs/17/release/vc_redist.x64.exe instead of https://aka.ms/vs/16/release/vc_redist.x64.exe, independently of #46. But since I don't really know how you managed to resolve the UUID etc. I cannot really propose the respective changes to the CBC.

[isuruf]

As I mentioned in my comment, see https://github.com/conda-forge/vc-feedstock/blob/main/recipe/meta.yaml#L22
(Use your favourite download tool to get the redirect URL for https://aka.ms/vs/16/release/vc_redist.x64.exe)

[isuruf]

VS2019 redistributable from https://aka.ms/vs/17/release/vc_redist.x64.exe

There is no VS2019 redistributable in that link. Only the VS2022 redistributable which is compatible with VS2019

[h-vetinari]

For posterity:

>curl -ILSs https://aka.ms/vs/16/release/vc_redist.x64.exe | grep "Location:"
Location: https://download.visualstudio.microsoft.com/download/pr/b929b7fe-5c89-4553-9abe-6324631dcc3a/296F96CD102250636BCD23AB6E6CF70935337B1BBB3507FE8521D8D9CFAA932F/VC_redist.x64.exe
>curl -ILSs https://aka.ms/vs/17/release/vc_redist.x64.exe | grep "Location:"
Location: https://download.visualstudio.microsoft.com/download/pr/7331f052-6c2d-4890-8041-8058fee5fb0f/CE6593A1520591E7DEA2B93FD03116E3FC3B3821A0525322B0A430FAA6B3C0B4/VC_redist.x64.exe

VS2019 redistributable from https://aka.ms/vs/17/release/vc_redist.x64.exe

There is no VS2019 redistributable in that link. Only the VS2022 redistributable which is compatible with VS2019

I get that 17 <-> VS2022 and 16 <-> 2019; however, as you see from the locations above, the files appear to be different, hence the question if we want to use the "17" one (nominally for VS2022) also for upgrading the VS2019 toolchain. It seems you're in agreement that this should work.

[isuruf]

No, you are getting confused. We want to package both VS2019 and VS2022 redistributables, but users will use VS2022 redistributable by default. So, please send a PR to just update VS2019 toolchain with the 16 one.
This was a condition for VS2019 upgrade and I forgot about it. If there's no PR, I'll downgrade to VS2017 in conda-forge-pinning-feedstock

[h-vetinari]

This was a condition for VS2019 upgrade and I forgot about it. If there's no PR, I'll downgrade to VS2017 in conda-forge-pinning-feedstock

Excuse me, but what kind of interaction is that? I asked how to do this, you didn't respond (OK, happens), then I remind you of this topic, and now you start making vague ultimatums? Not cool

No, you are getting confused.

I wasn't; my question since the beginning has been whether we want to just take the VS2022 redistributable even for the purpose of this issue ("Update VS2019 to latest"). It's fine if the answer is no, but it wasn't clear to me, given MS's guidance.

[isuruf]

Excuse me, but what kind of interaction is that? I asked how to do this, you didn't respond (OK, happens), then I remind you of this topic, and now you start making vague ultimatums? Not cool

Without either #46 or with an update to VS2019, the packages that we are producing are broken on users without an up-to-date system C++ redistributables. If this is not fixed, we should revert to VS2017 to make sure we are not breaking something.

Not cool

Sorry about that. As I mentioned this to you before, you replying fast to threads without taking the time to think makes me lose my cool. Please take time to think things through.

I wasn't; my question since the beginning has been whether we want to just take the VS2022 redistributable even for the purpose of this issue ("Update VS2019 to latest"). It's fine if the answer is no, but it wasn't clear to me, given MS's guidance.

You are suggesting that we package VS2022 redistributable inside vs2015_runtime=14.29.30037 which is the version for VS2019 redistributable. That is confusing.

[h-vetinari]

Without either #46 or with an update to VS2019, the packages that we are producing are broken on users without an up-to-date system C++ redistributables. If this is not fixed, we should revert to VS2017 to make sure we are not breaking something.

I guess you mean that the vs2019 toolchain coming though the images will have a slightly newer version than the redistributable, and therefore a small chance to break packages? That's fair enough.

#48

Sorry about that. As I mentioned this to you before, you replying fast to threads without taking the time to think makes me lose my cool. Please take time to think things through.

Please don't assume that I haven't thought about things. I'm not immune to brainfarts, but I often thought about things, and in this case, you were continuously misunderstanding the question I tried to ask, so it's easy to just clarify that point. So, in turn, please take some time to read & think about what I wrote as well.

You are suggesting that we package VS2022 redistributable inside vs2015_runtime=14.29.30037 which is the version for VS2019 redistributable. That is confusing.

I'll admit that I'm still fuzzy on how certain pieces fit together, but that was indeed the question that I had, given MS' explicit statement to that effect that I had quoted.

[isuruf]

So, in turn, please take some time to read & think about what I wrote as well.

Sure. In the meantime, can you tell me the reason for your comment "But since I don't really know how you managed to resolve the UUID etc." after I mentioned the link https://github.com/conda-forge/vc-feedstock/blob/main/recipe/meta.yaml#L22? Was that not clear enough?

I'll admit that I'm still fuzzy on how certain pieces fit together, but that was indeed the question that I had, given MS' explicit statement to that effect that I had quoted.

Even MS don't redirect the 16 link to the 17 link. What you are asking for is to redirect the 16 link to 17 link.

[h-vetinari]

In the meantime, can you tell me the reason for your comment "But since I don't really know how you managed to resolve the UUID etc." after I mentioned the link https://github.com/conda-forge/vc-feedstock/blob/main/recipe/meta.yaml#L22? Was that not clear enough?

I had tried when you first opened this issue to get at that link in various ways. It had not occurred to me until "your favourite download tool" that curl probably can do this, and so I managed to find the solution.

[isuruf]

Ah. Would you mind improving that comment there then?