Home
Help
Register
Log in

Search

 
   Active Threads  

You are here: Home > LLBLGen Pro > Architecture> .NET Core
 

Pages: 1 2 3 4 5 6
Architecture
.NET Core
Page:6/6 

  Print all messages in this thread  
Poster Message
Otis
LLBLGen Pro Team



Location:
The Hague, The Netherlands
Joined on:
17-Aug-2003 18:00:36
Posted:
37967 posts
# Posted on: 18-Jan-2020 23:12:20.  
SnowHammer wrote:
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.

Our runtimes are built against .net fx and .netstandard 2.0. An assembly built against .netstandard 2.0 can be used on .NET core 2.0 and up. There's no need to build against .netcore 3.1, that's where .net standard is for. Please read: https://www.llblgen.com/Documentation/5.6/LLBLGen%20Pro%20RTF/NetFullvsNetstandard.htm

So you can use our runtime on .net core today. Just reference the packages on nuget and if you're using .net core 2.0 or higher, it's going to be taken care of by nuget for you. Regular Smiley
Frans Bouma
LLBLGen Pro / ORM Profiler Lead Developer | Blog | Twitter
 
Top
mihies
User



Location:
Nova Gorica, Slovenia
Joined on:
29-Jan-2006 16:00:15
Posted:
800 posts
# Posted on: 01-Feb-2020 11:58:16.  
SnowHammer wrote:
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.


Well, no, there is no performance difference automatically when using .NET Core 3.1 library over .NET Standard 2 one if the code itself doesn't use the enhancements.


Miha Markic
MVP C#, LLBLGenPro Partner, DXSquad
Blog, Twitter
 
Top
Otis
LLBLGen Pro Team



Location:
The Hague, The Netherlands
Joined on:
17-Aug-2003 18:00:36
Posted:
37967 posts
# Posted on: 02-Feb-2020 09:32:56.  
mihies wrote:
SnowHammer wrote:
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.


Well, no, there is no performance difference automatically when using .NET Core 3.1 library over .NET Standard 2 one if the code itself doesn't use the enhancements.

Which enhancements are we talking about btw? .NET Standard is an API definition. It doesn't contain span<T> APIs and we don't use these, is that what you're referring to? Other than that, the .netstandard version utilizes the improvements made to e.g. the .net core clr. There might be a tiny performance gain to use span<T>, in theory at least, but frankly I don't see a lot of improvement areas where we can utilize span<T> and make things faster because of it.
Frans Bouma
LLBLGen Pro / ORM Profiler Lead Developer | Blog | Twitter
 
Top
mihies
User



Location:
Nova Gorica, Slovenia
Joined on:
29-Jan-2006 16:00:15
Posted:
800 posts
# Posted on: 02-Feb-2020 17:18:20.  
Quote:
Which enhancements are we talking about btw?


C# 8 features that are not supported in .NET framework are also not supported in .NET Standard 2 I reckon. But yes, when looking at performance aspect, then it revolves mostly around span and friends. Also, I was talking in general, not strictly LLBLGenPro. I'm sure you'll go for it if there were any non-invisible gains Regular Smiley BTW Span<T> and some others are also available for .NET Standard 2 and even 1.1 but are tad inferior to the support in 2.1.

Said that I wouldn't mind eventually nullable reference types support.


Miha Markic
MVP C#, LLBLGenPro Partner, DXSquad
Blog, Twitter
 
Top
Otis
LLBLGen Pro Team



Location:
The Hague, The Netherlands
Joined on:
17-Aug-2003 18:00:36
Posted:
37967 posts
# Posted on: 03-Feb-2020 09:59:23.  
We simply can't create two codebases. Microsoft decided to create a fork in the road and offloads the shit to us library developers. We've spent a lot of time to port our code to .NET Core (first by porting to .net standard 1.6 which failed) and they keep releasing updates that are tied to one platform and not the other because *they* don't want to pick up the tab for that.

We'll see what we have to do for .NET 5, likely we'll migrate to 1 codebase for that going forward. But that's for another day.
Frans Bouma
LLBLGen Pro / ORM Profiler Lead Developer | Blog | Twitter
 
Top
WayneBrantley
User



Location:
USA
Joined on:
10-Mar-2006 16:20:08
Posted:
1118 posts
# Posted on: 03-Feb-2020 16:01:21.  
Additionally as LLBLGen uses .net framework generics and such inside - if you target .net core those framework libraries now use span where appropriate so you will automatically get those gains.

I too would like to see code cleanup of what is generated to take advantage of what the language offers - but then again what 'generates' does not really matter to me that much. This causes Otis to have to create a 'break' in his code like Microsoft did and he is understandably resistant to such a change seeing the havoc it has created.

However, while it created havoc - we can all agree we are better off for it - and I am glad they did it - they had to as the language/platform was being abandoned (and new projects were not using it).

I think .net 5 will bring clarity to Otis with what is necessary to support going forward and the reality is EVERY customer must migrate to .net core as they will kill .net framework - and that may free up some possibilities.

One such example is to abandon self-servicing framework. That represents a lot of code and support in the libraries/templates/etc - that really is not the way forward...but if he does that - some existing customers will GREATLY impacted.


SelfServicing, .Net 4.5, Web Applications, SqlServer 2014  Top
Otis
LLBLGen Pro Team



Location:
The Hague, The Netherlands
Joined on:
17-Aug-2003 18:00:36
Posted:
37967 posts
# Posted on: 04-Feb-2020 09:20:51.  
We'll never abandon selfservicing, as indeed it will be a major impact to a lot of users and that's simply not a thing we want to do. Same goes for VB.NET. It might be that adding new things like nullable reference types, span etc. in the future might not be doable in areas for selfservicing or VB.NET (I have no idea why not, but let's say that's the case Wink ), then we'd not add these to selfservicing/vb.net, like we've done in the past with some features: people will still be able to use selfservicing but might have to deal with the absence of some features, none of them deal breaking.

It's always a struggle to decide when to cut off older versions and e.g. when .NET 5 arrives, code written to run well on .net 5 with the latest features won't run on older .net fx versions however a lot of customers might still have codebases on net fx for years to come. So we have to see whether we'll freeze our runtime in time for .netfx and fork a .net 5 version off going forward, with the occasional bugfix on the 'frozen' runtime (as .net fx is frozen in time as well: no new features are added) and new stuff added to the .net 5 one.

Looking at the backlash the EF Core team got when they decided to go .net standard 2.1 only in EF Core 3.0 (and then migrated back to .net standard 2.0 in ef core 3.1), it's not the case that the vast majority of .net devs are using .net core already, but indeed, it's inevitable one day they have to.

So I think it's reasonable to assume we'll freeze the 5.x version we have at that time for .net fx and add new stuff to a .net 5 version. When that is, is a bit unclear, likely next year (I have no idea when .net 5 arrives. Looking at the sorry state of winforms/wpf on .net 5 at the moment I don't think it's any time soon Regular Smiley )
Frans Bouma
LLBLGen Pro / ORM Profiler Lead Developer | Blog | Twitter
 
Top
WayneBrantley
User



Location:
USA
Joined on:
10-Mar-2006 16:20:08
Posted:
1118 posts
# Posted on: 04-Feb-2020 14:41:48.  
I like the idea of a fork.
Also, you could do a survey of your customers to see who is using what to help understand...and those not on the 'latest', what their plans are.

For me, I have a bit of self servicing from long ago - but have done new items in adapter and will probably try to migrate away from SS over time.


SelfServicing, .Net 4.5, Web Applications, SqlServer 2014  Top
Otis
LLBLGen Pro Team



Location:
The Hague, The Netherlands
Joined on:
17-Aug-2003 18:00:36
Posted:
37967 posts
# Posted on: 04-Feb-2020 17:16:24.  
Survey sounds good, tho I think most people would simply say "yeah I want everything" Regular Smiley
In any case, if we can avoid pain in any way, we'll pick that as a favorable option, but indeed, there are tough decisions ahead, we can't do both. Luckily it's not tomorrow that we have to make this decision so when the time comes more people have migrated away from old .net versions anyway. Regular Smiley
Frans Bouma
LLBLGen Pro / ORM Profiler Lead Developer | Blog | Twitter
 
Top
kamiwa
User



Location:
Neuss, Germany
Joined on:
12-Jun-2007 13:05:59
Posted:
137 posts
# Posted on: 04-Feb-2020 19:31:01.  
Otis wrote:
Survey sounds good, tho I think most people would simply say "yeah I want everything" Regular Smiley


So let's start the survey right away then and let's do it here.
If later ppl. say, they haven't been asked, we point them here.

Like in the "Hitchiker's Guide to the Galaxy" when Arthur Dent is informed that the plans to demolish his home had been on display.
Quote:
“But the plans were on display…”
“On display? I eventually had to go down to the cellar to find them.”
“That’s the display department.”
“With a flashlight.”
“Ah, well, the lights had probably gone.”
“So had the stairs.”
“But look, you found the notice, didn’t you?”
“Yes,” said Arthur, “yes I did. It was on display in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying ‘Beware of the Leopard.”


Here's my vote if you wanted it: Already ported my complete codebase to .NET Core and Adapter. No need for SelfServicing and full .NET Framework anymore.
If not having to maintain the "old" stuff, perhaps you can then use the saved time, to create an LLBLGen plugin for Rider! Cool


  Top
Otis
LLBLGen Pro Team



Location:
The Hague, The Netherlands
Joined on:
17-Aug-2003 18:00:36
Posted:
37967 posts
# Posted on: 05-Feb-2020 17:33:46.  
Laugh

Yeah plugins for rider require kotlin, not sure that's a wise investment, considering the whole designer then has to be written in that Tongue
Frans Bouma
LLBLGen Pro / ORM Profiler Lead Developer | Blog | Twitter
 
Top
Pages: 1 2 3 4 5 6  


Powered by HnD ©2002-2007 Solutions Design
HnD uses LLBLGen Pro

Version: 2.1.12172008 Final.