Migrate from .NET Framework on Windows

[mjcheetham]

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.

[Regenhardt]

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.

[rimrul]

No. The macOS build is built on .NET Core. So the readme is merely inacurate.

[dennisameling]

@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:

We recommend that you use the platform default, and this is typically the system browser. The system browser is better at remembering the users that have logged in before. If you need to change this behavior, use WithUseEmbeddedWebView(bool)

Note to self: this might be a viable approach for an embedded Web UI

[mjcheetham]

Hi @dennisameling,

Is there a specific reason why you want to use an embedded browser rather than the user's default browser?

There are/were a few reasons:

1. To maintain the existing behaviour from Git Credential Manager for Window (GCMW) which used an embedded browser pop-up via the old ADAL auth library
2. Without an intermediate window (take a look at GitHub and Bitbucket's UI flows with OAuth) where we can tell the user we're about to start a new browser window, just launching a browser window for some random authentication isn't a great user experience.

[..] would you accept a PR that migrates the Windows bits to .NET Core?

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.

Note to self: this might be a viable approach for an embedded Web UI

As I mentioned in this issue "We can use the UseCustomWebUi extension point to restore this functionality." - it's just a case of having enough time to get around to do that 😉

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:

• Single-file distribution model (& .NET 5?)
• Assembly trimming (& .NET 5?)
• Embedded browser support for Microsoft authentication, OR..
• ..some GUI that indicates we're about to launch a browser for the user.

(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).

[vtbassmatt]

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.

[vtbassmatt]

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).