Good news

We've decided to postpone .NET core support to the date when .NET standard 2.0 is shipped and will support netstandard2.0 instead. This is likely somewhere in May 2017. It's not an easy decision, but in this case there's no real 'right' decision, as there are too many things in flight at MS and broken things at their side.

This means we won't support .NET standard 1.6, but will support netstandard2.0. The main reasons are below.

• supporting .netstandard 1.6 would require a different 'target framework' if we would want to validate the model against the limitations in .netstandard1.6: it doesn't contain datatable for instance. This is a problem as netstandard2.0 will support datatable so creating this framework would be a dead end within a few months. We could get away with a stop-gap solution where the generated code would lack elements in the model and refer to documentation, but it's not ideal. And as netstandard20 is arriving within a few months it's silly to go through this trouble when most people will never use netstandard1.6.
• when .netstandard2.0 is released, the runtime has to be ported again, this time it can be brought over almost without changes. We would then have 2 versions, where one is obsolete before its life even began: who would use the .netstandard1.6 version, when a netstandard2.0 version is available? No-one, except people perhaps on existing projects, but that's a handful and they already don't use our runtime. New projects likely will use netstandard2.0 as the # of APIs and features is much bigger.
• even though we would manage to create a netstandard1.6 version at the end of January (we already ported the runtime) of our framework, it wouldn't be released as v5.2 then, but sometime later, e.g. in March. As netstandard2.0 comes out a month or 2 later, it's silly to do work on a limited framework now which will be obsolete within a few months.

So we decided to release a .NET core 2.0 version of our framework when .netstandard20 arrives. This isn't far away and a few months doesn't matter in this case.

I think it the wisest choice!

Wise decision. Thanks for the update.

FULL ACK!

Understandable. Now that you have done a bunch of work porting you should be able to produce a 2.0 port easier. I agree that 2.0 will likely come at the May event, I am hopeful that is the FINAL release and there are betas and such way before that so that you can be ready when they are ready.

The latest RC3 of Visual Studio gets the final, final version of the new project format. It is actually pretty nice. I also understand that the 2.0 code is complete internally (code complete, not really ready) so hoping they can make May at last.

Not debating your decision, I think it is a good one...but on a separate note, really wondering about datatable. Do people still use that? I can say we have not used it in any project it many, many years. Perhaps it should be 'optional' anyway as that a bunch to support. Who knows, maybe everyone but me uses it...?

WayneBrantley wrote:

Understandable. Now that you have done a bunch of work porting you should be able to produce a 2.0 port easier. I agree that 2.0 will likely come at the May event, I am hopeful that is the FINAL release and there are betas and such way before that so that you can be ready when they are ready.

The latest RC3 of Visual Studio gets the final, final version of the new project format. It is actually pretty nice. I also understand that the 2.0 code is complete internally (code complete, not really ready) so hoping they can make May at last.

It's really messier than that. 2017 RTM will have their new project system for .NET standard but .net standard2.0 will be released sometime after that. What's publicly available on github suggests they're close but at the same time it feels they're in crunch mode for months now, not a good sign for quality. But we'll see. Porting to netstandard2.0 should be straightforward (as in: almost all code compiles out of the box, except the dependency injection part)

Not debating your decision, I think it is a good one...but on a separate note, really wondering about datatable. Do people still use that? I can say we have not used it in any project it many, many years. Perhaps it should be 'optional' anyway as that a bunch to support. Who knows, maybe everyone but me uses it...?

Some people still use it, but it's not really sufficient anymore, agreed. Benchmarks with a typed view based on a datatable and a poco show that the poco is much faster. In v5.2 we're switching the default for typedviews/lists to poco b/c of that. (for new projects).

Datatable is actually useful for untyped sets, which are e.g. used for metadata retrieval on a datareader Removing them from .net therefore gives a problem which they failed to address in over a year (sloppy proposals aside, it really was a disaster). They've now ported it back to netstandard2.0 so that's OK now.

Microsoft delayed .net core 2.0 / .net standard 2.0 to Q3 2017 (see roadmap: https://github.com/dotnet/core/blob/master/roadmap.md). This changes things of course.

We'll re-evaluate what to do: port to 1.6 in the meantime or wait for 2.0. Neither are great choices, to be honest.

Oh no! My first reaction: I'd wait for 2.0!

On the other hand:

How likely is it, that people actually switch to .NET Core and - as there is no other alternative around - start using EF as ORM? Not very likely that they later port their solutions to LLBLGen.

Glad, I'm not in your shoes.

My take: hopefully we'll see a 1.6 port. Of course, that's from my perspective. So far I had to use Npgsql (SQL statements, ouch) and MongoDB as alternatives to llblgenpro. I'm not that keen on EF.

And @kamiwa is correct, once you start with an ORM is unlikely to switch. Perhaps if there is really a strong motivation, but otherwise not likely.

I'll definitely wait until Frans comes up with a solution. No point in using .NET Core w/o a decent ORM framework.

kamiwa wrote:

No point in using .NET Core w/o a decent ORM framework.

There are a lot of points for using it. Just think of dockerizing server parts. But yes, it's kinda ugly when it comes to databases right now.

mihies wrote:

But yes, it's kinda ugly when it comes to databases right now.

I live in a world where code that isn't using a database doesn't exist. Especially no server code.

kamiwa wrote:

I live in a world where code that isn't using a database doesn't exist. Especially no server code.

Hehe, indeed. But still, the pain of llblgen abstinence is at least a bit less strong when using other benefits of .net core.

I believe that at this point the choice is almost mandatory. Microsoft is causing a lot of damage to all of its developers .. I am convinced that their direction is right, but if you want to cut with the past is necessary to do it rapidly and certain times, their meter they are taking too much time. For two years we do not know whether to go and stay .. At me Netcore love it! I tried EFCore and is not bad but I love LLBLGen for me is another planet! I wanted to congratulate you for the excellent work done on Derived Models! Since there are, I take this opportunity to ask you if I can be sure in future relase the SelfServicing model will always be supported? These days I tried the DataAdater template but I found it too expensive if you have to manage only one type of database .. SelfServicing is the best for me! Times have changed the Netcore is no longer monolithic, developers will have to build their own toolbox and LLBLGen will have a great future! It 's time to invest, both the product and training in order to simplify the adoption of it to the largest number of developers .. Luca

.NET Core and Microsoft is causing quite a few IT companies a royal PITA.

JetBrains (best known for IntelliJ IDE and Resharper) are currently developing a cross platform IDE for .NET. named Rider.

They just had to find out, that open source is not always as open as you'd think.

The technology behind debugging .NET Core projects is MS VS and XAMARIN XS licensed only.

Read for yourself: https://blog.jetbrains.com/dotnet/2017/02/15/rider-eap-17-nuget-unit-testing-build-debugging/

.. Interesting an open source framework with a legacy debuger. I hope this is a mistake. Although it would be less of a problem at the moment .. The current problem is to have something to debug in NetCore!

Well, it is a tough call.

As discussed above, one of the pain points are 'no datatables'. For me it is a non-issue if you released a framework that did not use datatables and then later you released a 'datatable' package that added missing features others used.

I really want to move to something targeting a .net standard much quicker than Q3. For me, I see much of the community has embraced this and moved. There are still some holdouts 'waiting' for 2.0 because as discussed it makes the pain much less.

Your investment, your customers, your potential loss of new customers, your call. I will be forced to live with whatever decision you make as I will not be leaving and we love your product.

Thanks for the kind words everyone

They'll release a preview of v2.0 in Q2 and the RTM in Q3. Q2 is 'summer' (northern hemisphere) so just a couple of months away to see a stable API (with bugfixes give or take after that). We'll try to deliver a 2.0 port when their preview is ready, so Q2.

That's what I call a solomonic decision.

Also, Q3 might be as soon as July. Just sayin.

Have you guys tried out .net standard 2.0 builds at all yet?

http://yizhang82.me/dogfooding-netstandard-2

not yet, focus is on getting 5.2 out to beta. We'll start looking into the netstandard2.0 state after that so we can have a working runtime when netstandard2.0 hits 'preview' this summer. It's of no use to be earlier than that as no-one out there will use it before MS releases at least the preview.

We expect little problems porting to netstandard2.0. Only parts where things are a little rough and need some extra work is the dependency injection part and how to get the dbproviderfactory instance to the DQEs, but both have solutions, so not really big problems.

Looks like they are targeting 10.5. for 0 bugs.

https://github.com/dotnet/corefx/issues/17619

sounds good