A piece of software with zero bugs? In which parallel universe does this exist?

Just curious if you have looked at / started trying to convert using the new 2.0 preview and if so how it looks?

Not yet, waiting for corefx escrow and preview2 for the vs2017 tooling. It looks OK. I've been porting DbProviderFactories to CoreFX for MS last week, but it didn't make the deadline, so it will be in v2.1. I think everything is easy to port over except dependency injection. Worked with corefx and the tooling there is last week to get familiar with it and I think it's not going to be much of a problem.

I'll first cut that out and port everything over, which likely will be very easy, give or take a bit of other method usage perhaps, but not much work (even binary serialization is available ) and then will look in how to feed the DI datastructures we have internally using the DI system in CoreFX, as there's no appdomain so we can't use the built in discovery stuff of our runtime.

for databases supported, it will be sql server, postgresql, firebird, likely DB2 (but they're slow in the corefx corner) and perhaps mysql if devart's mysql provider is more mature than it is now. Oracle is dragging its feet bigtime and has no ado.net provider for corefx so no oracle on .net core till they get their act together.

We'll ship 2 runtime builds, one which is netstandard20 compliant and works for corefx (.net core 2.0+), and one which is build against .net 4.5.2 full and works on netfx (.net full). I expect no template changes for this port, so that's a big win.

Perhaps devart might help with Oracle drivers? Not that I care

Don't want to appear as being impatient, but: Any news on the topic?

kamiwa wrote:

Don't want to appear as being impatient, but: Any news on the topic?

No.

I'll start porting in a few weeks. The main wait is for tooling to mature. The current preview tooling (15.3 preview) isn't really production ready so I'm holding off for now. It's OK though, porting shouldn't take that much effort as almost all types needed are available.

Been playing around with VS 2017 15.3 Preview and .NET Core 2.0 Preview 1 for the last two hours and couldn‘t agree more to what you just said.

Preview 2 announced!

https://github.com/dotnet/announcements/issues/17

Quickly: I've been watching LLBLGen for years and I finally took the plunge tonight (I read S.Hanselman). I say: this is a GREAT piece of software. The 2 videos are a very good introduction, the example code is a great learning tool, the software is easy to use, is flexible and does what it's supposed to do, and the documentation is quite good. I did it all with my database (database first) within an hour or so. I am very impressed. Frans: Congrats and thanks for your contribution.

I think I've now hit the wall when I tried a .NetCoreApp 1.1-targeted app (an ASP.NET Core Web App using .Net Core) with the LLBLGen Pro Runtime Framework?! Not sure if I understand right, but I gather I have two choices: wait for v5.3 or use Entity Framework. Do I get that right? Please educate me. Thanks. PS. If I understand right then ... I will wait for v5.3 for this new project. Thanks PPS. My only issue is: The generated code uses tabs instead of spaces; of course everyboby agrees that https://www.google.ca/#q=tabs+are+evil ! Is this a preference/settings in the app?

FrankMonroe wrote:

Quickly: I've been watching LLBLGen for years and I finally took the plunge tonight (I read S.Hanselman). I say: this is a GREAT piece of software. The 2 videos are a very good introduction, the example code is a great learning tool, the software is easy to use, is flexible and does what it's supposed to do, and the documentation is quite good. I did it all with my database (database first) within an hour or so. I am very impressed. Frans: Congrats and thanks for your contribution.

Thanks!

I think I've now hit the wall when I tried a .NetCoreApp 1.1-targeted app (an ASP.NET Core Web App using .Net Core) with the LLBLGen Pro Runtime Framework?! Not sure if I understand right, but I gather I have two choices: wait for v5.3 or use Entity Framework. Do I get that right? Please educate me. Thanks. PS. If I understand right then ... I will wait for v5.3 for this new project. Thanks

Our runtime currently supports .NET full, 3.5 and up. V5.3 will support .NET core 2.0+. We expect all features to be available on .net core 2.0 except perhaps our dependency injection system. What you can do is develop your asp.net core project on .net 4.6.x at the moment (so you can use our runtime), and when 5.3 is released move to .net core 2.0, which should be without problems (unless, as said, you use our DI system which might not make it in this first port as .net core doesn't support an AppDomain so porting our assembly discovery system over to .net core for DI is not going to work. We have to investigate what amount of work it will be to rewrite that).

PPS. My only issue is: The generated code uses tabs instead of spaces; of course everyboby agrees that https://www.google.ca/#q=tabs+are+evil ! Is this a preference/settings in the app?

Nope, sorry, tabs all the way We're using tabs since the beginning, (which was 14 years ago) and since then have kept using tabs. Spaces are more common now than tabs nowadays but we won't switch, as there will always be people who want what's currently there. Making it optional is a LOT of work as all whitespace in all templates then has to be converted and be emitted by a statement that checks the setting, for no functional gain, so I'm sorry but we won't change that. I understand some people hate tabs and want spaces, and if we'd start today we'd likely use spaces instead, but in general people don't need to alter the generated code so if we use tabs that's not a problem for you.

WayneBrantley wrote:

Preview 2 announced!

https://github.com/dotnet/announcements/issues/17

Cool! Will see if 15.3 preview2 is more stable than the last time

What you can do is develop your asp.net core project on .net 4.6.x at the moment (so you can use our runtime), and

Did that - all is fine. Smooth as butter. My only issue now (I'm sure it's simple but I looked in the forums and could not find the answer) is that the connection string is always empty (Error: The connection string is not initialized). I overrode it for now. I read that I need to copy the app.config but that did not work. I basically inserted the connection string in all the *config files (including web.Debug.config and web.Release.config) with no success. I also read somewhere that a "webapp does not read the config file automatically". Not sure if this is related. Help appreciated.

(I was just joking about tabs vs spaces - thanks for taking the time to explain).

In startup.cs, in ConfigureServices:

CommonDaoBase.ActualConnectionString = Configuration.GetConnectionString("StringName");

This is for SelfServicing, I am sure adapter is similar.

You do not have a 'web.config' to load settings from, so that is why it is not automatically loaded anymore with asp.net core.

I hope your work on .net core 2 preview went well...

Because.....it is FINAL NOW!

https://github.com/dotnet/announcements/issues/24

WayneBrantley wrote:

I hope your work on .net core 2 preview went well...

Because.....it is FINAL NOW!

https://github.com/dotnet/announcements/issues/24

The standard is finalized, the code is still in preview

Runtime + generated code are all ported. Migration of tests is a big amount of work, but I don't expect any problems. No features had to be cut, every feature is supported on netstandard2.0, including dependency injection

Not sure when they'll release a beta/golive tooling version but I expect at least a beta period before RTM. v5.3 will be out in a couple of months I think as we want to add some other things too. When they're releasing a beta/go-live version of the tooling/vs2017 15.3, we'll likely do an EAP release of v5.3 with the netstandard port.

^ Like

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

One fine bug I ran into on .NET core 2.0 which will make use cut Binary serialization from the netstandard runtime build. In short, if there's a property of type 'Type', binary serialization fails on .net core because RuntimeType isn't serializable, while it is serializable on .net full. I don't really care what bizarre bullshit reason they come up with to justify yet another f*ckup in this mess, debating this is futile so there's just one remedy here and that's sadly to cut this feature.

In practice it won't be missed by a lot of people I think.

(and holy cow is it hard to make tests run on net core 2.0 ... )

Otis wrote:

https://github.com/dotnet/corefx/issues/23213 In practice it won't be missed by a lot of people I think.

Can confirm. Won't miss it at all.

I narrowed it down to 'IFieldPersistenceInfo' being present in a relation in sync info when serializing a selfservicing entity (or an entity relation) where a 'Type' instance is present. Will now see whether that can be worked around, as it looks like it's only that 'type' instance that triggers this issue. I know it's not widely used anymore, but what I want to avoid is that I have to cut up the source too much for various platforms: if it can be ported it will be in. Stay tuned.

Can confirm. Won't miss it at all. Do people actually serialize the entities these days?

No idea, but I do know some ppl serialize entity graphs to disk or files or xml blobs to a database field (no idea why... )

Anyway, found where a System.Type got serialized into the output, which was inside an entity relation which I could work around (by serializing the type as name and re-instantiating it again on the other side). This could still fail tho, in the obscure situation where the field is of a custom type filled with a type converter, but in that Mother of all Edge Cases, the user then is SOL.

So as .NET Standard/Core 2.0 has been released, when we can expect support for it (+-)? I'm asking because we plan to release the new version of our web-site on .net core 2.0

When it's ready.

Runtime is ported, most tests are, templates are, but it's unclear when exactly things are released. We'll release an EAP when the netcore2.0 stuff is ready at least. This is still an alpha build, the final version of v5.3 is expected in a few months.

Thanks for sharing plans, Frans!

Otis wrote:

Our runtime currently supports .NET full, 3.5 and up. V5.3 will support .NET core 2.0+. We expect all features to be available on .net core 2.0 except perhaps our dependency injection system. What you can do is develop your asp.net core project on .net 4.6.x at the moment (so you can use our runtime), and when 5.3 is released move to .net core 2.0, which should be without problems (unless, as said, you use our DI system which might not make it in this first port as .net core doesn't support an AppDomain so porting our assembly discovery system over to .net core for DI is not going to work. We have to investigate what amount of work it will be to rewrite that).

I want to create an Angular 4 app, the Visual Studio SPA templates which set up an Angular project for VS target .net core 1.1 (https://channel9.msdn.com/events/Build/2017/B8073) so that should be possible with LLBLGen 5.2 if I target Entity Framework , is that right?

yes.