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.

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.

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.

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 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.

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.

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.

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 ), 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 )

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.

Survey sounds good, tho I think most people would simply say "yeah I want everything" 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.

Otis wrote:

Survey sounds good, tho I think most people would simply say "yeah I want everything"

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.

“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!

Yeah plugins for rider require kotlin, not sure that's a wise investment, considering the whole designer then has to be written in that

Given that Microsoft say that .Net 5.0 is a unifying release and a replacement for .Net Standard 2.0/2.1, will LLBLGen get a ".NET 5.0" Platform in future?

(asking as someone who is going from .NET Framework directly to .NET 5.0 and so .NET Core and .NET Standard were something that passed me by)

It might, but it's a lot of work for effectively not a lot of gain for the user. The designer runs on windows only and Winforms / WPF will be a windows only platform on .NET 5+ as well. The DevExpress controls we use aren't plagued by the winforms lameness found in vanilla controls and use directx to render so they're fast.

Not only the UI is time consuming to move, the backend uses appdomains for various systems like importing types and the like. These have to be refactored in alternatives on .NET 5+ so we're not doing that now. We can do everything we need on .net 4.8 so there's no need to move to .NET 5+ for now.

Otis wrote:

The designer runs on windows only

I gave the current version of CrossOver (v = 21.0) another try and managed to get LLBLGen Pro v 5.8 up and running on macOS BigSur 11.5.1. My workflow is database first so I don't have much use for the model designer, thus I didn't test it in depth. Just did a basic test and created a new Model View and added a few entities to see if it does work at all.

But I'm using it on daily basis for adding or removing databases and tables to my DALs and creating and updating the code. Using MSSQL and postgreSql and so far it does work here.

Should perhaps mention that I had it running before with an earlier version of CrossOver and LLBLGen, but some LLBLGen update broke the setup.

So if you're on macOS and feeling adventurous: Try at your own risk.

I must admit, I've never heard of crossover, so can't comment on that Good to hear tho that the modelview UI works on other platforms as well, as its core is C++ I think. I tried to replace it with DevExpress' diagramming library but that's so utterly slow it was of no use.

Otis wrote:

I've never heard of crossover

CrossOver is a commercial software by CodeWeavers based on the OSS WineHQ project.

CrossOver website

From the WineHQ website:

Wine (originally an acronym for "Wine Is Not an Emulator") is a compatibility layer capable of running Windows applications on several POSIX-compliant operating systems, such as Linux, macOS, & BSD. Instead of simulating internal Windows logic like a virtual machine or emulator, Wine translates Windows API calls into POSIX calls on-the-fly, eliminating the performance and memory penalties of other methods and allowing you to cleanly integrate Windows applications into your desktop.

WineHQ website

So if you're feeling really adventurous you could as well give WineHQ a try.

Otis wrote:

It might, but it's a lot of work for effectively not a lot of gain for the user. The designer runs on windows only and Winforms / WPF will be a windows only platform on .NET 5+ as well. The DevExpress controls we use aren't plagued by the winforms lameness found in vanilla controls and use directx to render so they're fast.

Not only the UI is time consuming to move, the backend uses appdomains for various systems like importing types and the like. These have to be refactored in alternatives on .NET 5+ so we're not doing that now. We can do everything we need on .net 4.8 so there's no need to move to .NET 5+ for now.

To be honest, I'm fine with the designer as it is - I was just referring to the generated code and in particular the Platform dropdown where you have to choose .NET Standard even though that isn't the actual intended platform - just a compatible one.

I've just changed TargetFramework in my DAL projects to "net5.0-windows7.0" get it to compile and that seems to work - my DAL project has a reference to another project with that target framework so isn't as 'pure' as a normal LLBLGen project I guess.

I guess one win might be you could target people that use other platforms than Windows to use LLBLGen designer to manage everything. Now that .net core is cross platform that might be something to consider in the future.

Just a thought...

simmotech wrote:

Otis wrote:

It might, but it's a lot of work for effectively not a lot of gain for the user. The designer runs on windows only and Winforms / WPF will be a windows only platform on .NET 5+ as well. The DevExpress controls we use aren't plagued by the winforms lameness found in vanilla controls and use directx to render so they're fast.

Not only the UI is time consuming to move, the backend uses appdomains for various systems like importing types and the like. These have to be refactored in alternatives on .NET 5+ so we're not doing that now. We can do everything we need on .net 4.8 so there's no need to move to .NET 5+ for now.

To be honest, I'm fine with the designer as it is - I was just referring to the generated code and in particular the Platform dropdown where you have to choose .NET Standard even though that isn't the actual intended platform - just a compatible one.

No that's intentional, as all the .NET Core frameworks (including .NET 5/6) all support the same APIs in .NETstandard 2.0, and that's why we target that. It's common to target netstandard2.0 in libraries which are consumed solely by .net core 3.x+. We could have given a list of .net core+.net 5 + frameworks but it all would be the exact same code so we use netstandard20 for that. You can always change it later (as you've done indeed) and that's kept as-is so it's not overwritten next time.

I've just changed TargetFramework in my DAL projects to "net5.0-windows7.0" get it to compile and that seems to work - my DAL project has a reference to another project with that target framework so isn't as 'pure' as a normal LLBLGen project I guess.

Yeah then that's to be expected.

WayneBrantley wrote:

I guess one win might be you could target people that use other platforms than Windows to use LLBLGen designer to manage everything. Now that .net core is cross platform that might be something to consider in the future. Just a thought...

If winforms/wpf would be ported to mac/gnome/kde then it would indeed be a route we might want to look at. Sadly as things are now, the desktop GUI platforms on .net 5+ are all tied to windows (they're busy with a new one but they're always busy with a new one so I'll wait till it's usable), so migrating for that isn't going to make the designer cross platform.

As it is today (and in the near future) to have a cross platform designer it has to get a completely new GUI.