Investigate UWP support

[chrisdunelm]

An item from future planning in #787.

[Sergio0694]

I have a question, just out of curiosity: since the library targets .NET Standard 1.3, and that applies to .NET Core as well (so to UWP), how is it possible that right now the latest version (1.25.8xx) can't be installed in a UWP project due to incompatible references?
I mean, I thought that having a .NET Standard library guaranteed that it could run on any supported runtime (so .NET Core in this case) without having to worry about dependencies, once they were correctly added to the original .NET Standard project.
Thank you for all your help, and I'm happy to see the UWP support finally made it into its own issue with a target release as well! 😄

[chrisdunelm]

@Sergio0694 I also have the same question. I also expected that by supporting netstandard1.3 it should be installable in a UWP project; although there may still be platform-specific problems that occur at runtime. E.g. the netstandard1.3 FileDataStore is almost certainly not suitable for UWP.
This investigation is to discover what is causing the incompatibility; understanding why native compilation is also causing problems; and how to perform testing on the UWP platform. The ability to have CI testing on UWP(+native) is essential as we can't offer support for a platform without it.

[mateusz-piasecki]

Do we have any timeframe for settings timeframes?

[Sergio0694]

Hello @chrisdunelm - I've tried to update the library to the 1.26.2.862 version in my UWP project and it still can't get the packages to install correctly due to that missing System.Diagnostics.Process reference, just wanted to let you know that in case it might help investigating the issues.

I'm not sure how's that even possible now, since you said the .NETStandard library (and UWP should target the .NETStandard 1.3 package, since it supports up to .NETStandard 1.4 at the moment) doesn't have any other dependencies other than Newtonsoft.Json (which isn't the issue here). I mean, where is that System.Diagnostics.Process reference coming from? If that's from within the .NetStandard API set, how's that possible that it's causing these issues on a UWP project?

Anyways, as for the UWP version of the library, in case you can't get the current .NETStandard 1.3 package to work with it, the Fall Creator's Update should bring .NETStandard 2.0 support for UWP apps (.NETStandard 2.0 will also be supported by .NET Framework, .NET Core and Xamarin), and that should include a ton of new supported APIs, so if you plan to release an updated version of the library that targets .NETStandard 2.0, I guess that could help targeting all the different platforms more easily.

[chrisdunelm]

@Piachu91 Sorry, no; we don't have a timeframe for this.

@Sergio0694 The System.Diagnostics.Process dependency is coming from the Google.Apis.Auth; see the csproj here. This dependency is required to launch a browser during OAuth. I anticipate that we'd add a new uap10.0 target to our nupkgs for UWP support, which would not include that dependency. My statement in the v1.26.2 release notes about have no third-party dependencies except Newtonsoft.Json is slightly misleading; what I really mean is no non-Microsoft dependencies, I'll edit it to clarify.

[Sergio0694]

@chrisdunelm Oh I see, now I understand the issue, thanks!
Can't wait for version 1.27 to be finished so you guys can start looking into the UWP support, I hope it will be easy enough to fix the problems that are present on that platform (.NETStandard should make that easier, in theory) 😄

[LindaLawton]

If you want to use the library with service account or an API Key you can do it by adding the dlls directly in the project. I can give you a list of the dlls needed.

Oauth2 is going to require changes to the library itself.

[Sergio0694]

@LindaLawton Thanks for your help - unfortunately last time I checked (back with version 1.23.something when I could still get the library to compile in my UWP app, before the .NET Native toolchain was updated) there was another issue ( #838 ) that made it impossible to use the library (at least in my case).

So I guess I'll just have to wait for the official UWP investigation so that hopefully you guys will find a workaround for that issue, it's probably just the .NET Native compiler that's messing something up, as the debug build of the app worked perfectly fine (it was just the release build that had that issue).
Thanks again though 😄

[Sergio0694]

@chrisdunelm Hello Chris, I just saw that this issue has been moved to version 1.29 and I was just wondering: since I saw that all of the original issues in version 1.27 are already completed by now (even though the original due date was the 5th of June), and the only remaining issue (that .NET Core support for an API) has been moved to version 1.28, is this just a formality so that you'll release version 1.27 sooner and 1.28 the 5th (so the overall schedule will more or less remain the same), or do you plan to add more issues to version 1.28 and to postpone the actual version 1.29 with the UWP investigation?

Just curios, I was trying to understand when to expect the works on the UWP support to start, I'm looking forward to be able to use the library again in my app! Keep up the good work! 😄

[chrisdunelm]

@Sergio0694 I expect v1.27 to be released tomorrow (1st June); but if anything blocks it, then it will be released on Monday 5th (we generally don't do releases on Fridays, Saturdays or Sundays).

The ASP.NET Core auth issue #933 is moved to v1.28 because I don't want it to block the v1.27 release, and I suspect it's going to take some time to get done. This is because I've not done any ASP.NET Core development, and I need to understand how auth fits into ASP.NET Core before deciding how best to support Google Auth.
At the moment I don't anticipate any more issues being brought into v1.28, but it's possible it will happen.
I'll be putting a date on v1.28 shortly, but it definitely won't be June 5th :( - and as always, these dates are subject to change.

After v1.28 is done, I'll be starting on UWP for v1.29

Please note that I do have work outside of this repo, so if progress appears to stall for a while, it's probably just because there's other work I'm needing to do.

[Sergio0694]

@chrisdunelm I understand, and that's good to hear anyways, I guess you'll be able to start looking into the UWP support by the second half of June then!
I've waiting for the UWP support for the library for 8 months now, so a couple of weeks more are definitely not a problem 😄

I know you also have other work to do outside this repo, that's why I really appreciate all the effort you're putting into it, thanks again! 👍

[ghost]

@chrisdunelm So you're saying that the Google.Apis.Auth and Google.Apis.Drive.v3 apis will actually work in my UWP app in the near future???

I hope so. Spent a year learning C# and then put a year into developing my app. A few days ago I realized that the APIs I was looking to use don't even work on my platform of choice, and the last think I want to do right now is delve into REST API programming! I just KNEW things would work.

[mateusz-piasecki]

@chrisdunelm any news or timeline on this?

[chrisdunelm]

Work has (finally) started on this. Tentative mid-September release date.

[Sergio0694]

@chrisdunelm That's awesome, thank you so much for your effort! 😄

[chrisdunelm]

Release of this has been pushed back to the end of September.
The work is essential done (in the "uwp" branch), but there is currently a problem when using the nupkgs and performing oauth via GoogleWebAuthorizationBroker and UwpCodeReceiver.cs.
I hope to get this fixed in the next couple of weeks.

[LindaLawton]

When you have a working sample let me know and i will add it to the samples build project.

[chrisdunelm]

This is now in beta on nuget, and ready to test.
The Google.Apis.Core, Google.Apis, and Google.Apis.Auth packages have been released at version v1.30.0-beta01 with UWP support.

The API packages, e.g. Google.Apis.Storage.v1, have not been released in beta, as no changes are required.
So if you have a UWP app using (for example) Google.Apis.Storage.v1, then add an direct dependency on Google.Apis.Auth v1.30.0-beta01 to use the new UWP-specific functionality.

Please post any comments, bugs, or missing features here whilst this is still in beta. Thanks :)

[chrisdunelm]

@LindaLawton Thanks, I'll try to sort out a sample soon...

[Sergio0694]

@chrisdunelm It's so great to be able to test a beta version, great work! 😄

It seems to be working (at least partially), I've managed to login, to upload a file to GDrive and to browse my remote files from a UWP app.
I got this exception though when authorizing the app with a CancellationToken, is this the expected behavior?

[chrisdunelm]

@Sergio0694 Glad to hear it's working :)
Unfortunately authorization in UWP currently doesn't support using a cancellation token, so this is expected behaviour. The relevant code is in UwpCodeReceiver.cs.
This is due to WebAuthenticationBroker.AuthenticateAsync (called on line 57) not having an overload that accepts a CancellationToken.

The options are either to throw an exception if a CancellationToken is passed (as is the current behaviour); or to just ignore the passed CancellationToken, but cancellation will be ignored.
Do you have a preference? Whilst in beta we can definitely discuss and possibly change this.

[mateusz-piasecki]

@chrisdunelm I'll also definitely gonna test this out, but after my vacation, so second half of october

[jernelson7]

@Piachu91 yea, that's kinda my point. I'm not going to waste time (and money) implementing my own solution if this project will add support for it soon. It was marked for v1.31, then postponed without explanation ("chrisdunelm removed this from the v1.31 milestone on Dec 8, 2017") . So...will it be available soon or should I assume that it will not be, and thus I should try to create my own solution? No one seems to want to answer that.

[LindaLawton]

I understand that its frustrating but the developers who work on this project do so in their free time. Which is understandably under a lot of demand. Things get done on open source projects when the developers have time.

[chuese]

@chrisdunelm Just checking in. On Nov 20 I posted that my OAuth2 workflow using the dotnet API libraries v1.31.0 beta 01 is working for my UWP C# app. Any update on when the fix will find its way into your mainstream library? Just asking because the same authorisation flow does not work in the v1.32 releases. If I am not mistaken, I think you fixed it in the beta release by defaulting the datastore on UWP to PasswordVaultDataStore on the GoogleWebAuthorizationBroker.AuthorizeAsync() call.
See remarks from the library below.
// Remarks:
// In case no data store is specified, a sensible default will be used: FileDataStore
// on Windows and Core; PasswordVaultDataStore on UWP.

[tipa]

Any updates on this?

[LindaLawton]

@tipa The library is in maintenance mode I wouldn't
expect new features like this one too be added.

Feel free to fork the library and add it yourself.

[ghost]

UWP always get screwed over. I've been waiting about 2 years for a proper fix to this.

[chrisdunelm]

At a team discussion in October 2018 we made the decision to not proceed with support for UWP.
We don't see evidence that there would be enough usage to justify the technical work and infrastructure required for us to fully support the UWP platform.

We will revisit this decision on a regular basis, in case the situation changes.

[Sergio0694]

This was expected at this point, but I'd like to point out to @Acinity and @Piachu91 that it's is actually possible to use the latest version of the Google Drive APIs in UWP apps without problems, you just have to manually copy-paste the two classes (first and second) to handle the local access tokens.
I'm using the latest v1.36.0.1365 package and I haven't had any issues with it so far.

I mean, it'd be nice to have built-in support for that, but at least it still works with little to no effort 👍

[chrisdunelm]

@Sergio0694 Thanks for pointing out that this can be made to work on UWP without too much effort.
To confirm, the changes required for UWP are all in the auth library; not in the APIs themselves. We don't expect this to change, but we don't test on UWP so this isn't completely guaranteed.
The auth library is open-source (and always will be), so forking and adding UWP support is a perfectly viable thing to do.

[cmassman]

@Sergio0694 I added the 2 classes as you explained. I replaced the FileDataStore with the PasswordVaultDataStore. Now when trying to do the AuthorizeAsync It keeps coming up with this error from Windows. Would you know what is causing this? Or better yet, do you have working sample code?

credential = GoogleWebAuthorizationBroker.AuthorizeAsync(
GoogleClientSecrets.Load(stream).Secrets,
Scopes,
"user",
CancellationToken.None,
new PasswordVaultDataStore()).Result;

[chrisdunelm]

@cmassman You need to pass an instance of UwpCodeReceiver as the codeReceiver argument when calling GoogleWebAuthorizationBroker.AuthorizeAsync(...).

[bezysoftware]

Just a shout out from a UWP developer who has been using version 1.13.1 until it broke today, I just updated to 1.37.0 and copy-pasted above classes, seems to work again.

If you're still tracking "usage" of this lib, you can +1 for me

[alex4998]

Year 2021. Nothing changed. UWP is still not supported. Nice...

I just tried to reference the latest version and then tried version 1.37.0. They didn't work. I added the two files that were mentioned to my project and called

        UserCredential objCredential = await GoogleWebAuthorizationBroker.AuthorizeAsync(
           objSecrets,
           GOOGLE_SCOPE,
           strUser,
           CancellationToken.None,
           //new FileDataStore(strConfigPath, true)
           new PasswordVaultDataStore(),
           new UwpCodeReceiver()
        ).ConfigureAwait(false);

It didn't work either. In the UwpCodeReceiver at the line

     var result = await WebAuthenticationBroker.AuthenticateAsync(WebAuthenticationOptions.UseTitle, url.Build(), endUri);

The result.ResponseStatus is UserCancel and then it throws an exception.

Any ideas? May be there is finally a fully functioning in UWP fork?

[jskeet]

@alex4998: No, We haven't had any time to put into UWP (or Xamarin, or Unity) I'm afraid.

[alex4998]

@alex4998: No, We haven't had any time to put into UWP (or Xamarin, or Unity) I'm afraid.

But now I wonder if that trick with those two files really worked and why it doesn't work now.

[jskeet]

@alex4998: It's certainly curious, but unfortunately we don't have time to investigate that aspect either.

[alex4998]

If anybody cares UserCancel was happening because WebAuthenticationBroker.AuthenticateAsync was called on a non-UI thread. Completely misleading error/status. I wrapped it into this and it started working:

     Task<WebAuthenticationResult> authenticationTask = null;
     await CoreApplication.MainView.Dispatcher.RunAsync(
        CoreDispatcherPriority.Normal,
        () => authenticationTask = WebAuthenticationBroker.AuthenticateAsync(WebAuthenticationOptions.UseTitle, url.Build(), endUri).AsTask()
     ).AsTask().ConfigureAwait(false);
     var result = await authenticationTask.ConfigureAwait(false);

[fpromontorio]

Hi Alex, I tried the code you proposed but I can't authenticate my app. After successful authentication, can you invoke a Google service? I can't. I'm new to c# and uwp and maybe I'm more wrong than something. My app connects to Classroom goggle API. The Console version works with the GoogleWebAuthorizationBroker.AuthorizeAsync method, I would like to make it a Uwp version but it is known that this does not work with uwp.
I'm stuck at this point

UserCredential credential = new UserCredential(flow, "user", token);

        var service = new ClassroomService(new BaseClientService.Initializer()
        {
            HttpClientInitializer = credential,
            ApplicationName = ApplicationName,
        }); 

I can't create usercredentials because in the result of your code I don't know how to get the right information. The console version receives, and writes data such as these to a json file:

{
"access_token":
"ya29.a0AfH6SMBHT-XVV03KS5uFWFu1_tTKw9z8EhxO6SyaERTE-DPPk1pHr6hEhccPjkrCOmSLT87YNuXRP7dG43It2gXLFJqODFuDNBIXRw4RWKdXk8y7YzLnWb24iuq9uqQfqwFuimeLDN40zbEthNBG7k-rcJ1BMw",
"token_type":"Bearer",
"expires_in":3599,
"refresh_token":"1//09UagnhVjgL4PCgYIARAAGAkSNwF-L9Ir7aVxTGzhrK2MdGpW8F-wijeErQtWd-d49eWhhEK3WAJofWGJHAVWsb-i_UoIznmbua8",
"scope":
"https://www.googleapis.com/auth/classroom.profile.emails
https://www.googleapis.com/auth/classroom.courses.readonly
https://www.googleapis.com/auth/classroom.coursework.students
https://www.googleapis.com/auth/classroom.rosters
https://www.googleapis.com/auth/classroom.coursework.me",
"Issued":"2021-04-15T20:22:24.051+02:00",
"IssuedUtc":"2021-04-15T18:22:24.051Z"
}
In particular: access tokens and refresh tokens. How can this be done?
thank you in advance

[EmilAlipiev]

What is the conclusion for this? Uwp is still not supported?

[jskeet]

@EmilAlipiev: Correct. With the changes in UWP over the years, I suspect it's more feasible than in the past - if you basically bundle .NET with the app, for example, then to most intents and purposes it's "just a .NET app". (Indeed, I have a personal app that uses the Storage API via a service account, and I've had not problems with it.) Unfortunately there are just too many quirks and deployment options for us to actively support and test it.

[MartinRichards23]

@chrisdunelm We've been using your above solution in our UWP app, however now that support for the OAuth out-of-band flow is being removed do you have any idea how to update it so it will continue working?

[jskeet]

Chris is no longer working on the team - but the OOB flow has been deprecated and will be completely blocked by the backend by the end of January 2023, according to this migration guide.

We still don't have sufficient resources/demand to support UWP in our client libraries, and I'm afraid that includes re-investigation of previous workarounds. As I noted in November, it's possible that the regular .NET option of GoogleWebAuthorizationBroker might work now, but I can't justify putting time into testing it.

[LindaLawton]

Authorization with UWP seems to work fine with Maui, running locally. @MartinRichards23 is this a pure UWP app? Have you tested with standard windows desktop authorization?

private static async Task<DriveService> GetInstalledService()
	{
		var credPath = "credentials";
		
		var credential = GoogleWebAuthorizationBroker.AuthorizeAsync(GoogleClientSecrets.FromStream(await GetFileAsStream("credentials.json")).Secrets,
			new []{  Scopes },
			"userName",
			CancellationToken.None,
			new FileDataStore(credPath, true)).Result;
		
		return new DriveService(new BaseClientService.Initializer()
		{
			HttpClientInitializer = credential,
			ApplicationName = "DAIMTO - MAUI Oauth Installed Test"
		});
	}

[bezysoftware]

Just a side note, I was using the client to sign in users to Firebase, until it broke for me. So instead I switched to full Firebase UI solution - https://github.com/step-up-labs/firebase-authentication-dotnet I know this isn't a solution to everyone, but maybe a few who also use Firebase.

[LindaLawton]

@bezysoftware does that give you access to all google apis? or just firebase stuff?

I need to give it a try

[MartinRichards23]

@LindaLawton It is a pure UWP app.

I tried your example, it fails in LocalServerCodeReceiver when using Process.Start() to open the browser which I worked around by using Windows.System.Launcher.LaunchUriAsync();.

The next issue is that UWP doesn't allow the HttpListener to listen on 127.0.0.1, instead I tried passing a redirect url that uses a protocol registered to my app (rather than http), however that then causes the google signin page to complain the url is not valid.

[LindaLawton]

So Google doesn't allow for localhost or urn:ietf:wg:oauth:2.0:oob and HttpListener doesn't allow for 127.0.0.1.

<sarcasm>isn't that special</sarcasm>

If this the case I wonder how UWP handles Authorization internally. There must be another way.