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

[Sergio0694]

@chrisdunelm Thanks for the info - I think the best approach would be to keep the exception when a CancellationToken is passed, so it'll be immediately clear that the method doesn't in fact support it. Otherwise all the devs not reading the documentation could spend (waste) time trying to debug their app and wondering why their method isn't stopping when the token is cancelled, not knowing that it had in fact just been ignored by the library.

[chrisdunelm]

@Sergio0694 Yes, keeping the exception when a non-none CancellationToken is passed is also definitely our preferred approach, for the reasons you mention. Perhaps the exception message should be changed to make it clearer what the problem is.

[Sergio0694]

@chrisdunelm Did some more tests in Release mode, both with a local build and with a build published to the Store, everything seems to be working great, thank you for your hard work! 😄

[appstudio3000]

@chrisdunelm Thanks for your hard work here. Is there an update when the official release of the UWP version can be expected? This information would really help us the plan our project. We are currently building an UWP app using the Google Rest API. However, if version 1.30 get released soon, we can probably stop working to build our own library.

[chrisdunelm]

@appstudio3000 We do not have a release date for this. However I can tell you it will definitely not be any earlier than mid-November. This is because there are a number of discussions surrounding UWP and mobile (Xamarin) support that we need to have internally before we move this out of beta.

[appstudio3000]

@chrisdunelm Thanks a lot for the clarification. Actually we would also use the beta, but unfortunately we can only find beta nugets for Google.Api but not for Gmail or PubSub. So I guess we have to wait, before we can do the switch to the SDK.

[chrisdunelm]

@appstudio3000 beta packages for Gmail/Pubsub/etc are not required as there are no code changes required for UWP in those packages; they already contain dlls suitable for UWP in the netstandard1.3 target. So using the v1.29.2 (or whatever the latest is) Google.Apis.Gmail.v1 package with the Google.Apis v1.30.0-beta02 is completely fine.

[appstudio3000]

@chrisdunelm Great. It worked. Thanks for the info.

[chrisdunelm]

We need to release a new version of these packages as we require a new feature (see PR #1101). This release will be v1.30, but this new release will not contain UWP support. I've bumped the milestone release for UWP support to v1.31. As stated previously this will be mid-November at the earliest.

[chuese]

@chrisdunelm Can't wait for the UWP support... the sooner the better. I've been hanging out for this for a few months now. :) . Appreciate your efforts. Cheers

[dmitry-shechtman]

So I cannot yet use Drive in my UWP app?

[mateusz-piasecki]

@chrisdunelm @chuese @appstudio3000 @Sergio0694 did you guys have any trouble with file upload using 1.30 beta 02? Code that I'm using right now (which works on 1.11-1.12) does not seem to work and I'm wondering if I should try to rewrite it in some way or maybe it's beta stage fault?

[chuese]

Okay, I think we have progress. Just re-tried Oauth2 authentication as per Google Dev samples (webauthenticationbroker.authoriseasynch()) using the 1.31 beta 02 libraries on a UWP C# app. Where I had errors in the past, it now works as long as I build/deploy on a Windows 10 PC. The same code deployed to a Windows 10 mobile fails still.

Only difference I can see is that my PC has the Fall Creators Update Windows build, and the phone at the moment is stuck on the Anniversary update. So, do the new libraries with UWP support have a minimum Windows build level as a requirement?

The error I get on Windows 10 mobile Anniversary Update is a FileNotFound exception. Apologies for being vague, I'm not at home in front of my dev environment at the moment but wanted to post some feedback.

Any ideas of where I might be going wrong, @chrisdunelm @LindaLawton ?

[chuese]

Okay, big backpedal here... Just updated VS 2017 to latest version, and changed deploy options for client_secrets.json to "content" and copy if newer. Either one of these two actions has fixed the issue on the Windows phone. Oauth2 using Webauthenticationbroker now working beautifully. And also correction on the version of the Google API libraries. it's 1.31 beta 01. Big thanks for fixing this longstanding issue.

[jernelson7]

Hello, Just wondering if there is any update the timeframe for this. I have v1.32 and it does not seem to be supported (Windows throws a popup error when trying to authenticate). If not, the Windows Mail app (which I believe is UWP) seems to have found a way around this. Do you have any suggestions for how to do what Microsoft did?

(Ping) @chrisdunelm @chuese

[mateusz-piasecki]

@jernelson7 I asked Microsoft about this - they are using they own totally custom implementation AFAIK

[jernelson7]

@Piachu91 Ok, at least I know it's doable somehow. Any update on the timeline for supporting this?

[mateusz-piasecki]

@jernelson7 I think that you have wrong assumptions - everything is possible, but doability depends on time and money that you want to spend

[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;