.NET Standard version of Microsoft.Alm.Authentication

[mattjohnsonpint]

trafficstars

Please convert Microsoft.Alm.Authentication to a .NET Standard library so I can include in in a .NET Core application without getting compatibility warnings.

The dependency, Microsoft.IdentityModel.Clients.ActiveDirectory was already converted, targeting .NET Standard 1.4.

Thanks.

[whoisj]

Mr. DateTime how nice to see you here. :smile:

I started a conversion to .NET Standard awhile ago, but the effort is enormous and because there are WPF components in the library, there's no easy was to support this. If you only care about the `Microsoft.Alm.Authentication' then it is quite possible, but the CLI executables cannot be converted, neither can the GitHub nor the BitBucket authenticators.

Here's the WIP branch: https://github.com/whoisj/Git-Credential-Manager-for-Windows/tree/netstandard

If .NET Standard would resolve their differences with WPF this would all be much easier. Know anyone we can pester to the two technologies to play nicely together? :wink:

[mattjohnsonpint]

For the moment, I only care about the one library, because I'm working on a command line application.

I'll take a look at the work started, and maybe send a PR for this.

[whoisj]

I'll take a look at the work started, and maybe send a PR for this.

As a note, the code in master has changed significantly since that branch was created. You'll likely only be able to use it as a point of reference.

[mminns]

I've been thinking about the same thing, so I had a go:

https://github.com/Microsoft/Git-Credential-Manager-for-Windows/compare/master...mminns:experiment-master/netstandard?expand=1

Essentially...

Where applicable I converted existing projects to .NET Standard, where the existing project contains WPF code split these projects into a .NET standard core project + a Win32 project containing the WPF bits.

Likewise the Test projects have gone to .NET Core where possible.

All Framework projects are bumped to 4.7.1.

No PR partly because there is still a little bit of work to do with respect to moving Win32 specific code such a registry searching etc and renaming some projects etc. but mainly because its worth understanding if this is a broadly acceptable direction of travel? I think there is enough in the code above to show it would work.

Oh it does all work, or at least for the Bitbucket and GitHub support I've tested so far.

[mminns]

Increasingly off topic, but based on the work I did above, it is then possible to build a version of the GCMW on macOS etc. This branch substitutes console line interactions for GUIs, and only for Bitbucket so far and with no KeyChain storage etc, but other than that it compiles and runs doing everything it should be.

https://github.com/mminns/Git-Credential-Manager-for-Windows/tree/experiment-master/netstandard-xplat

I'm intrigued whether something like Xamarin.Forms new support for WPF, macOS and GTK opens the way to one GCM to rule them all on all platforms?

[whoisj]

@mminns meet @KirillOsenkov , I'm working with him on another project with a similar goal. He knows a ton (at least I think he does :neckbeard:) about making .NET work on Mac & Windows. I believe the ideal .NET Standard target is 1.4, but I might be wrong.

[mminns]

Hello @KirillOsenkov

I'll happily admit to being pretty new to Xamrin, Standard et al, so any pointers/advice is always appreciated.

Also any opinion on whether a move to .NET Standard + Win32 first then potentially onto a cross platform GCM has any potential as a realistic goal for this official release sometime in the future or if it is likely to always be a forked curiosity?

[KirillOsenkov]

Hey all, there are actually two options if you want to pursue getting this library to work on a Mac. One is .NET Core, and another is Mono. Unlike .NET Core, Mono supports running what we think of as "good old desktop assemblies". WPF is not supported by any of them, unfortunately, so that might be a problem.

[mminns]

So https://github.com/mminns/Git-Credential-Manager-for-Windows/tree/experiment-master/netstandard-xplat uses .NET core as the entry point, and all the WPF stuff is refactored into out additional add-on projects, so they are included in the main solution but excluded in the .NET Core/Standard only solution. Fr now that has no GUI at all, just substitutes in console prompts for now.

[mminns]

I actually came across an issue during my day job that might be relevant here.

We bumped Sourcetree to be .NET 4.7.1, + .NET Standard 2.0 we've had some reports from users of Windows 10 1507 LTSB that they can't upgrade to .NET 4.7.1. So far the information I've found is not clear cut, however the .NET 4.7.1 page talks about support for Windows 10 Creators and Fall Updates and then Win 7 & etc so 1507 is not explicitly mentioned.

Does anyone know if that is correct, is it really the case that LTSB release, it looks like support for it runs to 2025, cannot update to .NET 4.7.1? Seems....unhelpful... if true.

Is that why you suggested .NET Standard 1.4 above @whoisj ?

[whoisj]

@mminns I suggested a .NET Standard no higher than 1.4, because AFAIK that's the best level of support available for Mac OS.

[mminns]

Ah, actually my experimental branch uses .NET Standard 2.0 and does run on macOS.

[Logopher]

What's the latest on this? The Nuget package seems to work under .Net Standard, except I get a yellow triangle.

[whoisj]

I am not certain this repository is still active.