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!

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

If it helps.. why not Its not much.. we just xproj projects so that later we should be able easier to migrate to proper .netcore lib.

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?

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.

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.

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

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)

... or running on Linux/mono if you want to. It runs it is just mono isn't that asp.net oriented (AFAIK).

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

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

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:

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

and did this

    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

private static readonly DbProviderFactoryInfo _dbProviderFactoryInfo = new DbProviderFactoryInfo();

And DbProviderFactoryInfo has this:

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

And this...

        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

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

regards Mantas

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.

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.

        // 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?

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

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?

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.

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.

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.

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

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

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?

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.

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

Anyway, thanks for help.

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

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

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.

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.

Good stuff Keen to see result.

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

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.

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.

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.

Thanks, good info 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.

I have on my desk a mug. It says:

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?

Heh

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.

This is great! Let me know if you need a beta tester.