LLBLGenPro v2.0.0.0 License not found

Discussion of open issues, suggestions and bugs regarding ADO.NET provider for MySQL
ryans
Posts: 2
Joined: Thu 19 Apr 2007 00:53
Location: Seattle, WA, USA

LLBLGenPro v2.0.0.0 License not found

Post by ryans » Thu 19 Apr 2007 01:01

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

Alexey
Posts: 2756
Joined: Mon 13 Mar 2006 07:43

Post by Alexey » Thu 19 Apr 2007 07:15

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

ryans
Posts: 2
Joined: Thu 19 Apr 2007 00:53
Location: Seattle, WA, USA

previous version?

Post by ryans » Thu 19 Apr 2007 16:38

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

Alexey
Posts: 2756
Joined: Mon 13 Mar 2006 07:43

Post by Alexey » Fri 20 Apr 2007 08:01

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

FransBouma
Posts: 29
Joined: Fri 25 Nov 2005 10:43

Post by FransBouma » Fri 20 Apr 2007 08:40

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.

Alexey
Posts: 2756
Joined: Mon 13 Mar 2006 07:43

Post by Alexey » Fri 20 Apr 2007 11:23

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.

FransBouma
Posts: 29
Joined: Fri 25 Nov 2005 10:43

Post by FransBouma » Fri 20 Apr 2007 11:28

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.

Alexey
Posts: 2756
Joined: Mon 13 Mar 2006 07:43

Post by Alexey » Fri 20 Apr 2007 11:55

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

FransBouma
Posts: 29
Joined: Fri 25 Nov 2005 10:43

Post by FransBouma » Fri 20 Apr 2007 12:20

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)

FransBouma
Posts: 29
Joined: Fri 25 Nov 2005 10:43

Post by FransBouma » Sat 21 Apr 2007 19:25

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.

Alexey
Posts: 2756
Joined: Mon 13 Mar 2006 07:43

Post by Alexey » Tue 24 Apr 2007 08:36

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

FransBouma
Posts: 29
Joined: Fri 25 Nov 2005 10:43

Post by FransBouma » Tue 24 Apr 2007 08:40

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.

Alexey
Posts: 2756
Joined: Mon 13 Mar 2006 07:43

Post by Alexey » Tue 24 Apr 2007 08:54

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.

FransBouma
Posts: 29
Joined: Fri 25 Nov 2005 10:43

Post by FransBouma » Tue 24 Apr 2007 09:10

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?

Devart
Site Admin
Posts: 3974
Joined: Tue 26 Oct 2004 13:51

Post by Devart » Tue 24 Apr 2007 12:09

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.

Post Reply