search

OneDrive / onedrive-sdk-csharp

OneDrive SDK for C#! https://dev.onedrive.com
Other
293 stars 145 forks source link

How about Coreclr / CoreFx support? #108

Open aersam opened 8 years ago

aersam commented 8 years ago

That would be nice :)

suntsu42 commented 8 years ago

Any news about this? I'd like to access onedrive from linux using .net core.

giulianisanches commented 7 years ago

Hi,

How could i help on this ? I'm learnig to program in C#/.NET and this can be a good exercise.

Maybe start to port the SDK to .NET 4.6.2 (lastest version) and than port it to .NET Core (or wait for the 1.1 / 2.0 release of it).

I would apreciate some guidance :)

Thanks.

cdmayer commented 7 years ago

Hey giuliansanches, go ahead and give it a shot. At this time I'm not sure what's in the SDK that will block you from updating, but it can't hurt to try. Basically you just need to target .NET Core in the build step and see what the compiler complains about, then go from there. Some of it will be small (language features that aren't supported) but other stuff may be harder (for example, does .NET Core need a new/different HttpProvider implementation).

Shortly I am going to be pulling in a major update, Version 2.0 of the SDK. I would recommend starting there. Fork from the v2 branch to get started.

You can post problems/questions here.

giulianisanches commented 7 years ago

Hi, sorry for this late response.

I'm trying to work in this project but currently i can spend only a couple hours per week on it.

Thanks for the tips! As soon as i get the first compilation "success" with .NET Core I will update here. (i'm having a hard time to discover how to port the configuration/toolkit to .NET Core to get dotnet restore/build/run commands to work).

pavram commented 7 years ago

Biggest problem with porting this to dot.net core isn't the code or language feature support.

The problem is the project layout has changed, which makes "just compile for a different runtime" much harder than you'd wish.

The code for the One drive SDK, the microsoft.Graph and Microsoft.Graph.Core all compile fine (after I copy/pasted straight out of their respective Git repositories).

(Well; it all compiled fine except for "SpecialCollectionRequestBuilderExtension.cs", in the OneDrive SDK, which appears to be a partial class that expects something in the "Generated" folder to exist - which doesn't. I literally deleted the file and it compiled fine.)

Not very scientific, but the change in project structure is a real pain.

(I also used the latest version of the Newtonsoft library; which at this time is ~9.0.2)

giulianisanches commented 7 years ago

If project layout is a pain to someone experienced in C#, think about for someone starting with the technology :).

This weekend i will try to create a project in .NET Core and copy the files inside it.

thanks.

pavram commented 7 years ago

I dont know how high is rate my c# experience, but the project layout isn't hard, it's just different.

My testing of the SDK fell over when I started trying to port the OneDrive authentication example project. That project uses some Microsoft active directory libraries, those AD libraries HAVE been ported to .net core, but they have changed the API ever so slightly.

It's one of those problems that just keeps throwing up another library to port.

cdmayer commented 7 years ago

The change in project structure is an effort to reduce code duplication by separating responsibilities cleanly.

  1. Graph.Core has the interfaces and implementations of basics that anything touching a Graph API will need, such as AuthenticationProvider.
  2. Graph provides the objects for serializing/deserializing things based on the Graph EDM. Similarly, the OneDriveSDK provides the same for the OneDrive EDM (which is a superset of the things provided to access OneDrive in the Graph EDM, and supports authentication against endpoints other than Azure AD).

@pavram I see what you mean. It does feel like there are a lot of pieces to port, but I believe that is the end of the dependency chain. If there are API differences between the .NET Core version and the standard version, you probably should raise an issue against them because that is not likely intentional.

rfrazier commented 7 years ago

Will .NETStandard be officially supported in the future? Now that Xamarin is going that route and several other Microsoft properties....would be nice to fall in line.