-
Notifications
You must be signed in to change notification settings - Fork 1.9k
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
Migrate from .NET Framework on Windows #113
Comments
So your readme straight up lies saying "...built on .NET Core"? Could be "...built on .NET" or "...built on .NET Framework and soon .NET Core" instead. |
No. The macOS build is built on .NET Core. So the readme is merely inacurate. |
@mjcheetham would you accept a PR that migrates the Windows bits to .NET Core? Moving to .NET Core should also unlock building natively for Windows ARM64. We're working on a semi-native ARM64 Git for Windows and while using the x86 GCMC works for now (through emulation), having a native binary would be fantastic. Is there a specific reason why you want to use an embedded browser rather than the user's default browser? This is the official recommendation:
Note to self: this might be a viable approach for an embedded Web UI |
Hi @dennisameling,
There are/were a few reasons:
We're not wedded to the .NET Framework as the target runtime on Windows but need to consider "moving the user's cheese" for the UX. 🧀 We'd also need to be mindful of the impact of shipping a copy the .NET Core runtime with GCM Core has on installer/zip file size, and how bundlers of GCMC would respond. Git for Windows's libexec\git-core directory would now contain a helluva lot of binaries for example! We can look at using the single-file publishing model of course to reduce the number of binaries shipped, and trimming to reduce the size. .NET 5 would likely be the preferred target runtime to do this trimming and single-file publishing with, due to several improvements made in the latest release.
As I mentioned in this issue "We can use the Ideally MSAL.NET would expose the WinForms-based embedded browser when running on .NET Core on Windows, but that seems to be combined with/is waiting on their replacement of the old browser with "WebView2" (which itself has runtime distribution considerations). So to answer your question, "yes" we would accept a PR to move to .NET Core on Windows, but we'd also need to ensure the following at the same time:
(Note: on macOS we've recently removed the embedded browser workaround/native helper to rely on the default browser flow, but on Windows we have to be more considerate of the experience change that would bring with the various consumers of GCM which includes Sourcetree and Visual Studio). |
I'm in favor of this change - being on two different and diverging runtimes isn't hurting us now but smells like the kind of tech debt which will hurt us later. Let's sequence this after a move to .NET 5, and we can spend the time between now and then figuring out how much 🧀 -moving we'll do to VS and Sourcetree. |
As nice as this would be, the tradeoffs still don't really make sense. The bloat of bringing along the runtime is unacceptable to our distribution partners in Git for Windows, and the Win7 story would get needlessly complicated. We should reevaluate this when: 1) we can drop Win7 and 2) some .NET flavor can get us down to 3x our size (as opposed to the 10x it is in .NET 5). |
Update on dropping .NET Framework on Windows.. work in MSAL, .NET 6 and 7 means that we may be at a point where we can consider trying this again.
There is still one aspect that means we may not be able to fully embrace single-file publishing and that's Windows 7 support. Msys2 (that Git for Windows depends on) has signaled that it will be dropping Windows 7 and 8.0 support: https://github.com/msys2/msys2.github.io/blob/source/web/news.md#2023-01-15---dropping-support-for-windows-7-and-80 |
|
Update on Windows 7 issues and single-file publishing.. the latest docs indicate that we can use single file publishing if we are using the .NET 6.0.3 runtime or later:
https://learn.microsoft.com/en-us/dotnet/core/deploying/single-file/overview |
This work should now be entirely achievable with the latest .NET 8 release candidate, from my testing! 🎉 We can logically break this work down in to a few steps:
|
That might be a slight issue. Cygwin has explicitly announced that they intend to keep supporting Windows 8.1 for the forseable future. AFAIK Msys2 and Git for Windows have similar plans. But .NET 7 dropped support for Windows 8.1. |
Historically, we have been following their lead in Git for Windows. Because we had to. Like, when we still wanted to support Windows XP and Cygwin ended support for Windows XP, Git for Windows could not bear the torch to resurrect and maintain that support. In this instance, I think it might actually be the other way around: Git for Windows could say that, you know, Windows 8.1 support ended on January 10, 2023. If you need to use Git on that Windows version, either build it yourself or use an older version of Git for Windows. I'm not saying that this decision has been made, though. I'm just saying that it is an option, maybe the easiest option we have. |
We could also potentially disallow the Git Credential Manager option in the Git for Windows installer on Windows 8.1 and recommend a standalone install of the latest .NET Framework based version in that situation. |
We are currently not actually using the .NET Core on Windows. We should actually use the .NET Core runtime!
The reason we are currently using .NET Framework instead is because MSAL does (didn't) support embedded browser on Windows when targeting .NET Core or .NET Standard. We can use the
UseCustomWebUi
extension point to restore this functionality.The text was updated successfully, but these errors were encountered: