Hello Frans,

We are investigating a migration to ASP.NET Core and possibly a shift from the .NET Framework to the .Core Framework. We need some authentication which is only available in ASP.NET Core. In my investigation about all this .Core stuff I came across an article from you, where you are critical about this change.

http://weblogs.asp.net/fbouma/%E2%80%9C-net-core-is-the-future%E2%80%9D-but-who%E2%80%99s-future-is-that

I'm wondering if more than a year later you still have the same opinion. A year ago I only vaguely knew about .NET Core and now I'm investigating an upgrade. Navigating around on the internet it look like Core is gaining momentum, but most (all?) argument in your post are still true.

Btw we are only considering taking our weblayer to .NET Core, our Business Layer where LlblGen is situated is not in scope. So in the near future we won't be banging on your door for a LlblGen .Core version .

Regards Alexander.

I'm still skeptical about .NET core, simply because it lacks a lot of functionality that should be in a standard framework, it fragments assemblies to little pieces (which is a terrible thing, IMHO), is mainly driven by ASP.NET and it's to be seen whether it will take off. I still think it's an effort to keep web devs from leaving for other platforms, and together with that it actually fragments the .NET space, which I find a big problem.

That said, the tooling they created is about to become at least usable with RC2. They also have implemented things I've requested (or are in the process of implementing) and that's a good thing. So I'm actually waiting for RC2 to land with the final tooling to see what can be done, as starting a porting effort at the moment is useless, things change drastically in RC2.

I can't leave my customers in the cold with EF core, that's for sure. I will try to port our runtime, but I'll also cut out a lot of stuff (only port adapter, no VB.NET, no serialization). But I don't have a time frame. v5.0 is around the corner, I'll add CoreFX with EF core support soon after that when RC2 is released and will see what is best then: porting our runtime or wait a bit. I'm leaning towards waiting a bit, as MS has invested a lot on different frameworks before and all of these frameworks died eventually.

Thanks for your thoughts. Waiting seems the sensible thing to do.

We definitely would have waited a bit longer but I found out that support for OpenID Connect seems way better in ASP.NET Core. But as said I think I can use .NET Core or .NET Framework and still have OpenID Connect (gonna do a Proof of Concept soon) so using .NET Core is undecided.

We have the luxury that we just started with a new website so migration is feasible.

My 2 cents on this.

Currently we are looking for a tech stack to start new project. .NET Core as API looks as quite interesting choice. One of advantages - same code have ability to run also on Linux/Mac. So LLBLGenPro on this could be a great thing to have

Maybe this will help to speedup some prototype?

regards Mantas

FYI Mono runs on all three platforms (including LLBLGenPro) and more. Today. You can consider writing for mono and switch to .net core once it is stable and Frans added support.

Yes, I am considering this option too, thanks

mihies wrote:

FYI Mono runs on all three platforms (including LLBLGenPro) and more. Today. You can consider writing for mono and switch to .net core once it is stable and Frans added support.

Fun fact: I'm experimenting with Raspberry PI as well. Server stack runs fine on first tests.

We'll try to port our runtime (and templates) to .net core starting with RC2, but it won't be simple. There's 500K LoC in the runtime alone, so it will be a longer feature but hopefully porting will be relatively smooth once I've cut the things which won't work anymore like remoting and xmlserialization (although they'll port back remoting it seems).

It's a shame they're messing with the project file types so it's a rough ride.

For me DAL querying functionality is much more important than Remoting, Serialization, OData, etc.. Even if I have a lot of functionality which relies on serialization, for me more common way to make own DTO objects which I can serialize as it has less information and I have more control on this. But of course, maybe other people are using it extensively.

cerberis wrote:

For me DAL querying functionality is much more important than Remoting, Serialization, OData, etc.. Even if I have a lot of functionality which relies on serialization, for me more common way to make own DTO objects which I can serialize as it has less information and I have more control on this. But of course, maybe other people are using it extensively.

Same here.

We also have our own objects which are for a great part the same like the Entity objects because of the size.

And you can do porting the same way MS has done, if it's difficult skip and call it LlblGen Core 1.0, we won't blame you

cerberis wrote:

For me DAL querying functionality is much more important than Remoting, Serialization, OData, etc.. Even if I have a lot of functionality which relies on serialization, for me more common way to make own DTO objects which I can serialize as it has less information and I have more control on this. But of course, maybe other people are using it extensively.

That's also what we're thinking. With derived models now a first-class citizen in the designer, it's not hard to define models for serialization that way.

AlexanderM wrote:

We also have our own objects which are for a great part the same like the Entity objects because of the size.

And you can do porting the same way MS has done, if it's difficult skip and call it LlblGen Core 1.0, we won't blame you

heh . Well, I hope to port as much as possible actually, as migration paths are IMHO very important: you see it a lot among EF6 users that they're confused what to do as they're faced with a fork in the road with only options that suck: EF7 which is very limited, or EF6 which is EOL (more or less). We'll see what's easy to port. There are a couple of things I want to get rid of though, one thing is the collection classes of selfservicing, so I'll port Adapter first and also as MS doesn't have support for VB on .NET core yet, it won't be part of the focus for us either.

Forget about EFx... nHibernate, etc.. Starting with LLBLGen framework adapter scenario would be best option

I was going to, but then MS released info they're going to approach the whole .NET core BCL completely different (with a linker, not with hand-crafted dlls). So I'll keep it off for now, as it looks like porting is not going to be needed in the (near) future, as all api's are going to be present

Hello Frans can you give us any update on how and in what time we can use our loved framework in netcore ? Thank you

Luca75 wrote:

Hello Frans can you give us any update on how and in what time we can use our loved framework in netcore ? Thank you

There's currently no timeframe as there are two things which are crucial that are missing: 1) an updated roadmap from Microsoft when their linker system will arrive 2) an updated roadmap from Microsoft when more classes are ported to .NET core from the BCL.

These two are related btw. Our runtime is ~500K LoC and the templates are too a lot of code so altogether we estimate roughly 1M LoC have to be ported (that's outside of the thousands of tests we have!). This isn't a small undertaking, it's a massive project to do, for the reason that a lot of functionality in the runtime relies on classes which aren't there (yet) in CoreFX.

So this means that if we port now (which means, we start now, but are finished in a couple of months which is very optimistic), we have to cull a lot of code from the runtime simply because it relies on APIs that aren't in CoreFX. It also means that when these APIs are added to CoreFX, we have to port the culled code, but that also means effectively we have to port the whole system again, as it's not something simple as 'exclude these files and things work fine on coreFX and add them later again if classes are added'.

Microsoft knows this and some time ago started working on a linker system based on the Xamarin model. This means that you don't program against a set of hand-created assemblies but simply compile against a standard and the compiler + linker creates a working set of code for you. This effectively means it solves the cull now, port again later problem: all APIs in full will be present, they'll be linked to different versions of the code in the target frameworks, e.g. full BCL classes if targeted netstandard 1.3, CoreFX if targeting netstandard1.6.

So it's a problem at the moment: we can't simply do this porting process a couple of times, we either do it once or not at all. Porting now and adding a tremendous amount of #ifdef's to the code, not to mention fighting a lot of with the immature tooling for corefx/.net core, will only make sure we have to do the porting process a couple of times simply because each time Microsoft adds a new API to CoreFX which is used by code we had removed to compile it regardless on CoreFX we have to look at all the culled code and check whether it is addable at that point.

Then I haven't even mentioned the project.json -> csproj/msbuild move they're doing at the moment, of which they themselves said they don't know yet what to do with project.json. The runtime is a couple of projects in 1 solution (8 or so), so although it would be a pain, it's manageable. It's a different story for our tests, which for sqlserver alone are 66 projects in a single solution. Most of them generated, but still. All of them have to be ported to CoreFX as well. 67MB of C# code, over 4700 files, have to be stored somewhere in a project format that's unknown (there's not a schema spec for project.json, tooling is in 'preview' and very immature).

I did start porting though, or better: I tried to start porting a smaller library, but the tooling already failed to help me (this was RC2) get things working in the editor with proper #ifdef's. An example of that is that if something is excluded for a project e.g.

#ifdef COREFX
// coreFX code
#else
// full code
#endif

it should grey out the code which is excluded. This works for normal C# projects, the tooling currently doesn't do this. It's a simple example, but for us important.

The code in the runtime is at some places over 13 years old. It works great, but there are things which aren't really 'in use' anymore, like the binary serialization support or even the XML serialization support. Porting the code makes it difficult at the moment, as culling code like that might look 'easy', but adding it back when CoreFX gets support for these APIs again (and it will!) isn't simple. Not to mention that serializing entity graphs to JSon relies on ISerializable implementation to avoid a cyclic reference mess in JSon.NET and you're already in rock-hard-place land before you know it

I want to add that we do want to port our runtime, especially considering the fact that EF core is feature-wise very simple and limited, plus we're faster too. But porting our runtime isn't a project done in a weekend, sadly, it takes a lot of time and as it's not a simple project it shouldn't be done more than once.

For now we want to wait a bit: more APIs should be added to CoreFX, what are the plans from MS about their linker / tooling offering regarding existing large code bases. At the moment it's completely unknown what they're going to do, when what is added. I'm sorry I don't have better news for you.

(edit) I've emailed Microsoft to hear more about the elements I listed above as very important, to see if / when more information is available so we can plan ahead.

Hello Franz thanks for your answer. I would like to develop new projects on MVC6, in my Netcore has not even an access to good data system .If I were you I would try to look at it as an opportunity! I understand at this time porting is really very expensive. You can post a request on GitHub because they give us a roadmap on the necessary implementations? We could invite the forum users to sign it .. I think groped not harmful, maybe we can draw attention to the problem, in the end I think both improve Netcore interest of all. In theory, now with the new philosophy of "Open Source" Microsoft should direct its efforts in the direction that the community members require .. let's give him a chance, for them should not be a lot of work .. I think that if you wait for the LLBLGen framework is totally portable Netcore be long and who will be forced to urgently find alternative solution.

Great ! Well done! Keep us updated please

Hello Franz have an idea of whether and when LLBLGen Studio 1.0 will support EFCore ? Thank you

Luca75 wrote:

Hello Franz have an idea of whether and when LLBLGen Studio 1.0 will support EFCore ? Thank you

Planned for 5.1

Great! Thanks

I tried to modify LLBLGenPro templates in order to generate .NET Core project targeting .NET 4.6.1. Everything looks fine, except that project file generation fails second time with exception:

Exception type: GeneratorAbortException The VS.NET project file is for an older version than VS.NET 2010 so you first have to upgrade that project file in VS.NET 2010.

Is there any way to fix this? Probably you know more what is validated at this point, so maybe I can add it to xproj file

I am using 4.2 May 4th 2016 version.

the sourcecode of the code generator is available in the 'extras' section so you could have looked there, but in any case, it's in the ProjectFileCreator.cs, line 411:

XmlNode targetVersionFromFile = projectDom.SelectSingleNode(String.Format(@"/{0}Project/{0}PropertyGroup/{0}ProductVersion", nsprefix), nsmgr);
if(targetVersionFromFile==null)
{
    // not found
    throw new GeneratorAbortException(
        "The VS.NET project file is for an older version than {0} so you first have to upgrade that project file in {0}."
            .AsFormatted(ConvertToVSNetDescription(versionToTarget)), this.ActiveTask);
}

this is a check which has been removed in v5, but in v4.x it still tests what version the project file is as vs.net 2008 project files needed migration.

I think xproj files don't have a <project><propertygroup><projectversion> element and it therefore fails. To make this work in v4 you have to alter the sourcecode and use a custom built task performer for this.

Great! xproj is still xml file as csproj and simply adding manually this node works like a charm!

Thank you.

cerberis wrote:

Great! xproj is still xml file as csproj and simply adding manually this node works like a charm!

Thank you.

Heh, adding the xml element of course also works, but not sure if vs.net will leave it in if you save it again. Just in case it doesn't, a custom task performer build is then what fixes it