Devart Forums

I'm trying to use LLBLGenPro ORM tool version 2.0.0.0 with the current version of MySQLDirect .Net version 4.00 Trial version.

LLBLGenPro was looking for version 3.0.* of the CoreLab.MySql, but I used assembly redirection to redirect to the 4.0.9.0 version that I have.

Now LLBLGenPro is trying to use the CoreLab.MySql dll's to access a MySQL database, but failing on a "License not found" exception.

I have read the License topic in the help, but it doesn't seem to apply to this case because I'm not compiling LLBLGenPro.exe. In any case I put a licenses.licx and licenses.config file next to the LLBLGenPro.exe file, which didn't help.

How can I get LLBLGenPro to be able to use CoreLab.MySql?

Thanks,
Ryan

LLBLGenPro should be rebuilt with MySQLDirect .NET 4.0.
Please contact Solutions Design.

Can I get a trial of the previous version (3.0)?

Unfortunately, no. We have moved all our works to 4.0.

Alexey wrote:LLBLGenPro should be rebuilt with MySQLDirect .NET 4.0.
Please contact Solutions Design.

We of course won't do that now, as we have customers using mysqldirect 3.x and that would then mean we have to build TWO versions.

Why is it our problem that YOU changed license schemes? The user of our product installs a provider from YOU. Our code simply loads the driver and uses it to connect to mysql. The provider then shouldn't check our .exe, it should check the system it's running on. The .exe is using a driver dll which is legitimately build against 3.x.

We had the same misery last year, with v3.x where we had our driver compiled against 2.x because customers were still using that.

I have to say: it's been enough. We have a legitimate license for v3.x, we build our code with 3.x and if a user uses v4.x, that's great but it simply should work FUNCTIONALITY wise. If it fails because v4's API has changed and you can't redirect the assembly reference to v4's dll, fine, I'll release a v4.0 build. But if it solely crashes because v4 can't find a license in OUR code (which is beyond me why it should find it THERE, as the USER installs v4, so the USER's system should contain the license info for v4, not our work), why do we then suddenly have to upgrade to v4, and force everyone out there who uses our work and mysql to upgrade to v4 as well? That's silly.

If this can't be solved by you, we have to drop Core Lab's provider and will release our driver/dynamic query engine in sourcecode so people have to build it first to use mysql with v4 of your provider IF they want it to, we won't distribute it anymore then. Last year's licensing problems aren't forgotten here, I don't want to go through that again.

Frans Bouma
Lead developer LLBLGen Pro.

Why is it our problem that YOU changed license schemes?

We have not changed the scheme, but we have changed the license. Users with the license for 3.0 shouldn't be using MySQLDirect .NET 4.0 assemblies. That's why this problem occurs.

Alexey wrote:

Why is it our problem that YOU changed license schemes?

We have not changed the scheme, but we have changed the license. Users with the license for 3.0 shouldn't be using MySQLDirect .NET 4.0 assemblies. That's why this problem occurs.

That's not what this is all about. We have a v3 license, we compile our code against v3. The USER has v4 and as we just execute some queries and nothing else, is v4 structural different that we have to rewrite our code to make it work against 4? If so that would mean migration issues for all your customers who use 3 and want to use 4 as well...

So what WE use to compile our code with is not the issue of the user, the user has 4, and therefore there's no license problem: the USER has the license, so the license check should succeed.

(edit). The thing is: our work works fine with v3 of your provider. However, people can't purchase v3 anymore, they can only purchase v4. Because of this, WE suddenly have to update our work because of this.

Yes, version 4 is structural different. In my letter to you I mentioned CoreLab.Data.dll which is added to our project.

Alexey wrote:Yes, version 4 is structural different. In my letter to you I mentioned CoreLab.Data.dll which is added to our project.

So we have to rewrite parts of our driver to meet the new structure?

Nevertheless, supporting both isn't going to work. We have a single .exe (our designer) which loads the driver at request (depending on which driver is selected by the user). The DRIVER is build against the provider used.

HOWEVER, the mysqldirect provider will check in our EXE (the designer) for the v4.0 license. Though we have added the v3 license data (as you provided to us in may last year because it gave problems with the dll reference which didn't add the license data) to the .EXE, not the v4 data.

Does this mean we have to replace that with v4 data (so v3 licensees won't be able to use our designer + mysql with v3) or can both be added (IF we proceed with this, which isn't certain at this point) ?

You have to understand that last year we also lost several days looking for answers why this didn't work and I simply refuse to spend a lot of time on it again.

Again, I fail to see why it's of any relevance to the USER which license WE have used to build the code (license checking related)

To illustrate the weirdness of the licensing scheme you're using, the following example.

A given person buys a license for our O/R mapper system and a v4 license of your mysqlconnect provider.

Our designer works as follows: user creates new project, user selects db type, THEN a driver assembly is loaded (our code) which uses a provider (in this case mysqlconnect for mysql). The designer communicates with the driver, the driver uses the provider assembly. A standard 'plugin/provider' model.

The customer has the sourcecode for the mysql driver (our code) which uses the mysqlconnect provider. The custsomer compiles that code against v4 of your provider and tries to use that compiled assembly with our designer.

This goes wrong when the driver is trying to connect to the db, because the provider used by the driver (which is your provider) checks the _EXE_ for the license. However, the customer doesn't have access to the sourcecode of the .exe as that's OUR designer.

The provider should check the driver assembly for a license, not the .exe or other places for a license but not the .exe, as that's not where the provider assembly is referenced (the .exe doesn't have any reference to any ado.net provider at all).

Now you state that we should compile our .exe with a license hint to v4. Though when one of our customers who has v3 installed tries to use the .exe, it then fails because there's no v3 license present in the .exe.

If you can make this work for the DRIVER dll, we could provide the v4 capable driver DLL to our customers. If you can't make that work for the DRIVER, if it has to be in the .exe, we have obviously a big problem and we have to stop using Core lab as we won't force our customers who have v3 of your provider to upgrade to your v4 provider for obvious reasons.

ryans, this problem is going to be solved by building a special edition of LLBLGenPro for MySQLDirect .NET 4.0.

Alexey wrote:ryans, this problem is going to be solved by building a special edition of LLBLGenPro for MySQLDirect .NET 4.0.

_driver_ .

We'll resolve this shortly, as soon as Core Lab sents us the license so we can build our driver against v4.

By the way, Frans, it is possible that we have already sent you upgrade information. Make sure it was not blocked by your anti-spam filter or so.

Alexey wrote:By the way, Frans, it is possible that we have already sent you upgrade information. Make sure it was not blocked by your anti-spam filter or so.

I checked, but no email yet.

Don't you use an automated system?

FransBouma wrote:I checked, but no email yet.
Don't you use an automated system?

We have already sent you upgrade information. Please check and confirm receiving.