Yesterday, CoreLab has released v3.2 of their .NET provider for MySql. v3.2 comes with .NET 2.0 final support. LLBLGen Pro's mysql driver and DQE are compiled against v2.80.7 of the CoreLab mysql provider.

During the beta period of vs.net 2005, the MySql corelab provider v2.80 was also released in beta form for .NET 2.0. However, this provider didn't work with .NET 2.0 final.

We tried to contact Corelab with the question if v2.80.x is upgraded to be able to work on .NET 2.0 but they said it wouldn't, and that we had to upgrade to v3.2 as .NET 2.0 support was 'a new feature'. We tried to express our problems with upgrading to 3.2, because if we upgrade to v3.2, all our customers have to do that too. Up till today we still haven't received an answer. I've contacted Corelab again, let's see how that pans out.

The core issue I already briefly mentioned the problem in the previous paragraph, but here's it in detail: to be able to let the MySql DQE work on .NET 2.0 final, we have to compile against v3.2 This version comes with a different licensing scheme: component licensing. Also, it might be code-incompatible with v2.8.

If we upgrade to v3.2, all our customers who currently use 2.8 have to upgrade as well, as their code will stop working once they use the new DQE or use llblgen pro and try to create a new project/refresh a catalog. Upgrading to v3.2 isn't free however: Corelab decided that licensees of 2.8 have to pay for a new license for v3.2. So if we upgrade, every LLBLGen pro user who uses MySql as well, has to shell out money for v3.2 as well.

We decided that's not the decision we should make nor want to make for you, it should be your decision if you want to upgrade to a higher version and pay money for that, not us.

Obviously we're in a Catch-22 at the moment: if we don't upgrade, .NET 2.0 support for MySql is not working, if we do upgrade, our customers have to upgrade and pay money to corelab.

We could compile the DQE for .NET 2.0 against v3.2 and the DQE for .NET1.x against 2.8. (if they let you keep the 2.8, which isn't the case as well). However we have a single MySql driver, not two. Shipping 2 driver versions, compiled against each version is a pain to say the least (we already know that from the Oracle/ODP.NET situation) and it's also not ideal for our customers, because existing projects will break and other misery.

The options we're considering We've thought of a couple of options. None of them are ideal. a) We drop MySql support entirely and keep the DQE / Driver as sourcecode on the website for the people who want to use it. b) We switch to MySql S.A.'s GPL-ed provider, we pay for a license, and can then distribute the compiled version. Our customers however have to switch provider then as well, and if they don't want to use a GPL-ed provider, (which is a problem on its own) they have to pay MySql, which is a higher fee than to Corelab c) We move to v3.2 and keep the sourcecode around for v2.8 so customers can use the code to compile against 2.8 and keep on working on 2.8. This code is already available to you, via the SDK and the runtime library sourcecode. d) We stick with 2.8 and people who migrate to 3.2 have to use a policy file or other config voodoo to work with the code but this doesn't work on .NET 2.0

None of them are great options. We're still undecided what to do about this so if you have anything to say about this, please step forward and post below your comments.

One other thing is problematic at the moment: the v3.2 is released with component licensing, which means our code has to be compiled with a licenses.licx file which contains corelab references to make it work. This isn't the case at the moment and this can be a problem, because the 2.8 version doesn't have component licensing, so it might be that if we add this, it might not work for 2.8, we haven't tested this yet.

Conclusion All in all, we're very unhappy with the situation. Corelab's support has been miserable in the past and people who have had to contact them for support know what I'm talking about, so if possible we'd like to cut out the dependency on Corelab, however the alternatives aren't that great. The sad thing is that whatever decision we take, some customers of ours will be unhappy with that decision.

Thanks for your time, and I hope as much MySql users chime in with their thoughts. I'm looking forward to your opinions about this.

I appreciate your concern for your users. It's clear that this problem is solely the fault of CoreLab, and that you've made every effort to make this as best a situation as is possible.

I have production websites with MySQL/LLBLGen/Corelab. My committment to LLBLGen is strong, but I cannot change the database regardless of the cost, in either hours or dollars.

I'm lucky in that I bought the CoreLab 2.x product so late that I got 3.x for free, so the cost of the CoreLab product is not an issue. My plan is clear: upgrade, re-build, and go forward.

Your options A or D above involve a strategy that is inconsistent with your customers ability to take advantage of the great progress being made with the LLBLGen product. It would cut customers off from what is clearly a growing product. This would be a shame, and would eventually erode their confidence in the product by degrading it's usefullness over time.

Your option B is certainly viable, and while I dislike paying annual fees (if I'm reading the MySQL page correctly), I understand that I pay money to make money. If it costs me hours and money, I will convert, because it still saves me money in the long run. However, it is not my preferred option.

My preference is for option C above. I believe it strkes the right balance between forward thinking and support for existing users who haven't yet monetized their products to the point of being able to undergo the burden of the cost of upgrading.

I'm no fan of CoreLab, believe me. I don't wish to give them any more money that is absolutely necessary.

But, my committment to my own users says that I have to continue to operate without disruption, and grow into the future, and today that means CoreLab is in the mix.

Nobody blames LLBLGen, or you personally, for the CoreLab madness, and I appreciate your listening carefully to your customers' concerns.

Scott Wallace www.developerfood.com www.nearbinder.com and soon to be www.adgrace.com

I agree with swallace. Option C is my preference - I think we have to just pay the toll and move on.

My preference is for option C above. I believe it strkes the right balance between forward thinking and support for existing users who haven't yet monetized their products to the point of being able to undergo the burden of the cost of upgrading.

Here also:

Nobody blames LLBLGen, or you personally, for the CoreLab madness, and I appreciate your listening carefully to your customers' concerns.

While i dont use MySql for various reasons, my opinion may be a bit biased, but personally i would go for option A. I say drop ONLY cuase i would prefer you spending time on supporting PostgreSql which now has a nice windows port rather then MySql and its stupid licensing scheme.

Thanks all. Keep them coming. Corelab responded and we're working on a solution. I think it will be option C (sorry Answer ) though when that happens is not yet decided, as Corelab currently has a lot of probs with the component license as it seems, and I can't get the runtime lib compiled on the command line with the license.licx file

We've solved the issue. Here's the news snippet:

We reported a couple of days ago that there were some issues with the CoreLab MySqlDirect.NET provider, its new version and how LLBLGen Pro would use that provider in the (near) future.

Together with CoreLab we've solved this issue and the results are below.

• If you're using .NET 1.x, nothing changes, you can keep on using 2.80.x.
• If you're using .NET 2.0, you have to upgrade to CoreLab MySqlDirect.NET v3.20.x or higher.

If you're using .NET 1.x and you have MySqlDirect.NET v3.20 installed for .NET 1.x, you should be fine, as that setup also is supported.

To be able to use v3.20.x with LLBLGen Pro's designer, you have to download the latest designer from the Full version section at the left: version December 20th or later. This build has a reference to the CoreLab MySqlConnection so the component licensing will work.

This thus does require an update of the provider, if you're using .NET 2.0, but c'est la vie. It's the most productive solution that was possible for all parties.

Sounds good. I'll give it a try this evening and let you know if it works.

Thank you Otis. I appreciate your ongoing effort to keep MySQL support for your great product

StuartLeitch wrote:

Thank you Otis. I appreciate your ongoing effort to keep MySQL support for your great product

Well, MySql will personally never be my choice for a database, but it's of course very rude to simply cut off support for a given database without offering an alternative for that same database. I'm also very happy with the end result, as it's not a high impact situation now.

Has any of you got it to work? I got reports it still doesn't work, and when I set it up here on .NET 2.0 indeed I can't create a project but that's because of a new error: Could not load type 'CoreLab.Common.DbConnection' from assembly 'CoreLab.MySql, Version=3.20.6.0, Culture=neutral, PublicKeyToken=09af7300eec23701'.

I can't get rid of that error, very weird. This becomes a true nightmare and I'm now very close to kick it out of llblgen pro because it eats too much time and is too frustrating.

Otis wrote:

I can't get rid of that error, very weird. This becomes a true nightmare and I'm now very close to kick it out of llblgen pro because it eats too much time and is too frustrating.

Do it, but first include support for the Original MySql Connector/Net

This works fine for me on .net and mono, windows and linux.

i have recompiled the the LLBLGen CoreLab driver with MySql Connector and it works in the llblgen designer.

The only problem is that im not able to get the Templates working with my driver because they use an enun CoreLab.MySql.MySqlType with have other values than the one in the MySql Connector Driver.

This time i Change the generated Templates by hand to work with mysql driver, but that's annoying.

by the way:

December 20th dont works for me. i always got "license expired" for CoreLab driver in the designer

The problem with the mysql provider is that it's GPL-ed, and I won't go into that quackmire. (plus the mysql provider is expensive if you want to have the non-gpl-ed version). I'm sure there's a solution for this, as it's caused by something. Finding the cause for this however, is a bit of a problem.

I've mailed corelab, see what they have to say about this...

Question: if you add a licenses.licx file to the mysql driver sourcecode, add that line from the licensing page in the corelab docs, does it then work for you?

i will test

cjendro wrote:

i will test

Thanks. I can mail you a version which is build against 2.80.7 and has the licenses.licx file inside, which doesn't work here, (weird error see above). perhaps I've to build it against 3.20.6 directly for .net 2.0, not sure.

Otis wrote:

cjendro wrote:

i will test

Thanks. I can mail you a version which is build against 2.80.7 and has the licenses.licx file inside, which doesn't work here, (weird error see above). perhaps I've to build it against 3.20.6 directly for .net 2.0, not sure.

i use "3.20.7"

i dont have an other (older) version, because i bought it 2 days ago :-)

cjendro wrote:

Otis wrote:

cjendro wrote:

i will test

Thanks. I can mail you a version which is build against 2.80.7 and has the licenses.licx file inside, which doesn't work here, (weird error see above). perhaps I've to build it against 3.20.6 directly for .net 2.0, not sure.

i use "3.20.7"

Hmm, perhaps that version fixes the problem I had I use 3.20.6

rebuild driver against 3.20.7 no effect, still exception in llblgen designer "license expired or not valid..."

where must the license.licx file be

in the exe or in the dll?

i have tested with a small test programm, license.licx must be in the executable, not in the driver dll

cjendro wrote:

i have tested with a small test programm, license.licx must be in the executable, not in the driver dll

I have it in the exe, I have it in the application core AND in the driver, I still get the license error (if I build the driver against .NET 2.0 and 3.20.7). If I use 2.80.7 on .NET 2.0 (so redirect takes place), I get the other error and nothing works at all.

The problem is that the driver assembly is dynamically loaded. I'll now post to their forums that they have to fix this pronto.

Otis wrote:

cjendro wrote:

i have tested with a small test programm, license.licx must be in the executable, not in the driver dll

I have it in the exe, I have it in the application core AND in the driver, I still get the license error (if I build the driver against .NET 2.0 and 3.20.7). If I use 2.80.7 on .NET 2.0 (so redirect takes place), I get the other error and nothing works at all.

The problem is that the driver assembly is dynamically loaded. I'll now post to their forums that they have to fix this pronto.

i have downloaded the december 20. version, there is no embedded resource in llblgenpro.exe

you can also contact me via icq 1603858 or msn messanger carsten.jendro AT gmx.net

cjendro wrote:

Otis wrote:

cjendro wrote:

i have tested with a small test programm, license.licx must be in the executable, not in the driver dll

I have it in the exe, I have it in the application core AND in the driver, I still get the license error (if I build the driver against .NET 2.0 and 3.20.7). If I use 2.80.7 on .NET 2.0 (so redirect takes place), I get the other error and nothing works at all.

The problem is that the driver assembly is dynamically loaded. I'll now post to their forums that they have to fix this pronto.

i have downloaded the december 20. version, there is no embedded resource in llblgenpro.exe

You've to check Resources -> llblgenpro.exe.licenses The exe references a lot of licensed components (janus, infragistics).

I think it's the dynamic loading of the assembly. If you create an assembly which creates a connection, and load that assembly dynamically with assembly.loadlibrary, and create an instance of the type which creates teh connection there, and call the method which creates the connection it fails.

So I'm currently stuck. I've posted to their forums, and also mailed Dmitry, the chief there, so it's now wait and see.

As it's christmas now and my wife cooked a lovely dinner, I'm going to spend some time on that instead. THanks for the icq number, much appreciated And thanks for the help on a christmas day . Let's all hope this MySqHell is soon becoming MySqL again

Otis wrote:

You've to check Resources -> llblgenpro.exe.licenses The exe references a lot of licensed components (janus, infragistics).

I think it's the dynamic loading of the assembly. If you create an assembly which creates a connection, and load that assembly dynamically with assembly.loadlibrary, and create an instance of the type which creates teh connection there, and call the method which creates the connection it fails.

So I'm currently stuck. I've posted to their forums, and also mailed Dmitry, the chief there, so it's now wait and see.

As it's christmas now and my wife cooked a lovely dinner, I'm going to spend some time on that instead. THanks for the icq number, much appreciated And thanks for the help on a christmas day . Let's all hope this MySqHell is soon becoming MySqL again

i have checked llblgenpro.exe.licenses, there are a lot of lichenses for Infragistics.Win.UltraWinGrid.UltraGrid and so on, but nothing about CoreLab in my version of llblgenpro.exe

i will do a test with dynamic loading now