Skip to content
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

installer: bump NetFx version requirement from 4.5.1 -> 4.6.1 #329

Merged
merged 3 commits into from
May 5, 2022

Conversation

y2kbugger
Copy link

We already require Fx4.6.1, but the installer checks for Fx4.5.1

Signed-off-by: Zak Kohler git@y2kbugger.com

I used the lower of the two 4.6.1 checks as that is how 4.5.1 was done previously.

@mjcheetham

.NET Framework 4.6.1
On Windows 10 November Update systems: 394254
On all other Windows operating systems (including Windows 10): 394271

@dscho dscho changed the title Fix Fx version requirement from 4.5.1 -> 4.6.1 installer: bump NetFx version requirement from 4.5.1 -> 4.6.1 Feb 24, 2021
@dscho
Copy link
Member

dscho commented Feb 24, 2021

.NET Framework 4.6.1
On Windows 10 November Update systems: 394254
On all other Windows operating systems (including Windows 10): 394271

Where does that information come from?

Also, could you amend the commit message to start with "installer: bump NetFx version requirement from 4.5.1 -> 4.6.1", and then continue by specifying what requires v4.6.1, accompanied by a link to the evidence (e.g. to the code in GCM Core or GCM for Windows that shows how it won't work with older versions)?

@dscho
Copy link
Member

dscho commented Feb 24, 2021

Oh, sorry, I forgot to thank you for this valuable contribution!

I'm not the domain expert on this, so I'll leave it to @mjcheetham to give their 👍 before merging.

@y2kbugger
Copy link
Author

Version detection spec comes from here:
https://docs.microsoft.com/en-us/dotnet/framework/migration-guide/how-to-determine-which-versions-are-installed

To be fair, @mjcheetham noticed the discrepancy, mentioned in an email when asking about another issue:

One interesting thing to note.. the Git for Windows installer is checking for .NET Framework 4.5.1, but actually it should be checking for 4.6.1 (which is what GCM Core requires on Windows) – this is a bug

@dscho
Copy link
Member

dscho commented Feb 24, 2021

Version detection spec comes from here:
https://docs.microsoft.com/en-us/dotnet/framework/migration-guide/how-to-determine-which-versions-are-installed

To be fair, @mjcheetham noticed the discrepancy, mentioned in an email when asking about another issue:

One interesting thing to note.. the Git for Windows installer is checking for .NET Framework 4.5.1, but actually it should be checking for 4.6.1 (which is what GCM Core requires on Windows) – this is a bug

Excellent! Could you add that information (together with a link to @mjcheetham's comment) into the commit message? Then we're golden.

rimrul
rimrul previously requested changes Feb 25, 2021
installer/install.iss Outdated Show resolved Hide resolved
installer/install.iss Outdated Show resolved Hide resolved
@y2kbugger
Copy link
Author

Since this change isn't trivial like the first, I want to build and test that it works as expected. I'm looking into options for this.

RdbGitCredentialManager[GCM_Core].Checked:=True;
end;
// Auto-upgrade GCM to GCM Core in version v2.29.0
if RdbGitCredentialManager[GCM_Classic].Checked and ((PreviousGitForWindowsVersion='') or IsUpgrade('2.29.0')) then begin
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not keep this block here, but enhance the conditionals so that e.g. the auto-upgrade won't happen if RdbGitCredentialManager[GCM_Core].Enabled evaluated to True?

Copy link
Author

@y2kbugger y2kbugger Mar 1, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My reason is that denesting the conditionals reduces complexity/ improves maintainability. The tradeoff is that the upgrade/replay execute regardless, and are the repealed by the version checks. but I think that is better than having a combinatorially nested ifs, as that would involve duplicating at least some of the checks.

If you look at structure of final code (rather than just diff) it is:

  • Replay previous
  • Upgrade to Core
  • Version Guard for GCM Core
  • Version Guard for GCM Classic

Did notice one thing that might need changed (based on testing): if both guards get triggered (and unchecked and disabled), do we need to manually set [GCM_None].Checked:=True, or do radios enforce that once option is chosen.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My rationale: if you put the version guard before replying, you can automatically reject an invalid replay.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On that note, @y2kbugger, have you tested what happens if GCM_Core is checked during a replay, but then disabled because of the version check (using a bogus minimum version to force it to be disabled would be the easiest way to test that, I think)?

@mjcheetham
Copy link
Member

I'm not the domain expert on this, so I'll leave it to @mjcheetham to give their 👍 before merging.

This is correct. GCM Core requires .NET Framework 4.6.1 be installed to run. GCM "classic" only requires 4.5.1.

Heads-up.. a future version (the next one?) of GCM Core will require .NET Framework 4.7.2.

Going even further in to the future, GCM Core will not require any version of .NET Framework (we will bundle/statically link the .NET Core CLR and libraries).

@y2kbugger
Copy link
Author

My reason is that denesting the conditionals reduces complexity/ improves maintainability. The tradeoff is that the upgrade/replay execute regardless, and are the repealed by the version checks. but I think that is better than having a combinatorially nested ifs, as that would involve duplicating at least some of the checks.

If you look at structure of final code (rather than just diff) it is:

  • Replay previous
  • Upgrade to Core
  • Version Guard for GCM Core
  • Version Guard for GCM Classic

Did notice one thing that might need changed (based on testing): if both guards get triggered (and unchecked and disabled), do we need to manually set [GCM_None].Checked:=True, or do radios enforce that once option is chosen.

I think i made the required changes and unless my reasoning(or code) is either wrong or the other style is just preferred this is ready to be tested.

@dscho
Copy link
Member

dscho commented Mar 10, 2021

a future version (the next one?) of GCM Core will require .NET Framework 4.7.2.

@mjcheetham this happened with the latest release, correct?

@mjcheetham
Copy link
Member

a future version (the next one?) of GCM Core will require .NET Framework 4.7.2.

@mjcheetham this happened with the latest release, correct?

Yes. The current latest GCM Core release on Windows targets .NET Framework 4.7.2.
https://github.com/microsoft/Git-Credential-Manager-Core/blob/3fc6791abf670dd08c0620e8a6c642f7104c128a/src/windows/Payload.Windows/Payload.Windows.csproj#L6

@dscho
Copy link
Member

dscho commented Dec 6, 2021

I guess now that we no longer ship the old Git Credential Manager for Windows, this PR would become substantially simpler?

@dscho
Copy link
Member

dscho commented Apr 29, 2022

I guess now that we no longer ship the old Git Credential Manager for Windows, this PR would become substantially simpler?

@mjcheetham I guess that was a question for you?

@mjcheetham
Copy link
Member

I guess now that we no longer ship the old Git Credential Manager for Windows, this PR would become substantially simpler?

@mjcheetham I guess that was a question for you?

GCM "Core" still requires .NET Framework 4.7.2.

@dscho
Copy link
Member

dscho commented May 4, 2022

I guess now that we no longer ship the old Git Credential Manager for Windows, this PR would become substantially simpler?

@mjcheetham I guess that was a question for you?

GCM "Core" still requires .NET Framework 4.7.2.

Oh, so we have to change

// Restore the settings chosen during a previous install, if .NET 4.5.1
// or later is available.
if DetectNetFxVersion()<378675 then begin
, but to what value?

@rimrul
Copy link
Member

rimrul commented May 5, 2022

Oh, so we have to change

// Restore the settings chosen during a previous install, if .NET 4.5.1
// or later is available.
if DetectNetFxVersion()<378675 then begin

, but to what value?

Probably 461808. See https://docs.microsoft.com/en-us/dotnet/framework/migration-guide/how-to-determine-which-versions-are-installed#detect-net-framework-45-and-later-versions

dscho added 2 commits May 5, 2022 11:22
When users cannot choose to use Git Credential Manager, they're
frequently puzzled why it is disabled.

Let'd give them a hint.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
We forgot to bump the requirement when Git Credential Manager started
requiring a later version than 4.5.1.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
@dscho dscho requested a review from mjcheetham May 5, 2022 09:31
@dscho dscho dismissed rimrul’s stale review May 5, 2022 09:32

I updated the branch, the patches now look very different and need a new review

@dscho
Copy link
Member

dscho commented May 5, 2022

@rimrul could I bother you for a re-review?

Copy link
Member

@mjcheetham mjcheetham left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Technically looks good (correct version check etc), but I'd change the UI to specify "Framework".

installer/install.iss Outdated Show resolved Hide resolved
installer/install.iss Outdated Show resolved Hide resolved
Typically, when referring to `.NET`, one apparently refers to the Core
CLR, not to the Desktop CLR we mean here.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
@rimrul
Copy link
Member

rimrul commented May 5, 2022

On a side-note: The CI seems to struggle a lot with installing the build-installers flavor of the SDK. I think it might be related to the fact that when I try to download the SDK artifact manually, it reliably slows to a crawl after around 20MB. This doesn't seem to happen with the full-sdk artifact, though.

Copy link
Member

@mjcheetham mjcheetham left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

@dscho
Copy link
Member

dscho commented May 5, 2022

The CI seems to struggle a lot with installing the build-installers flavor of the SDK

Right, this is actually tracked in git-for-windows/setup-git-for-windows-sdk#336... I just didn't have time yet to look into it more closely.

I think it might be related to the fact that when I try to download the SDK artifact manually, it reliably slows to a crawl after around 20MB.

Potentially.

I think we should look into using partial clones, and parallel checkout, anyway. We could even just initialize an empty repository, get the commit SHA as well as the contents of .sparse/ via the API, and then fetch the objects in a batch. It's a bit tricky to get this right so that the performance does not tank, but I think this might be better than going forward with these git-sdk-64-extra-artifacts job artifacts.

@dscho dscho merged commit 0dff628 into git-for-windows:main May 5, 2022
dscho added a commit that referenced this pull request May 5, 2022
The installer [now verifies that .NET Framework 4.7.2 is
available](#329)
before offering Git Credential Manager (GCM) as an option (because
it is required for GCM to work).

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants