yowl wrote:

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?

I'll answer myself, you can redirect the SPA templates project to the full framework by editing the csproj file and then there is no issue, its just not possible to change from core to full in the VS project properties window, but editing the csproj file works fine.

Edit. And thanks for the reply and congrats on the article by Scott Hanselman.

Yes you have to revert to the xml editor for the changes, same goes for multi-targeting csproj/vbproj files. It's easy to do though, so that won't be a problem.

OTOH the slowness of vs 2017 15.3 is really something...

All tests pass, runtime/templates now run for 100% on netstandard2.0 / .net core 2.0. We'll release an EAP soon (next week I hope).

YEAH! Finally new toys and new adventures!

Excellent news! Waiting for EAP.

This is indeed great news! Thanks!

Great News!Thanks

And... no features cut! Everything works as on .net full. We only needed a new configuration system as there's obviously no config file on .net core, but that's straightforward and as it's a convenient code-oriented system, we made it usable on .net full as well

Example: (there are more options available, like dependency injection and name overwriting, as well as all other options you can set both using static fields and in config file options: everything in one place)

RuntimeConfiguration.AddConnectionString("Main.ConnectionString.SQL Server (SqlClient)", "<your connection string>");
RuntimeConfiguration.ConfigureDQE<SQLServerDQEConfiguration>(c => c.SetTraceLevel(TraceLevel.Verbose)
                                                                   .AddDbProviderFactory(typeof(System.Data.SqlClient.SqlClientFactory))
                                                                   .SetDefaultCompatibilityLevel(SqlServerCompatibilityLevel.SqlServer2012));
RuntimeConfiguration.Tracing.SetTraceLevel("ORMPersistenceExecution", TraceLevel.Info);
RuntimeConfiguration.Tracing.SetTraceLevel("ORMPlainSQLQueryExecution", TraceLevel.Info);

There are some caveats regarding binary serialization, but those are related to some types not being serializable in .NET core due to MS cutting serializability on some types, so out of our hands. Some are intentional (System.Type) some are a bug (DBNull). It is what it is...

Hi Frans, how are the work going on? What are you doing beautiful inside the box?

Not that I'd think that Frans can't speak for himself but from following his twitter account (https://twitter.com/fransbouma) I'd say poor Frans is having a hell of a time struggling with drunkvs (https://twitter.com/hashtag/drunkvs) in order to get the EAP ready. Glad I'm on Mac and using Rider. (https://www.jetbrains.com/rider)

Yeah it's been less fun than I'd hoped. But! on the bright side everything's done for netcore/standard support so EAP is next week.

I wanted to add EF Core 2.0 support in as well, but in line with the quality of vs2017 15.3, MS didn't write any docs for the new features of EF Core 2.0 and told me to wait till they have the docs ready (that is a literal quote). Insane, right?

So almost there

JetBrains just told me that the EAP version of Rider with full support for .NET Core 2.0 will be available yesterday, today or next week the latest. So that fits perfectly.

I read everything thank you. I'm worried about our future ... Last time I'm trying to understand Ms if NetCore is the future because they do not invest in it? We are the third version is usually that good! I love .net but I start to be tired of waiting ...

kamiwa wrote:

JetBrains just told me that the EAP version of Rider with full support for .NET Core 2.0 will be available yesterday, today or next week the latest. So that fits perfectly.

..and LLBLGen running on Mac? ..and LLBLGen make project for Rider? ..and visual studio plugin work on rider(es service stack) Thanks

Luca75 wrote:

kamiwa wrote:

JetBrains just told me that the EAP version of Rider with full support for .NET Core 2.0 will be available yesterday, today or next week the latest. So that fits perfectly.

..and LLBLGen running on Mac?

Unfortunately not (yet)! Admittedly still using virtualized Windows (or RDPing into a Windows box) to create my LLBLGen projects and generate the code. But apart from that, my .NET development has been Mac only for at least the last six months. And don't miss Windows and VS a single bit.

Luca75 wrote:

I read everything thank you. I'm worried about our future ... Last time I'm trying to understand Ms if NetCore is the future because they do not invest in it? We are the third version is usually that good! I love .net but I start to be tired of waiting ...

It's rush rush rush at Microsoft it seems. They tried something stupid with netcore 1.0, then fell asleep while everyone complained, then suddenly woke up and scrambled that they had to release something useful with 2.0, but that takes time and they didn't take the time.

They simply released what they had, and will fix things afterwards. That's not how you release software others depend on. It's not some OSS js lib, it's a platform people built their app on. Tooling which has to work or devs can't release their stuff.

I still feel it's utter chaos over there, likely caused by the fact they've changed how they work to an OSS model that frankly doesn't really work yet (perhaps it will in the future). I mean, EF Core 2.0 without any docs of new features, wtf... 1) what are these 10 people doing all day? 2) they were done with 2.0 months before netcore2.0 release, still no docs. I'd fire them all, but hey who am I.

I wanted to add DbProviderFactories to .net core, wrote the code, submitted a PR to CoreFX, they told me along the way I had to change some method names, so I did. Then they told me, as it's a new API, it needed review, but no-one knew where that review should be submitted. So after a week or so they created their API review, and then some time passed, and they came back with a completely different API, totally not compatible with the code I had already written, and on top of that: totally unusable. So I said: I won't change my code to implement this API, why not use mine and what's wrong with my API? No answer, other than we had to start with their proposal. Some bikeshedding later over whether overloads are useful or not (really, that was the level of debate... ) things fell silent. .NET core manager pinged the datateam lead again and again when answers were to be expected. "Next week", "tomorrow", nothing happened.

Weeks have passed and nothing has changed. I've implemented my own DbProviderFactory registration method in v5.3, and I don't need it anymore (like all other ORMs which support .net core, none of them will need it anymore). But it's the chaos that struck me as depressing. I invested serious time in this and it just was a waste. (also the tooling they had to compile and run tests on corefx is terribly complex and confusing, sometimes broken, and often undocumented).

The tooling they released as 2.0, and vs 2017 15.3... it's terrible. It's full of showstopper bugs, signs that this stuff is not really release quality. Above all, it's so utterly slow. When I load our tests sln with 69 csproj files in vs 2015, it takes 30 seconds (with R#) to get up and running. in 2017 15.3 with multi-targeting projects it's more than 2.5 minutes. (!) same amount of code! Change something, e.g. recompiling the runtimes so the tests have to be recompiled... 30-50% CPU usage for minutes on end.

I reported several bugs to them in this area, made profiles/memdumps with the tooling built into vs for that. Weeks ago already, the only reply on some of them (not even all!) 'triaged', or 'under investigation'. But if you have to 'investgate' a bug for more than a few days, I know one thing: the intern who was 'investigating' it is off for a 3 week holiday. No bug takes 3+ days to 'investigate' or you should hire better devs.

When I was porting (or better: fighting the tooling) our 4000+ tests, I ran into things like DBNull.Value not being binary serializable on .net core (so serializing a datatable/typed list etc. would fail). I reported that, 2 weeks ago. They asked me if I would fix it. I replied 'no, as it's in coreclr, a repo I don't know so doing that will take a lot of time, and I don't have that', besides... just pay the devs to do the work, why would I have to work for free for MS to fix some bug they introduced themselves? Anyway, the manager said he'd ask someone. Today I read he still hasn't asked anyone, as an answer to a dev who ran into the same issue... utter chaos.

Will it get better? yes, I'm sure it will. But not today, and not tomorrow. My guess is it will take at least till 15.5/6 for vs tooling to be a bit usable, and .net core 2.1/2 to run well.

Our designer is still windows bound as it's bound to winforms and uses controls which are windows only. It's designed to be able to have a different UI though, but it'll take a lot of time to implement that, and looking at the numbers who's using .net core on other platforms than windows (for development), it's almost all windows. So not a big priority for us today.

To end on a positive note: our .NET core 2.0 stuff runs properly well and there are no problems (that I know of, other than stuff I can't fix as it's MS' problem like TransactionScope, some binary serializable types etc.). So that's one less thing to worry about when working with .NET core .

Oh and it has docs

Otis wrote:

...To end on a positive note: our .NET core 2.0 stuff runs properly well and there are no problems (that I know of, other than stuff I can't fix as it's MS' problem like TransactionScope, some binary serializable types etc.). So that's one less thing to worry about when working with .NET core .

Oh and it has docs

Thanks

Any news abut the EAP?

If everything's going as planned it should be available later today. We completed EF Core 2.0 support yesterday (not VB.NET support, we'll see if we can add that today) too so the EAP is now a solid offering. We'll add more features to it tho before RTM.

Cool!

Otis wrote:

If everything's going as planned it should be available later today. We completed EF Core 2.0 support yesterday (not VB.NET support, we'll see if we can add that today) too so the EAP is now a solid offering. We'll add more features to it tho before RTM.

Thank you. We do not know but work together for 15 years and I'm sure we will continue to play together for a long time. Thank you for your excellent work!

Luca75 wrote:

Otis wrote:

If everything's going as planned it should be available later today. We completed EF Core 2.0 support yesterday (not VB.NET support, we'll see if we can add that today) too so the EAP is now a solid offering. We'll add more features to it tho before RTM.

Thank you. We do not know but work together for 15 years and I'm sure we will continue to play together for a long time. Thank you for your excellent work!

Thanks Luca!

All, here you go: https://www.llblgen.com/tinyforum/Messages.aspx?ThreadID=24436

Feedback please in the beta feedback forum: https://www.llblgen.com/tinyforum/Threads.aspx?ForumID=57

Now that .NET Core 3.1 is out, we are porting all of our .NET Framework code to .NET Core. It is actually going very smoothly. We split out functions that are Windows specific into a separate .NET Core library that includes https://docs.microsoft.com/en-us/dotnet/core/porting/windows-compat-pack

Since you did the big port to EF Core, could you consider doing the rest as well?

Thanks!

What exactly should we still port that we haven't ?

Hmm, maybe I missed it? LOL So, how do we use the .NET core version of LLBLGen? I use the LLblGenPro ORM so would use the .NET Standard 2.0 binaries? I suggest you add the .NET Core 3.1 binaries as well, as I understand there are a number of performance improvements since standard 2.

https://devblogs.microsoft.com/dotnet/introducing-net-5/

Is a really nice post about the merging of everything into .NET 5 -- can't wait!