Forum:  Architecture

Thread:  .NET Core


AlexanderM (User)   Posted on: 24-Mar-2016 09:36:17.
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 Cool .

Regards Alexander.
Otis (LLBLGen Pro Team)   Posted on: 24-Mar-2016 10:38:00.
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.


AlexanderM (User)   Posted on: 25-Mar-2016 12:44:56.
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.
cerberis (User)   Posted on: 12-May-2016 14:41:51.
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 Regular Smiley

Maybe this will help to speedup some prototype? Regular Smiley


regards
Mantas


mihies (User)   Posted on: 12-May-2016 15:09:00.
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.
cerberis (User)   Posted on: 12-May-2016 15:13:18.
Yes, I am considering this option too, thanks Regular Smiley

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.



mihies (User)   Posted on: 12-May-2016 15:16:47.
Fun fact: I'm experimenting with Raspberry PI as well. Server stack runs fine on first tests. Regular Smiley
Otis (LLBLGen Pro Team)   Posted on: 12-May-2016 17:33:13.
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.


cerberis (User)   Posted on: 13-May-2016 08:20:35.
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.
mihies (User)   Posted on: 13-May-2016 09:39:32.
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.


AlexanderM (User)   Posted on: 13-May-2016 14:43:39.
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 Tongue
Otis (LLBLGen Pro Team)   Posted on: 13-May-2016 17:50:40.
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. Regular Smiley 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 Tongue

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


cerberis (User)   Posted on: 01-Jun-2016 20:20:38.
Forget about EFx... nHibernate, etc..
Starting with LLBLGen framework adapter scenario would be best option Laugh
Otis (LLBLGen Pro Team)   Posted on: 02-Jun-2016 14:48:29.
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 Regular Smiley

Luca75 (User)   Posted on: 29-Jun-2016 13:31:29.
Hello Frans can you give us any update on how and in what time we can use our loved framework in netcore ?
Thank you
Otis (LLBLGen Pro Team)   Posted on: 29-Jun-2016 15:13:52.
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.

Code:

#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 Regular Smiley

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.


Luca75 (User)   Posted on: 29-Jun-2016 19:23:07.
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.
Luca75 (User)   Posted on: 29-Jun-2016 19:26:13.
Great ! Well done!
Keep us updated please


Luca75 (User)   Posted on: 30-Jun-2016 20:29:07.
Hello Franz have an idea of whether and when LLBLGen Studio 1.0 will support EFCore ?
Thank you
Otis (LLBLGen Pro Team)   Posted on: 30-Jun-2016 21:01:28.
Luca75 wrote:
Hello Franz have an idea of whether and when LLBLGen Studio 1.0 will support EFCore ?
Thank you

Planned for 5.1


Luca75 (User)   Posted on: 30-Jun-2016 21:51:53.
Great!
Thanks
cerberis (User)   Posted on: 28-Jul-2016 08:53:26.
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 Regular Smiley

I am using 4.2 May 4th 2016 version.


Otis (LLBLGen Pro Team)   Posted on: 29-Jul-2016 12:28:31.
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:

Code:
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.
cerberis (User)   Posted on: 29-Jul-2016 12:34:19.
Great!
xproj is still xml file as csproj and simply adding manually this node works like a charm!

Thank you.


Otis (LLBLGen Pro Team)   Posted on: 29-Jul-2016 13:39:59.
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 Wink
WayneBrantley (User)   Posted on: 15-Sep-2016 14:39:34.
ceberis,
Would you mind sharing your template modifications? Perhaps upload to this thread?

Otis,
I really hope you have started on your 500k lines of code. We have started using .net core and really like it. I am ALMOST faced with the decision of LLBLGen or something else.

For example, we created a new api service recently and use .net core. We were almost faced - because there are still a couple of other libraries that are not on .net core, but they are all in process. Had everything been dotnet core but your library - then we would need to choose something else. Not sure that that something else is, I guess you would be forcing me to EF (yuck) or maybe I would just use dapper.

I know you have shared your reason for not doing it yet, but many it would be great. Many things that are no longer supported in core, we personally do not care about (xml serialization,etc). This would give you a GREAT chance to 'clean slate' and remove lots of stuff that is not really necessary anymore (or at least break that out into another package that depends on .net 4.6.1)

Point is, WE WANT OUR LLBLGEN and I want to pressure you to get this delivered! Laugh


Otis (LLBLGen Pro Team)   Posted on: 15-Sep-2016 18:00:00.
Port will still happen, but we'll wait for .NET standard 2.0. At the moment it's simply not doable, too much isn't there. MS knows this, hence they're going to do it differently now: no longer hand-crafted mini assemblies but a linker system which will be much easier to port code with.

Porting things over and removing old stuff aren't the same thing, something MS also realized after .NET core 1.0 release. So porting will likely be in full. If we have to maintain 2 libraries it will be a pain. (and one of the main issues a LOT of fellow ISVs are facing with respect to .NET core: porting code to .NET core means maintaining two different libraries which are effectively a fork. )
cerberis (User)   Posted on: 15-Sep-2016 18:10:10.
If it helps.. why not Regular Smiley
Its not much.. we just xproj projects so that later we should be able easier to migrate to proper .netcore lib.



WayneBrantley (User)   Posted on: 15-Sep-2016 20:36:17.
So, if I were to extrapolate your stance....
Q2 2017 for .net standard 2.0
Plus port, test and release time
All equals Q4 2017 at the earliest for llblgen core support?

Is that a fair estimate?
Otis (LLBLGen Pro Team)   Posted on: 16-Sep-2016 09:33:17.
I have no idea, could be. I can do an estimate but estimating "when it's is done" based on no info at all other than that MS will release .net standard 2.0 is of no value. For example, I have no idea how much work it will be and whether it will be interesting at all. In the past 13 years I've added support for many frameworks of MS which are all dead. Not that I think .net core will die off, but in what form it will live on is unknown. So we'll see when .net standard 2.0 is presented, their roadmap for tools and then we can see what is possible. Before that it's of no use to say anything.



WayneBrantley (User)   Posted on: 16-Sep-2016 15:00:26.
Understood. I know it can get WORSE than what I presented. Looking at best case Q3/Q4 of next year. Just need to know that factor when deciding if we can wait on a project for that..or must use something else.

Thanks.
Otis (LLBLGen Pro Team)   Posted on: 16-Sep-2016 16:23:11.
WayneBrantley wrote:
Understood. I know it can get WORSE than what I presented. Looking at best case Q3/Q4 of next year. Just need to know that factor when deciding if we can wait on a project for that..or must use something else.

Thanks.

From what I've seen, using EF core on .NET core is really 'early adopter' area, they even say so themselves. They expect to have a better runtime in the same timeframe so I think before .NET standard 2.0 and the stuff it will bring, using .NET core with an ORM is really risky. (E.g. EF core runs all group bys in memory, to name a little detail Wink).

So there's little alternative but to wait, or run on .NET full (with asp.net core, which is fully possible, and in that scenario you can use our runtime without problems).

You're looking at using .NET core as the framework or is it more asp.net core you're interested in? (if you're running on windows, .net full + asp.net core makes more sense now)


mihies (User)   Posted on: 16-Sep-2016 16:35:59.
... or running on Linux/mono if you want to. It runs it is just mono isn't that asp.net oriented (AFAIK).
WayneBrantley (User)   Posted on: 16-Sep-2016 16:59:38.
1) As we start to convert standard class libraries to core libraries and change how everything works, we want to target the lowest thing possible. If they depend on LLBLGen, that means they have to use full net framework. So, depending on the use, see below - may make sense to remove that dependency.

2) We created a new asp.net core site recently and targeted .net core framework (I hate how these terms are overloaded). We installed all the items we needed, trying to retain .net core framework so we could attempt to host this on Linux. We came down to your product and one other that uses RestSharp (which has a core version we had issues with) that was the reason we could not do it.

Since I needed the other library AND LLBLGen, I gave you a pass Laugh.
However, if everything had been done, I would have dropped LLBLGen for Dapper or EF to get it to run under linux in a docker.

Our use of LLBLGen is usually pretty simple. Basic CRUD - no serializing, no wcf, no extra crap of any kind...just straight linq projecting to POCO. Raw database access read and write. I would probably choose dapper. Of course that means I can write SQL in my code...which is both great and HORRIBLE and I have to worry about sql injection if not done correctly, etc.

I just see a time by the beginning of the year that your product is potentially the only one we use without some sort of a version on core.

Again, nothing above is a criticism or anything, just trying to know where everything will land and when. We definitely cannot move and are not moving at this time. Same issues as you have. However, when the new tooling comes out we will be attempting to move to .core projects that target the full framework. If any of our libraries can target core, we will do that as we can. I am listening to you and attempting to wait as long as I can, if waiting makes it so much easier.

If your product is done when standard 2.0 releases (because you worked on it at the same time using previews, etc), then that would probably be great. But if it is another year (based on your code size, etc), then we will probably be forced to use some DEFINITELY inferior method of data access.



Otis (LLBLGen Pro Team)   Posted on: 19-Sep-2016 19:12:31.
I agree with your points, and I wished we had something for .NET core at the moment. The main problems are however:

1) the tooling is currently terrible: project.json is on its way out and csproj based .net core projects aren't really working as the tooling is in preview. This requires a lot of head scratching and time wasting to get simple things working (I tested the waters with one of our OSS projects, it wasn't pretty Angry )
2) porting a large library now means the whole process of porting the library again has to be done when MS updates the .NET core BCL. This might sound strange, however think about it this way: say the library contains 500 features. Of these 500, currently 200 can be ported to .NET core's BCL (as a lot is missing). When MS updates the .NET core BCL, another 150 can be ported. However, this means the whole codebase has to be ported again because which of the remaining 300 can be ported? That's a time consuming process.

So porting libraries is doable if the .NET core BCL is a bit bigger. We still realize and accept we have to add a lot of #ifdef's, that's fine. I just want to add them once, not every month. I also don't care whether binary serialization or xml serialization can't be ported, that's life. Regular Smiley The main pile of work is simply porting the massive code base over, including the templates. This is a time consuming process which can't be done every several months because MS released a new assembly or 2 for .NET core.

Luckily they realize this too hence .NET standard 2.0. It might very well be .NET standard 2.0 still lacks a lot of features required for some features in our library, but that's OK. The majority of the code at least can make the cut and we can then be sure we don't have to re-port the library every 2-3 months. (which is impossible to do btw).
cerberis (User)   Posted on: 19-Oct-2016 07:55:21.
Not sure if this is right thread to write, but as it is .NET Core related..
We are trying to integrate MySQL database in .NET Core (targeting 4.6 full framework) project with LLBLGen 4.6 (build 20160929).

I know there are thread in corefx about it: https://github.com/dotnet/corefx/issues/4571

Anyway, until it is fixed I am trying to get it working.
I already did override in Adapter to replace DynamicQueryEngine with custom one:
Code:

        protected override DynamicQueryEngineBase CreateDynamicQueryEngine()
        {
            return new MySqlDynamicQueryEngine();
        }


and did this

Code:

    public class MySqlDynamicQueryEngine : DynamicQueryEngine
    {
        protected override IDbSpecificCreator CreateDbSpecificCreator()
        {
            return new CustomMySqlSpecificCreator();
        }
    }

    public class CustomMySqlSpecificCreator : MySqlSpecificCreator
    {
        public override DbProviderFactory FactoryToUse => new MySqlClientFactory();
    }


However.. your MySqlSpecificCreator has this in field declarationL
Code:

private static readonly DbProviderFactoryInfo _dbProviderFactoryInfo = new DbProviderFactoryInfo();


And DbProviderFactoryInfo has this:
Code:

        public DbProviderFactory FactoryForReflection
        {
            get
            {
                if(_factoryForReflection==null)
                {
                    // creates factory
                    DbProviderFactory dummy = this.FactoryToUse;
                }
                return _factoryForReflection;
            }
        }



And this...
Code:

        static DynamicQueryEngine()
        {
            Switch = new TraceSwitch("MySqlDQE", "Tracer for MySql Dynamic Query Engine");

            // grab all provider factories of the supported providers.
            DataTable definedProviders = DbProviderFactories.GetFactoryClasses();
            MySqlSpecificCreator.SetDbProviderFactoryParameterData(new List<ValuePair<string, string>>()
                {
                    new ValuePair<string, string>(InvariantDevartProviderName, "Devart.Data.MySql.MySqlType"),
                    new ValuePair<string, string>(InvariantCoreLabProviderName, "CoreLab.MySql.MySqlType")
                }, "MySqlType");
.....

// where MySqlSpecificCreator.SetDbProviderFactoryParameterData is not possible to override....


That property for some reason is used in InitializeEnumTypeCache method and I don't have any way to override it.. except copy all MySqlSpecificCreator and remove the code which uses DbProviderFactories...

Any option to make a possibility to override it there?
Any other suggestions?

One more option of course to change ORM, but that's the last thing I want to do Regular Smiley

P.S. Otis you should stop using static methods/classes.. its antipattern Regular Smiley

regards
Mantas




Otis (LLBLGen Pro Team)   Posted on: 19-Oct-2016 09:57:20.
cerberis wrote:
Not sure if this is right thread to write, but as it is .NET Core related..
We are trying to integrate MySQL database in .NET Core (targeting 4.6 full framework) project with LLBLGen 4.6 (build 20160929).

You mean asp.net core? As .net core is a framework just like .net full. So using .net core targeting .net full doesn't make any sense.

So I don't really understand what you're doing, as our framework doesn't run on .net core. In asp.net core, it should work properly, as the dbproviderfactory is obtained from the machine.config settings in the .net full configuration, so it's no problem.

Quote:

I know there are thread in corefx about it: https://github.com/dotnet/corefx/issues/4571

That's a thread about .net core, not .net full. for .net full things should work normally.

Quote:

            // grab all provider factories of the supported providers.
            DataTable definedProviders = DbProviderFactories.GetFactoryClasses();
            MySqlSpecificCreator.SetDbProviderFactoryParameterData(new List<ValuePair<string, string>>()
                {
                    new ValuePair<string, string>(InvariantDevartProviderName, "Devart.Data.MySql.MySqlType"),
                    new ValuePair<string, string>(InvariantCoreLabProviderName, "CoreLab.MySql.MySqlType")
                }, "MySqlType");
.....

// where MySqlSpecificCreator.SetDbProviderFactoryParameterData is not possible to override....


That property for some reason is used in InitializeEnumTypeCache method and I don't have any way to override it.. except copy all MySqlSpecificCreator and remove the code which uses DbProviderFactories...

Any option to make a possibility to override it there?
Any other suggestions?

That method obtains the factory, and generates a setter method for the ado.net provider specific property on DbParameter to set the enum value which specifies the ado.net provider specific type. It grabs the type enum and generates string-> real enum conversion tables. So it can do that without referencing the actual assembly, which is a good thing. Not sure what you want to change about that?

Quote:

P.S. Otis you should stop using static methods/classes.. its antipattern Regular Smiley

Antipattern? Says who? Some lecturing consultant who is a bad programmer so he writes books?

So, in short: I have no idea what you're doing nor trying to achieve, nor what the actual problem is you're trying to solve?
cerberis (User)   Posted on: 19-Oct-2016 13:49:39.
Basically trying to solve this:

An unhandled exception occurred while processing the request.
ORMGeneralOperationException: None of the factories in the list of "Devart.Data.MySql, CoreLab.MySql" were found.
Please check machine.config and the .NET version your application is running on.
TypeInitializationException: The type initializer for SD.LLBLGen.Pro.DQE.MySql.DynamicQueryEngine threw an exception.


And no, I cannot modify machine.config. Regular Smiley

ASP.NET Core is nothing else just console application listening on specified port and accepting requests. So there is no difference is it ASP.NET Core or .NET Core app..

And static methods are antipattern because it is hard to test, it is hard to override, reusing such code results in hard coupling of the code.
In your case you are allowing to override class in one place, but still using static method of your class for some methods.


Otis (LLBLGen Pro Team)   Posted on: 19-Oct-2016 17:16:55.
cerberis wrote:
Basically trying to solve this:

An unhandled exception occurred while processing the request.
ORMGeneralOperationException: None of the factories in the list of "Devart.Data.MySql, CoreLab.MySql" were found.
Please check machine.config and the .NET version your application is running on.
TypeInitializationException: The type initializer for SD.LLBLGen.Pro.DQE.MySql.DynamicQueryEngine threw an exception.

And no, I cannot modify machine.config. Regular Smiley

But surely you've installed the mysqlconnect provider with the installer?

Quote:

ASP.NET Core is nothing else just console application listening on specified port and accepting requests. So there is no difference is it ASP.NET Core or .NET Core app..

.NET core is a platform, it's a .NET flavor. ASP.NET is a web framework, completely different. ASP.NET core isn't the same as .net core at all, it's comparing apples with trucks.

ASP.NET core doesn't use a web.config file, so I think that's part of the problem? Didn't any of the solutions here help you? https://docs.asp.net/en/latest/fundamentals/configuration.html

Quote:

And static methods are antipattern because it is hard to test, it is hard to override, reusing such code results in hard coupling of the code.

Who told you that bullshit? Some methods aren't extension points so aren't overridable, whether they're static or not. That you don't like that is too bad, but it's not up to you to decide what is an extension point. Hard to test, by whom? I can test them without problems. Static methods are part of OO programming. What's wrong with a function?

Quote:

In your case you are allowing to override class in one place, but still using static method of your class for some methods.

Yes, because you are arguing that a random point in the code should be an extension point for you while it's not. The code you refer to is a static constructor. It runs once, and for a reason, it does things which are potentially slow. It is done this way so threading issues aren't a problem and locks aren't needed. Yes, this isn't extensible, but static constructors aren't a spot for extensibility anyway (nor are normal constructors).

My code isn't bad, it's not meant to extensible in a way you want it to, simply because elsewhere things go wrong, namely asp.net core doesn't offer a way to specify the DbProviderFactory, and then _my_ code is inflexible and not extensible?

Have you asked the ASP.NET team how to solve this? It's .NET full after all, not .net core, and it offers a way to define DbProviderFactory definitions.

It's actually a problem of ASPNET core not being able to use resources properly on .NET full. Or better, to register a custom factory. See this issue: https://github.com/dotnet/corefx/issues/6476. There's an api underway which solves this, however it's not yet available (will be after .NET full v4.6.2) where you can register the factory in code. That would solve things properly. I could add a method which registers a factory in some static (yes! because some things are stored only once) structure but that's actually moot as it will be obsolete forever once MS does their job for once and implements code which actually works and adds that api I referred to above.
cerberis (User)   Posted on: 19-Oct-2016 21:43:59.
Quote:

But surely you've installed the mysqlconnect provider with the installer?


Well.. not, I am just deploying my application which uses only nuget..

I was able to get it working by simply grabbing and modifying complete files from LLBLGenPro sources:
MySqlSpecificCreator
DbProviderFactoryInfo
MySql.DynamicQueryEngine

Well.. that's not nice, but at least its working.

Probably my issue that I do not use Devart or CoreLab providers but taking the one which is provided by MySql (and than I am not sure if thats .NET Core issue of course).
This might mean that our discussion is worthless Regular Smiley

Anyway, thanks for help.


Otis (LLBLGen Pro Team)   Posted on: 19-Oct-2016 23:32:21.
The one from MySQL is GPL licensed, and therefore not supported. By using that one you have to GPL license your own code as well, or buy a license from them. This is NOT a joke, they are actively pursuing this, you've been warned Regular Smiley. They told me this themselves, it's not something you can get away with. If you don't GPL your own code, they will see you as violating the GPL.

Stay away from their driver, it's not only a big pile of crappy code, it's also bad for your own code, due to their draconian licensing.

Just use the free devart one (the lite version, it has all you need, no GPL license).

So, yes, using that MySQL ado.net provider will cause a problem with the factories. It also will likely not work at runtime due to mapping differences in types. And perhaps keel over in the middle of a query because of their shitty code.

But it's your call.
Otis (LLBLGen Pro Team)   Posted on: 10-Nov-2016 18:15:41.
Just a heads up to all here, we've started development of LLBLGen Pro runtime framework on netstandard1.6, so porting the library, templates to .NET core.

We moved this up as we saw how poor Entity Framework Core really is so it's a window of opportunity not to be missed Wink

We don't have an ETA as it's early days, we also don't even know if we can port it at all, but we'll try.

This is a port only, not a rewrite. Some things aren't ported as they rely on classes not in netstandard1.6. It's done by excluding code from the .NET full codebase, so code is shared, and by using some polyfills to fill in the gaps of features we do need now but aren't in netstandard1.6 (but are coming in netstandard20)

Things which are cut (incomplete list)
- fast/binary/xml serialization, so any constructor, method, property, class, interface related to that
- typedlist/views generated as datatable, as datatable isn't supported. generate as poco to linq/queryspec
- any databinding related code/interfaces like ITypedList implementations.
- other datatable/dataset related code, so calling a retrieval procedure which fetches a dataset/table isn't supported, nor projecting to datatable/set.
- Dependency Injection is likely kept, but it's unclear whether this is doable due to the lack of an appdomain, so discovery might be limited.

Of course when netstandard20 arrives, we'll enable more code.

As for databases, sql server, firebird, postgresql and mysql have .net core providers. OleDB won't be ported by MS so ms access is out of the question. DB2 and Oracle are slow with porting their stuff so I don't expect them to release a .net core provider soon.

I expect it will take at least a month or so before we have compiling runtime code that contains the feature set, so don't expect a binary soon. Regular Smiley


WayneBrantley (User)   Posted on: 10-Nov-2016 18:22:20.
Great to hear.

One comment around Dependency Injection.

If possible, don't roll your own - instead leverage the .NET Core DI framework (reference Microsoft.Extnesions.DependencyInjection.Abstractions).

Using this we can plug in our own implementation (autofac or whatever)

Where can I download the binary?

JK. Laugh
cerberis (User)   Posted on: 10-Nov-2016 19:01:18.
Good stuff Regular Smiley
Keen to see result.

And I agree with WayneBrantley.. do not roll your DI if possible Regular Smiley


Otis (LLBLGen Pro Team)   Posted on: 11-Nov-2016 08:16:30.
WayneBrantley wrote:
Great to hear.

One comment around Dependency Injection.

If possible, don't roll your own - instead leverage the .NET Core DI framework (reference Microsoft.Extnesions.DependencyInjection.Abstractions).

Using this we can plug in our own implementation (autofac or whatever)

Where can I download the binary?

JK. Laugh

Regular Smiley

Isn't MS' DI only available in asp.net core apps? But I haven't read much about their DI stuff yet other than that some people don't like it much for whatever reason.
I think we need to use theirs regardless as it's the only way to get the DbProviderFactory injected, as it's not defined in any config file.
WayneBrantley (User)   Posted on: 14-Nov-2016 15:52:07.
Quote:
Isn't MS' DI only available in asp.net core apps? But I haven't read much about their DI stuff yet other than that some people don't like it much for whatever reason.
I think we need to use theirs regardless as it's the only way to get the DbProviderFactory injected, as it's not defined in any config file.


Asp.net core does include actual dependency injection framework (Microsoft.Extensions.DependencyInjection) or you can plug your own....

However, asp.net core uses DI abstractions from Microsoft.Extnesions.DependencyInjection.Abstractions and then you can use their DI framework or whatever you want as your actual implementation. As an example, I believe Entity framework core also uses these abstractions.

So, you could/should use these abstractions (and can by default use Microsofts Microsoft.Extensions.DependencyInjection framework) and we can plug our own in.



Otis (LLBLGen Pro Team)   Posted on: 14-Nov-2016 17:27:59.
Thanks, good info Regular Smiley Will look into using that instead. We'll lose things like DependencyInjectionScope, but I don't think it's used much. We can always add our own DI based on theirs with our own discovery later. The main issue at the moment is the lack of appdomain which is coming back in the future, but currently isn't there.
WayneBrantley (User)   Posted on: 23-Dec-2016 16:54:32.
I have on my desk a mug. It says:

Quote:
I'd get it done MUCH QUICKER if people would stop asking me....

(Image attached)


Despite having that mug staring at me...how is the core work going? Laugh


Otis (LLBLGen Pro Team)   Posted on: 23-Dec-2016 20:35:47.
Heh Regular Smiley

Runtime all ported, templates left. Will be january 2017 I guess, as I also have to port 3500 tests or so, which hopefully will be a bit easy now nunit runs on .net core as well.

I expect the templates not to be a lot of work. What will be a bit of a pain is the project.json stuff, as microsoft has created a complete clusterfuck with their project system mess at the moment: for vs 2015, one has to keep using the preview2 tooling (with project.json, which is outdated) and for vs 2017 rc you have to use the new stuff, which is still subject to change, and which uses csproj and which won't be backported to 2015... I'll first go for project json and will adjust it later on.
twaindev (User)   Posted on: 28-Dec-2016 22:32:43.
This is great! Let me know if you need a beta tester.

Luca75 (User)   Posted on: 29-Dec-2016 09:54:36.
Good newsCool
Otis (LLBLGen Pro Team)   Posted on: 09-Jan-2017 12:01:05.
We've decided to postpone .NET core support to the date when .NET standard 2.0 is shipped and will support netstandard2.0 instead. This is likely somewhere in May 2017. It's not an easy decision, but in this case there's no real 'right' decision, as there are too many things in flight at MS and broken things at their side.

This means we won't support .NET standard 1.6, but will support netstandard2.0. The main reasons are below.

* supporting .netstandard 1.6 would require a different 'target framework' if we would want to validate the model against the limitations in .netstandard1.6: it doesn't contain datatable for instance. This is a problem as netstandard2.0 will support datatable so creating this framework would be a dead end within a few months. We could get away with a stop-gap solution where the generated code would lack elements in the model and refer to documentation, but it's not ideal. And as netstandard20 is arriving within a few months it's silly to go through this trouble when most people will never use netstandard1.6.
* when .netstandard2.0 is released, the runtime has to be ported again, this time it can be brought over almost without changes. We would then have 2 versions, where one is obsolete before its life even began: who would use the .netstandard1.6 version, when a netstandard2.0 version is available? No-one, except people perhaps on existing projects, but that's a handful and they already don't use our runtime. New projects likely will use netstandard2.0 as the # of APIs and features is much bigger.
* even though we would manage to create a netstandard1.6 version at the end of January (we already ported the runtime) of our framework, it wouldn't be released as v5.2 then, but sometime later, e.g. in March. As netstandard2.0 comes out a month or 2 later, it's silly to do work on a limited framework now which will be obsolete within a few months.

So we decided to release a .NET core 2.0 version of our framework when .netstandard20 arrives. This isn't far away and a few months doesn't matter in this case.


Luca75 (User)   Posted on: 09-Jan-2017 15:30:26.
I think it the wisest choice!Confused
twaindev (User)   Posted on: 09-Jan-2017 15:32:31.
Wise decision. Thanks for the update.

kamiwa (User)   Posted on: 12-Jan-2017 23:50:35.
FULL ACK!
WayneBrantley (User)   Posted on: 04-Feb-2017 20:27:39.
Understandable. Now that you have done a bunch of work porting you should be able to produce a 2.0 port easier. I agree that 2.0 will likely come at the May event, I am hopeful that is the FINAL release and there are betas and such way before that so that you can be ready when they are ready.

The latest RC3 of Visual Studio gets the final, final version of the new project format. It is actually pretty nice. I also understand that the 2.0 code is complete internally (code complete, not really ready) so hoping they can make May at last.


Not debating your decision, I think it is a good one...but on a separate note, really wondering about datatable. Do people still use that? I can say we have not used it in any project it many, many years. Perhaps it should be 'optional' anyway as that a bunch to support. Who knows, maybe everyone but me uses it...?


Otis (LLBLGen Pro Team)   Posted on: 05-Feb-2017 12:37:52.
WayneBrantley wrote:
Understandable. Now that you have done a bunch of work porting you should be able to produce a 2.0 port easier. I agree that 2.0 will likely come at the May event, I am hopeful that is the FINAL release and there are betas and such way before that so that you can be ready when they are ready.

The latest RC3 of Visual Studio gets the final, final version of the new project format. It is actually pretty nice. I also understand that the 2.0 code is complete internally (code complete, not really ready) so hoping they can make May at last.

It's really messier than that. 2017 RTM will have their new project system for .NET standard but .net standard2.0 will be released sometime after that. What's publicly available on github suggests they're close but at the same time it feels they're in crunch mode for months now, not a good sign for quality. But we'll see. Porting to netstandard2.0 should be straightforward (as in: almost all code compiles out of the box, except the dependency injection part)

Quote:

Not debating your decision, I think it is a good one...but on a separate note, really wondering about datatable. Do people still use that? I can say we have not used it in any project it many, many years. Perhaps it should be 'optional' anyway as that a bunch to support. Who knows, maybe everyone but me uses it...?

Some people still use it, but it's not really sufficient anymore, agreed. Benchmarks with a typed view based on a datatable and a poco show that the poco is much faster. In v5.2 we're switching the default for typedviews/lists to poco b/c of that. (for new projects).

Datatable is actually useful for untyped sets, which are e.g. used for metadata retrieval on a datareader Regular Smiley Removing them from .net therefore gives a problem which they failed to address in over a year (sloppy proposals aside, it really was a disaster). They've now ported it back to netstandard2.0 so that's OK now.
Otis (LLBLGen Pro Team)   Posted on: 16-Feb-2017 11:49:09.
Microsoft delayed .net core 2.0 / .net standard 2.0 to Q3 2017 (see roadmap: https://github.com/dotnet/core/blob/master/roadmap.md). This changes things of course.

We'll re-evaluate what to do: port to 1.6 in the meantime or wait for 2.0. Neither are great choices, to be honest.


kamiwa (User)   Posted on: 16-Feb-2017 12:02:15.
Oh no!
My first reaction: I'd wait for 2.0!

On the other hand:

How likely is it, that people actually switch to .NET Core and - as there is no other alternative around - start using EF as ORM?
Not very likely that they later port their solutions to LLBLGen.

Glad, I'm not in your shoes.
mihies (User)   Posted on: 16-Feb-2017 15:18:09.
My take: hopefully we'll see a 1.6 port.
Of course, that's from my perspective.
So far I had to use Npgsql (SQL statements, ouch) and MongoDB as alternatives to llblgenpro.
I'm not that keen on EF.

And @kamiwa is correct, once you start with an ORM is unlikely to switch. Perhaps if there is really a strong motivation, but otherwise not likely.


kamiwa (User)   Posted on: 16-Feb-2017 15:30:03.
I'll definitely wait until Frans comes up with a solution.
No point in using .NET Core w/o a decent ORM framework.
mihies (User)   Posted on: 16-Feb-2017 15:39:53.
kamiwa wrote:
No point in using .NET Core w/o a decent ORM framework.

There are a lot of points for using it. Just think of dockerizing server parts. But yes, it's kinda ugly when it comes to databases right now.


kamiwa (User)   Posted on: 16-Feb-2017 15:43:16.
mihies wrote:

But yes, it's kinda ugly when it comes to databases right now.

I live in a world where code that isn't using a database doesn't exist.Regular Smiley
Especially no server code.
mihies (User)   Posted on: 16-Feb-2017 15:47:49.
kamiwa wrote:

I live in a world where code that isn't using a database doesn't exist.Regular Smiley
Especially no server code.


Hehe, indeed. But still, the pain of llblgen abstinence is at least a bit less strong when using other benefits of .net core.


Luca75 (User)   Posted on: 16-Feb-2017 19:09:33.
I believe that at this point the choice is almost mandatory. Microsoft is causing a lot of damage to all of its developers .. I am convinced that their direction is right, but if you want to cut with the past is necessary to do it rapidly and certain times, their meter they are taking too much time. For two years we do not know whether to go and stay .. At me Netcore love it! I tried EFCore and is not bad but I love LLBLGen for me is another planet!
I wanted to congratulate you for the excellent work done on Derived Models!
Since there are, I take this opportunity to ask you if I can be sure in future relase the SelfServicing model will always be supported? These days I tried the DataAdater template but I found it too expensive if you have to manage only one type of database .. SelfServicing is the best for me!
Times have changed the Netcore is no longer monolithic, developers will have to build their own toolbox and LLBLGen will have a great future! It 's time to invest, both the product and training in order to simplify the adoption of it to the largest number of developers ..
Luca
kamiwa (User)   Posted on: 16-Feb-2017 19:23:41.
.NET Core and Microsoft is causing quite a few IT companies a royal PITA.

JetBrains (best known for IntelliJ IDE and Resharper) are currently developing a cross platform IDE for .NET. named Rider.

They just had to find out, that open source is not always as open as you'd think.

The technology behind debugging .NET Core projects is MS VS and XAMARIN XS licensed only.

Read for yourself: https://blog.jetbrains.com/dotnet/2017/02/15/rider-eap-17-nuget-unit-testing-build-debugging/


Luca75 (User)   Posted on: 16-Feb-2017 20:58:40.
.. Interesting an open source framework with a legacy debuger. I hope this is a mistake. Although it would be less of a problem at the moment ..
The current problem is to have something to debug in NetCore! Confused
WayneBrantley (User)   Posted on: 16-Feb-2017 22:44:23.
Well, it is a tough call.

As discussed above, one of the pain points are 'no datatables'. For me it is a non-issue if you released a framework that did not use datatables and then later you released a 'datatable' package that added missing features others used.

I really want to move to something targeting a .net standard much quicker than Q3. For me, I see much of the community has embraced this and moved. There are still some holdouts 'waiting' for 2.0 because as discussed it makes the pain much less.

Your investment, your customers, your potential loss of new customers, your call. I will be forced to live with whatever decision you make as I will not be leaving and we love your product.



Otis (LLBLGen Pro Team)   Posted on: 17-Feb-2017 11:09:05.
Thanks for the kind words everyone Regular Smiley

They'll release a preview of v2.0 in Q2 and the RTM in Q3. Q2 is 'summer' (northern hemisphere) so just a couple of months away to see a stable API (with bugfixes give or take after that). We'll try to deliver a 2.0 port when their preview is ready, so Q2.
kamiwa (User)   Posted on: 17-Feb-2017 11:16:28.
That's what I call a solomonic decision. Regular Smiley

mihies (User)   Posted on: 18-Feb-2017 10:45:14.
Also, Q3 might be as soon as July. Just sayin.
WayneBrantley (User)   Posted on: 21-Mar-2017 02:12:19.
Have you guys tried out .net standard 2.0 builds at all yet?

http://yizhang82.me/dogfooding-netstandard-2


Otis (LLBLGen Pro Team)   Posted on: 21-Mar-2017 09:14:08.
not yet, focus is on getting 5.2 out to beta. We'll start looking into the netstandard2.0 state after that so we can have a working runtime when netstandard2.0 hits 'preview' this summer. It's of no use to be earlier than that as no-one out there will use it before MS releases at least the preview.

We expect little problems porting to netstandard2.0. Only parts where things are a little rough and need some extra work is the dependency injection part and how to get the dbproviderfactory instance to the DQEs, but both have solutions, so not really big problems.
mihies (User)   Posted on: 30-Mar-2017 08:32:11.
Looks like they are targeting 10.5. for 0 bugs.

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


Otis (LLBLGen Pro Team)   Posted on: 30-Mar-2017 09:15:24.
sounds good Regular Smiley
kamiwa (User)   Posted on: 30-Mar-2017 09:18:05.
A piece of software with zero bugs?
In which parallel universe does this exist? Regular Smiley


WayneBrantley (User)   Posted on: 22-May-2017 14:12:36.
Just curious if you have looked at / started trying to convert using the new 2.0 preview and if so how it looks?
Otis (LLBLGen Pro Team)   Posted on: 22-May-2017 19:17:07.
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 Regular Smiley) 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.


mihies (User)   Posted on: 22-May-2017 19:44:09.
Perhaps devart might help with Oracle drivers? Not that I care Regular Smiley
kamiwa (User)   Posted on: 27-Jun-2017 23:14:21.
Don't want to appear as being impatient, but: Any news on the topic?

Otis (LLBLGen Pro Team)   Posted on: 27-Jun-2017 23:18:06.
kamiwa wrote:
Don't want to appear as being impatient, but: Any news on the topic?

No.

Regular Smiley 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.
kamiwa (User)   Posted on: 28-Jun-2017 01:30:36.
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.

WayneBrantley (User)   Posted on: 28-Jun-2017 22:00:32.
Preview 2 announced!

https://github.com/dotnet/announcements/issues/17
FrankMonroe (User)   Posted on: 29-Jun-2017 06:11:16.
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. Laugh

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 ! Cool Is this a preference/settings in the app?


Otis (LLBLGen Pro Team)   Posted on: 29-Jun-2017 09:39:51.
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. Laugh

Thanks! Laugh

Quote:

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

Quote:
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 ! Cool Is this a preference/settings in the app?

Nope, sorry, tabs all the way Cool 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 Wink
FrankMonroe (User)   Posted on: 30-Jun-2017 22:44:02.

Quote:
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).


WayneBrantley (User)   Posted on: 30-Jun-2017 23:10:23.
In startup.cs, in ConfigureServices:

Code:
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.
WayneBrantley (User)   Posted on: 09-Aug-2017 19:35:09.
I hope your work on .net core 2 preview went well...

Because.....it is FINAL NOW!

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


Otis (LLBLGen Pro Team)   Posted on: 10-Aug-2017 10:08:50.
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 Wink

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 Regular Smiley

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.
mihies (User)   Posted on: 10-Aug-2017 12:30:14.
^ Like

Otis (LLBLGen Pro Team)   Posted on: 14-Aug-2017 13:33:41.
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 Dissapointed... )
mihies (User)   Posted on: 14-Aug-2017 13:41:20.
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.


Otis (LLBLGen Pro Team)   Posted on: 14-Aug-2017 14:04:54.
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.
WayneBrantley (User)   Posted on: 14-Aug-2017 14:13:16.
Can confirm. Won't miss it at all.
Do people actually serialize the entities these days?


Otis (LLBLGen Pro Team)   Posted on: 14-Aug-2017 14:21:52.
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. Cool
s_tristan (User)   Posted on: 17-Aug-2017 12:50:41.
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

Otis (LLBLGen Pro Team)   Posted on: 17-Aug-2017 15:13:21.
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.
s_tristan (User)   Posted on: 17-Aug-2017 15:25:11.
Thanks for sharing plans, Frans!

yowl (User)   Posted on: 17-Aug-2017 23:00:10.
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?
Otis (LLBLGen Pro Team)   Posted on: 18-Aug-2017 09:20:18.
yes.

yowl (User)   Posted on: 18-Aug-2017 16:07:52.
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.
Otis (LLBLGen Pro Team)   Posted on: 18-Aug-2017 21:38:58.
Regular Smiley

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


Otis (LLBLGen Pro Team)   Posted on: 22-Aug-2017 16:00:04.
All tests pass, runtime/templates now run for 100% on netstandard2.0 / .net core 2.0. Regular Smiley We'll release an EAP soon (next week I hope).
kamiwa (User)   Posted on: 22-Aug-2017 16:03:20.
YEAH!
Finally new toys and new adventures! Laugh


s_tristan (User)   Posted on: 22-Aug-2017 16:25:30.
Excellent news! Waiting for EAP.
twaindev (User)   Posted on: 22-Aug-2017 16:28:50.
This is indeed great news! Thanks!

Luca75 (User)   Posted on: 22-Aug-2017 16:31:50.
Great News!Thanks
Otis (LLBLGen Pro Team)   Posted on: 22-Aug-2017 17:08:01.
Laugh

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 Regular Smiley

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)
Code:

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


Luca75 (User)   Posted on: 01-Sep-2017 03:25:08.
Hi Frans, how are the work going on? What are you doing beautiful inside the box?
Cool
kamiwa (User)   Posted on: 01-Sep-2017 08:33:17.
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)

Otis (LLBLGen Pro Team)   Posted on: 01-Sep-2017 09:35:21.
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. Laugh

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 Regular Smiley
kamiwa (User)   Posted on: 01-Sep-2017 09:46:14.
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. Laugh

Luca75 (User)   Posted on: 01-Sep-2017 09:59:41.
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 ...
Luca75 (User)   Posted on: 01-Sep-2017 10:01:49.
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. Laugh

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


kamiwa (User)   Posted on: 01-Sep-2017 10:15:54.
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. Laugh

..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.
Otis (LLBLGen Pro Team)   Posted on: 01-Sep-2017 13:04:21.
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... Dissapointed ) 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 Wink.

Oh and it has docs Wink


Luca75 (User)   Posted on: 01-Sep-2017 15:08:19.
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 Wink.

Oh and it has docs Wink

Thanks
kamiwa (User)   Posted on: 05-Sep-2017 14:04:02.
Any news abut the EAP?

Otis (LLBLGen Pro Team)   Posted on: 06-Sep-2017 09:38:54.
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.
kamiwa (User)   Posted on: 06-Sep-2017 09:46:05.
Cool!

Luca75 (User)   Posted on: 06-Sep-2017 10:47:28.
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!
Otis (LLBLGen Pro Team)   Posted on: 06-Sep-2017 16:59:13.
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