I'm trying to access the Google Drive API, and I can successfully log in a user with the use of the Google+ API. I've been following this guide:
https://developers.google.com/drive/v3/web/quickstart/dotnet
I added the needed libraries with the nuget package manager, but still it can't find the GoogleWebAuthorizationBroker class. The weird thing is, that when I add the same Google.Apis.Auth package version 1.18.0 to a simple console application it works flawlessly, but when I add it to my .NET Core 1.0 preview 2 project it simply won't recognize the aforementioned class.
A screenshot including the added packages:
My .NET Core source code (no class found here):
My console application source code and references (the class can be found here for some reason):
Thanks in advance!
Your console application is running on the full .net framework. That is why GoogleWebAuthorizationBroker is getting resolved there.
I have had the same issues with the Google.Apis against .net core and I ended up running the asp.net Core project on top of the full .net framework. When the Google components work, I plan on switching the framework back to .net core.
I replaced the dotnet framework with the 461 framework like this:
"frameworks": {
"net461": {}
}
And I also had to comment out/remove the dependency on Microsoft.NETCore.App like this:
"dependencies": {
"Google.Apis": "1.19.0",
"Google.Apis.Auth": "1.19.0",
"Google.Apis.Calendar.v3": "1.19.0.675"
//"Microsoft.NETCore.App": "1.1.0-preview1-001100-00",
},
You could also run against both frameworks - I tried doing that, and when you publish the website you go
DOTNET PUBLISH -f 461
or
DOTNET PUBLISH -f netcoreapp1.0
Depending on the framework.
You also then have to select from a dropdown in visual studio, the framework you run against, which ended up being more of a problem. Easier to just comment out the dotnetcore1.0 framework when not needed and just go dotnet publish on my build pipeline ...
There is a thread on the Google .net apis github page about .net core compatibility here. https://github.com/google/google-api-dotnet-client/issues/872#issuecomment-259710682
Expected support for these classes are guesstimated at early 2017.
Hope that help you?
Related
I recently migrated a dotnet framework v4.7.2 WCF service with the upgrade-assisstant tool to NetStandard 2.0. the project successfully migrated and compiled, BUT I couldnt start the service either from visual studio nor dotnet cli.
the Error I get from dotnet cli tool is :
A fatal error was encountered. The library 'hostpolicy.dll' required to execute the application was not found.
AND the error I get trying to start the service from visual studio, solution explorer -> right click on wcf project -> debug -> start new instance is:
A project with an output type of class library couldnt start directly.
P.S when the WCF service was still dotnet framework v4.7.2 I could easily start the service doing the above mentioned procedure in visual studio.
As I know .net 4.7.2 is the lowest real version that supports .netstandard 2.0 In this link.
You can back it up and upgrade to 4.7.2 to try it out.
WCF server APIs are not supported on .NET Standard or .NET Core/.NET 5+, so there's no good way to migrate such an app forward.
Upgrade Assistant tries to figure out whether a project should upgrade to a library or an exe based on the previous project type. For this project, Upgrade Assistant guessed it was a library since there was no traditional main method and it wasn't a web app or some other project type that the tool understood as executable. Regardless of whether it upgraded it as a .NET Standard library or as a .NET 5 exe, though, it wouldn't work because WCF server APIs are only supported on .NET Framework.
It might be nice if Upgrade Assistant alerted you to that early in the process so you knew upgrading wouldn't work for this type of project. I thought it had a feature like that, but it must have missed for this specific project. You could provide feedback on the tool's GitHub page (https://github.com/dotnet/upgrade-assistant/issues).
As far as how you can actually upgrade WCF server stuff, you'll need to re-architect using a different technology like ASP.NET Core, gRPC, or CoreWCF.
I have a .net 5 web api that consists of a solution with most of projects being .net 5, but two of them are .net framework (v 4.7.2).
The web api works fine when I run it, and referring to .net framework projects is not a problem.
Now I am trying to upload this solution to azure app service using Github actions. The build step works fine, but when publishing, I get the following error:
C:\Users\runneradmin\AppData\Local\Microsoft\dotnet\sdk\5.0.202\Microsoft.Common.CurrentVersion.targets(4288,5):
error : MSB4803: The task "FormatUrl" is not supported on the .NET
Core version of MSBuild. Please use the .NET Framework version of
MSBuild. See https://aka.ms/msbuild/MSB4803 for further details. [path
to my .net framework .csproj]
I am trying to avoid updating the project to .net 5. Is there a way to configure my github actions to be able to publish .net framework projects as well?
I have been troubling with .Net core 2.1.2 update. We have a .Net core project and we are developing that in two different machine ( win 10.0.17 ) , interesting thing is coming up here; he has the same project and even same sdk and runtime updates and evenmore he has vs2017 15.7.5 update. He can run and build the Web Api without error but I have couple of problems shown in image name of buildError.
First
Second
Third
and finally buildERROR
Error The project was restored using Microsoft.NETCore.App version 2.1.2, but with current settings, version 2.1.0 would be used instead. To resolve this issue, make sure the same settings are used for restore and for subsequent operations such as build or publish. Typically this issue can occur if the RuntimeIdentifier property is set during build or publish but not during restore.
Oh before forget, here is the error when I'm trying to add a new controller.
i will appreciate it, if we solve that.
Note: I already clear the nuget cache file. And did not work.
Below, my csproj :
If you have other .net Core SDK's and Runtimes e.g ".Net Core Runtime 2.1.302" and ".Net Core Runtime 2.1.301" and even if you had download ".Net Core SDK 2.1.201 " & ".Net Core SDK 2.1.202 "
You only need to be sure exact versions of SDK's and Runtime. I'll leave my version below in the image
Best Regards ;)
I have a WPF application under the .Net framework 4.5 and a web app under the DNX Core.
I want to share some code between those two apps.
I tried to create a "portable classe library" ... with no result.
I tried to do it with a nuget package ... with no result (and too complex to dispatch modifications)
Thanks for your propositions
Normally when creating a portable class Library, you can be compatible with .NET 4.5 and Dnx project. The only problem is that .Net 4.5 relies on csproj when your Dnx project relies on project.json.
Thus you won't have it out of the box, check out your options here: What are my options for sharing code between DNX / ASP.NET 5 projects (project.json / xproj) and other C# projects (csproj) within a single solution?
Note that this solution will probably not work in the next version of dotnet core if they finally remove the project.json...
I'm interested in figuring out how to use the Twilio API, and I am building an ASP.NET 5 application using the Twilio API with MVC6 (trying to follow this tutorial). So far, I have created an empty ASP.NET 5 application, and I added "Twilio" to the dependencies in project.json. I get the following error:
"The dependency Twilio 4.0.3 in project TwilioTest does not support framework DNXCore, Version v5.0"
I notice that when I remove "dnxcore50" from "frameworks", the error goes away.
I'm not sure what this means or how to approach it. I'm still pretty new to .NET and trying to wrap my head around how all of the pieces fit together. Does it mean that Twilio isn't compatible with DNXCore? Since all I want to do for now is learn how to use Twilio, could I essentially remove the dnxcore50 framework from the project and continue working through building the app?
The Twillio NuGet package is dependent on the full .NET stack, which in project.json frameworks terms is DNX451. What that means is, you can add the Twillio NuGet package and remove the DNXCORE50 reference and your project will run as expected and you will be able to use the Twillio API. As far as I know the only major drawback is that your ASP.NET Core project will no longer be cross platform as you are now dependent on the full .NET Framework stack which is only present in Windows.
In a nutshell, you should be fine unless you are planning to deploy to Linux/OSx. Hopefully as ASP.NET CORE becomes mainstream more 3rd party SDKs will be built to require only DNXCORE50 as a dependency.
Another option don't use the Twillio Libraries and code against their REST API. See documentation here: https://www.twilio.com/docs/api. But I wouldn't recommend this if you are deploying to a Windows environment.
Twilio is working on their .Net Standard (Core) library. In the meantime, I've published a .Net Core port of their library to unblock our current projects until we get the official update. Feel free to take it for a spin:
Install Twilio.NetCore from Nuget.
And you can check out the source on Github.