SDK to support NET Core
Closed this issue · 26 comments
Currently I see that the the sdk supports .NET 4.5 and 4.6. At Albelli we try hosting most of our APIs on AWS Lambda. Would it be possible to release a version of the SDK that supports
- .NET Core 1.0.1
@brajivbala Yes, .NET Core support is tabled for sometime in the near future. I will prioritize this request.
@jhumber i tried to create the SDK as (.NET Standard) Class Library. I found that we need the following nuget packages compatible with .NET Standard 1.3 (with some minor code changes/Especially with regards to how we use Reflection within the SDK/Log4Net method signatures)
- log4net (2.0,8)
- NewtonsoftJson (9.0.1)
- Microsoft.Extensions.PlatformAbstractions (1.1.0)
- System.Collections.Specialized (4.3.0)
I was able to compile the Class Library and run some tests. The Implications of using .NET standard 1.3 is that we cannot support .NET 4.5. The platforms supported by .NET Standard 1.3 can be found at
- https://github.com/dotnet/standard/blob/master/docs/versions/netstandard1.3.md
- https://docs.microsoft.com/en-us/dotnet/standard/net-standard
Otherwise we have to do some multitargeting to support .NET 4.5. Let me know what you think.
Thanks for the research! I suggest the first thing is that we set up the CI environment to build and test the targets we want to support. They will be "red" first but then we have a clear goal to go after.
The Travis build is already set up with core ( https://travis-ci.org/commercetools/commercetools-dotnet-sdk // https://github.com/commercetools/commercetools-dotnet-sdk/blob/master/.travis.yml#L6 ). It's currently green for some reason but "allowed to fail". It's on an old prerelease .net core, but the docs ( https://docs.travis-ci.com/user/languages/csharp/ ) say that 1.0.1 / 1.0.5 ?) and 1.1.2 should be available now. Let's test that...
@jayS-de do you know how to configure appveyor to do multiple builds per environment? ( https://www.appveyor.com/docs/build-environment/ )
If that is feasible somehow I would be happy not to drop 4.5 support.
The SDK is also targeted towards older on-premise setups (e.g. CMSes) and even local apps (e.g. the majority of in-store displays and kiosks runs windows 7).
I would have to adjust the cake build script. As the build script defines which runtime to use. I just stripped it down to .NET45. So travis is indeed lying about .net core. I think it's really running still against mono.
To actually support more variants we need different project files which define the target runtime.
I just pushed this branch: https://github.com/commercetools/commercetools-dotnet-sdk/tree/ci-dotnetcore-stable
It fixes the bug that travis is actually building on mono (4.5 compatible) and not on dotnet core. Result is that the respective configuration is red now, which is correct. The build script would also need to be fixed once the thing compiles on .NET core SDK 1.0.1
goal of the branch would be to have CI set up but "red".
Apropos: the compatibility discussion already has an own issue here: #8
Actually, I am okay with dropping 4.5 if I get the ecosystem and compatibility tables right. The 4.5 decision was made nearly a year ago now when it was not yet clear that Windows Phone is finally a dead horse.
So all you .NET know-betters-than-me, here's the key question: Would a 1.3 profile build be usable for the following use cases:
- cloud function on azure
- cloud function on AWS
- Window 7 based terminal or display device (you can install a newer, supported .NET there since you are the administrator and not the user)
- Window 10 based terminal or display device (same, see above)
- A typical windows server configuration for the Kentico, Umbraco and Sitecore CMSes.
Native mobile is out or needs to be done as universal windows app.
If that is supported by targeting dotnet & mono 4.6 / dotnetcore 1.0.0 / UW-app 10.0 I'm fine with shortening the discussion here :-)
@brajivbala I tend to agree with @nkuehn in that it would be nice to keep supporting 4.5, however I don't view that as a dealbreaker if we can't make everything play nicely together as we can still support 4.6 under .NET Standard 1.3.
At this point, you've likely done more research than I have on what a multitargeting approach would look like. Can you expand a bit on how we would go about setting that up?
@nkuehn regarding your compatibility questions about those specific platforms and use cases, 4.6/.NET Standard 1.3 would be fine, but you would need later versions of the CMSes you mentioned.
@brajivbala So to recap: if multitargeting is needlessly complicated, let's drop 4.5 support. I would just like to get an idea of what we're in for if we do decide to set up multitargeting.
I am fine with dropping .NET 4.5 .
@jhumber I am guessing we would need multitargeting only if we need to support .NET 4.5
More info on multitargeting can be found here.
https://docs.microsoft.com/en-us/dotnet/core/tutorials/libraries
If we just create the current ClassLibrary(commercetools.NET) as a .Net Standard Library (fixed at 1.3), then my guess is that we do not need multi targeting
@brajivbala Thanks for the link. I am fine with dropping support for 4.5 and not worrying about multitargeting. Also, regarding this:
You can use the default version of the .NET Standard supplied by templates - netstandard1.4 - which gives you access to most APIs on .NET Standard while still being compatible with UWP, .NET Framework 4.6.1, and the forthcoming .NET Standard 2.0.
If there are no downsides, maybe we should consider using .NET Standard 1.4
yes .NET Standard 1.4 is what Microsoft themselves recommend. It also means 4.6 is not supported and only .NET 4.6.1 is. So that is where i am a bit hesitant that someone might want to use the SDK against .NET 4.6).
@brajivbala what would be typical use case for having 4.6 available but not not 4.6.1 ?
@jhumber 4.6.1 does not seem to really do it for the CMSes in comparison to 4.6
- Kentico 9+10 say "4.5 or 4.6" (but no mention of 4.6.1).
- Umbraco will have support for 4.6.1 only in the next version (8) but current run on dotnet 4.6 from v7.4 on
- Sitecore: https://kb.sitecore.net/articles/087164 -> 4.6.1 only in the very latest "XP 8.2", but 4.6 also usable in the 7.2 CMS and all 8.x (although with limitations).
gut feeling: 1.4 could bring us into trouble. e.g. I know of a project that will start from scratch on umbraco in three weeks or so. I assume they will not use a not-yet-released version.
@nkuehn Kentico 9 and later will support 4.6 and it's point releases (4.6.1, 4.6.2). Sitecore 8.2 and later supports 4.6 and 4.6.1. I have not personally used Umbraco but it appears that 4.6 and point releases are supported as of version 7.4.
parallel research :-)
@nkuehn my reservations were driven by
- Just a gut feeling to make sure the sdk is able to support more environments.
- Some of the dependencies we have in the sdk like log4net don't have compatible versions for w .NET standard1.3 and above.
If we can find a solution to the dependencies/ are ok with dropping 4.6. I say let's go for it :-)
@brajivbala Aaah, log4net. I'm not sure what to do about that otherwise I'm on board with going right to .NET Standard 1.4.
I will take a look at what can be done about log4net over the weekend but I won't be able to report back until Monday. I'm also open to using other logging libraries if there is a compatible alternative.
@jhumber I would suggest first trying it out with .net standard 1.3. If it proves way too painful to make it work, then I would consider 1.4. That way we make sure that dropping support for 4.6 is not for nothing.
PS I know already that it can be done easily with .net standard 1.3 :-) in combination with the nuget packages I have mentioned above.
@brajivbala Yeah, you're right. Let's move forward with .NET Standard 1.3.
One other reasoning to larger the lowest possible .net standard is that the .net standard is only additive. There is no procedure to remove the API implemented in later version. So later if we choose to upgrade, I am guessing we will be safe.
I've asked other clients and partners about their requirements and will keep you informed here. But it's not likely that it'll deviate from the CMS-centric list I did above (= 1.3).
@nkuehn one more thing i found is that azure functions also support any netstandard 1.3 assemblies or the .NET Framework v4.6
So 1.3 is good choice for the SDK.
On another note We have managed to get the SDK (.net standard 1.3) working on AWS lambda at Albelli for now. I haven't tried Azure functions yet. May be very soon.
@jhumber any luck yet converting to .net standard 1.3 ?
@brajivbala My ability to contribute to this project will be limited for the next couple of weeks and I am currently working on issues #24 and #32. If you need this addressed sooner, please feel free to make the necessary changes.
@jayS-de in our call today did I understand correctly that you plan to use ( Conditional compilation directives) IFDEF s like the NUnit project and compile the code against various target platforms ?
While I am not against using IFDEFs, I would consider the implications of using it .
- Personally I think it very painful to maintain.
- They can lead to architectural complexity/technical Debt over a period of time.
NUnit use this IFDEF strategy, probably because they have support a wide variety of platforms ranging from .NET2.0 to .NET Core. We do not have to support the legacy platforms that NUnit does. I think using .NET Standard is a nice way to abstract ourselves from the above mentioned issues.
If you need to think over/discuss more about this, we can have another call
@jhumber do you have an opinion on using the conditional compilation directives approach ?
As the SDK is now using .NET standard 2.0 this issue should be resolved.