.Net Core 2.x support/dependencies

[bruno-david]

Hi.

Do you have any plans for supporting/using .Net Core 2.x dependencies in the next builds?

• Microsoft.Extensions.DependencyInjection
• Microsoft.Extensions.Logging

Regards,

Bruno David

[borrrden]

I haven't seen those cause issues so far, but doing that would throw out .NET Core 1.x support which is something I would like to avoid for now. I guess they might be causing some trouble with ASP .NET Core 2.x? They seem happy enough to be used on regular .NET Core 2.x.

The reason I capped the dependency is because the new API there is incompatible with 1.x and when the users install the wrong version (which can happen easily) there are missing method exceptions and all kinds of chaos, but I imagine that part is more or less obvious.

If you have a suggestion about how I can support both then let me know.

[bruno-david]

Why do you still have to support an old version of .net core in an SDK that is still in Developer Build stage and not released yet?

For me, the problem is that my Library project that uses CouchbaseLite NuGet Package also references another set of Projects that depends on Microsoft.Extensions.Logging 2.0 and Microsoft.Extensions.DependencyInjection 2.0. This is the message I receive when trying to update to db021:
Version conflict detected for Microsoft.Extensions.Logging. Reference the package directly from the project to resolve this issue.
XXX.Repositories.CouchbaseLite -> XXX -> Microsoft.Extensions.Logging (>= 2.0.0)
XXX.Repositories.CouchbaseLite -> Couchbase.Lite 2.0.0-db021 -> Microsoft.Extensions.Logging (>= 1.1.2 && < 2.0.0).
Package restore failed. Rolling back package changes for 'XXX.Repositories.CouchbaseLite'.

Even though it suggests me to add a direct reference, it still does not work and it gives me the same error message.

[borrrden]

After looking more, it seems that it is not even possible for me to do this. Couchbase Lite is a .NET Standard 1.4 library, and Microsoft.Extensions.Logging requires .NET Standard 2.0. I am not going to move to .NET Standard 2.0 yet because that would drop the bulk of UWP support. Perhaps this logging library is simply not possible to use because of this restriction....

[bruno-david]

Can you give a rough idea of when the move to .net core 2.0 would be considered? In the meantime I will see what I can do on my side to make it work...

[borrrden]

Hmmm I imagine I would bring it up with all the pre .NET Standard 2.0 versions of UWP are deprecated (they are deprecating pretty fast so it might be sooner than any of us thinks)

[borrrden]

I looked up the lifecycle and the latest .NET Standard 1.4 Windows 10 version end of life is scheduled for tentatively September 2018

[bruno-david]

So is this when you would consider moving to .net core 2.0?
What would be my options to have Couchbase Lite on .net Core 2.0 before that?
Remember .Net Core 2.0 is way better in every aspect than 1.x and everyone is moving to 2.0. Even Microsoft released .Net Core 2.0 support to UWP last month

[borrrden]

Remember .Net Core 2.0 is way better in every aspect than 1.x and everyone is moving to 2.0.

I agree with this sentiment but I cannot reasonably say the second one. Once you enter the enterprise world things are exactly the opposite. Companies pay money and try everything to stay on the first version they have that works. Upgrades cost them time and money. I realize that Couchbase Lite 2.0 itself has not been GA released yet and that the argument here doesn't apply, but turning around to someone who says "Why can't it work on my tablet?" and say "because you didn't upgrade to X version of Windows 10" doesn't go over well (I've tried...but the customer usually has an army of thousands of tablets on a corporate approved version of so and so).

Just to be clear Couchbase works on .NET Core 2.0 because .NET Standard 1.4 < .NET Standard 2.0. The issue you have is that another library is requiring libraries that are in conflict with the ones that I require.

Even Microsoft released .Net Core 2.0 support to UWP

Nobody is more happy about that than me. I want to move to .NET Standard 2.0 but I cannot do so responsibly while the majority of the Windows 10 versions don't support it. In fact right now only the latest version supports it.

As far as options to make it work, not to be too cynical sounding but that depends on how loudly you can make your case. If you are an enterprise customer, then you will have a lot of pull through contacting through our corporate channels. If you are a community user, then the answer is most likely going to be to compile it yourself after migrating the project to the new standard.

You don't need to compile everything from scratch though. Just the C# inside of Couchbase.Lite and Couchbase.Lite.Support.NetDesktop (for LiteCore, you can pull the files from inside the Nuget package).

[borrrden]

P.S. It's not "me" when I talk about consideration. I also have management to answer to and clear things with.

[bruno-david]

Sure, I completely understand your point.
We are enterprise customers...I will try to make it work on my own for now by following your instructions.

You don't need to compile everything from scratch though. Just the C# inside of Couchbase.Lite and Couchbase.Lite.Support.NetDesktop (for LiteCore, you can pull the files from inside the Nuget package).

Thanks for the clarifications.

[borrrden]

This won't be the end of this discussion anyway, I will bring it up internally to see what I may or may not be able to get away with.

[bruno-david]

Thanks, it would be great for us. Please keep me posted.
We have a new product that will go live in a few months and we would like to use Couchbase Lite 2.0 due to all the improvements it has and also due to the support for .Net Core (We have WPF and Xamarin clients sharing the same code base with a WebAPI)

[borrrden]

Alright after several discussions I have gotten clearance to immediately move to NS 2.0. It should be changed over by the next DB. Here's to avoiding backlash from people using 1.x!

[borrrden]

Build infrastructure needs upgrading to be able to build .NET Standard 2.0, and then the testing infrastructure needs the same for the Windows Linux and Mac boxes. This issue will block on that.

[bruno-david]

Thanks for your support!

[borrrden]

Well the bad news on this is when I tried to upgrade to .NET Standard 2.0, and consequently the 2.0.0 version of the Microsoft Extensions things blew up for me on both UWP and Xamarin Android. The former is a bug in the build system that I was able to work around. The latter is an issue that is described here. I was able to finally get things to build and run after hours of trying but then the unit test framework stopped recognizing my tests. I'm on a time crunch here and don't have time to put up with that nonsense so I am reverting back to .NET Standard 1.4.

That being said, I am going to take another approach to this. I removed Microsoft.Extensions.Logging and removed the ability to add a custom logging provider to Couchbase Lite (Java and Swift do not provide this anyway, it was merely a bonus for .NET carried over from CBL 1.x). I replaced Microsoft.Extensions.DependencyInjection with [https://simpleinjector.org/index.html](Simple Injector) and added some more code so that I don't expose any nuget classes directly. This will prevent me from getting locked in in case I find an issue later. The end result is that the Nuget package will no longer take dependencies on the Microsoft Extensions and your issue should be unblocked.

I still want to move to .NET Standard 2.0, and actually the latter Android item will be irrelevant with this change since the source of the issue was the Microsoft Extensions library. I still hope to do it by the GA of 2.0, but it looks like the beta (closed beta scheduled in a week) and db022 will continue to be NS 1.4.

[bruno-david]

ok, thanks for the update, I will test it out.
When is db022 coming out?

[borrrden]

Supposed to be out tomorrow...which is why I'm in such a time crunch to get all this done.

[borrrden]

I was ready to release but our manual group testing uncovered an issue on all three platforms that needs to be resolved. Tomorrow we will retest. However, I will close this ticket for now.