cjendro wrote:

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

True, no matter what I do, it doesn't end up there indeed... Perhaps that's the cause, I've no idea.

Ok, more info: - the .licenses file apparently is incrementally build. If I remove the file, (or the obj folder in general) and then recompile I get the reference to the assembly, that is, IF I have 3.20.7 for .NET 1.1 installed. If I have 2.80.x installed for .NET 1.1, it won't work. - I added manually 3.20.7 for .NET 1.1 to the gac as well, then I got the reference in the .licenses file and in the .exe - trying to create a new project for mysql on .NET 2.0 failed: Could not load type 'CoreLab.Common.DbConnection' from assembly 'CoreLab.MySql, Version=3.20.7.0, Culture=neutral, PublicKeyToken=09af7300eec23701'.

When I uninstall 2.80.7 and install 3.20.7 trial for .NET 1.1, it works.

Conclusion The only solution is: We upgrade our code to 3.20.x and all our mysql customers have to do that too. We then offer manual downloads for 2.80.7 build driver / DQE or offer the customers to build the code manually, which can be done through the DQE sourcecode and the driver sourcecode available in the SDK (the dqe sourcecode is shipped with llblgen pro).

Not that great. The driver isn't updated that often, so it's not that big of a problem, but the DQE build for 2.80.7 is a hassle so we likely will go for the sourcecode only option.

Today is also a day off here in The Netherlands (we have 2 christmas days). I wasted 3 hours again on this issue today. These are the last 3 hours I'll ever spend on this problem. It will also be a strong guideline for the next databases we'll choose to support. Never ever will we opt for a commercial provider again, nor will we go for a database which has only GPL-ed free-providers. If postgresql doesn't have a free solid non-GPL-ed provider for .NET, it won't be supported. This whole issue frustrated me to the bone, as it's out of my hands what causes it and I cant solve it myself without causing problems for our customers.

I still can't believe why on earth MySql asks money for their non-GPL-ed .NET provider. It looks like they don't WANT you to use the db...

I know I promised in an earlier post to test this, but I've spent the long holiday getting adgrace.com out the door (nearly there!), and I halted at the 30 Nov designer to get it done. I'm glad now I waited or else I'd have been screwed.

So, if I'm reading correctly, I need to completely uninstall CoreLab 2.8, and install both the 3.2 for .NET 1.1 and .NET 2.0?

No stick with 2.8 for now. If you want to use .NET 2.0, you have to compile the DQE and driver with 3.20.x manually for now. This will soon be resolved for you, but at the moment this is the only way to get .NET 2.0 working with the current code.

Will do.

BTW, thanks for logging into adgrace.com. It's been updated since you've visited. Check it out again to see what it really is. Basically it's web ads but with people's own messages rather than commercial ads. Weird idea, but perhaps it's something. You can see examples of the ads/messages delivered on websites at my developerfood.com site, once you drill in a bit to where the ads are.

Anyway, couldn't have done it without you, and your many frustations with CoreLab.

Thanks!

strange thing with the licensing:

a)

Visual Studio sometimes can't resolve lines like

CoreLab.MySql.MySqlConnection, CoreLab.MySql

in licenses.licx, but when i use

CoreLab.MySql.MySqlConnection, CoreLab.MySql, Version=3.20.7.0, Culture=neutral, PublicKeyToken=09af7300eec23701

it wotks fine.

b) CoreLab normally only searches the entry assembly for licenses with one exception:

when Assembly.GetEntryAssembly(); returns null, all the assembly in the current appdomain will be searches for a license. the first assembly containing a license will be used to get the license. when you have multiple assemblys containing licenses, only the fist assembly that is found will be searches for a license.

you have 3 assemblys:

• LLBLGenPro.exe
• Janus.Windows.GridEX.v2.DLL
• Infragistics.Win.UltraWinToolbars.v3.1.dll

I am not sure if this is 100% correct, i only have taken a look to the obfuscated licensing code with .net reflector, but it looks very strange.

best was woluld be to recompile Corlab driver and remove the licensing mechanism :-) takes only 5 minutes ;-)

cjendro wrote:

strange thing with the licensing:

a) Visual Studio sometimes can't resolve lines like CoreLab.MySql.MySqlConnection, CoreLab.MySql

in licenses.licx, but when i use

CoreLab.MySql.MySqlConnection, CoreLab.MySql, Version=3.20.7.0, Culture=neutral, PublicKeyToken=09af7300eec23701

it wotks fine.

Yeah, noticed that too.

b) CoreLab normally only searches the entry assembly for licenses with one exception:

when Assembly.GetEntryAssembly(); returns null, all the assembly in the current appdomain will be searches for a license. the first assembly containing a license will be used to get the license. when you have multiple assemblys containing licenses, only the fist assembly that is found will be searches for a license.

you have 3 assemblys:

• LLBLGenPro.exe
• Janus.Windows.GridEX.v2.DLL
• Infragistics.Win.UltraWinToolbars.v3.1.dll

I am not sure if this is 100% correct, i only have taken a look to the obfuscated licensing code with .net reflector, but it looks very strange.

Indeed, they should check all assemblies. I think the raw problem now comes down to: if you have an assembly Foo version 1.0 which references assembly Bar version 1.0, compiled against .NET 1.1, it works fine on .NET 1.1. When you want to run it on .NET 2.0, which should be possible automatically, and you have for .NET 2.0, Bar v2.0 installed, and a policy file which redirects bar 1.0 -> bar 2.0, it will only work if all classes in Bar v2.0 have the same hierarchy.

It will fall apart if they don't. This is the case in corelab's 3.20 lib. So it's not entirely corelabs fault. It's unfortunate however. I'll see if I can recompile everything against 3.20 this week or that we start with that next week (which is then the first week of the new year so a good start for this )

best was woluld be to recompile Corlab driver and remove the licensing mechanism :-) takes only 5 minutes ;-)

Tssk... .

If they did some clever coding, they have checks build into the code which check for Public token values on the same assembly and do something rigid. In obfuscated code that's really hard to find. So those 5 minutes I don't think so.

Otis wrote:

best was woluld be to recompile Corlab driver and remove the licensing mechanism :-) takes only 5 minutes ;-)

Tssk... .

If they did some clever coding, they have checks build into the code which check for Public token values on the same assembly and do something rigid. In obfuscated code that's really hard to find. So those 5 minutes I don't think so.

my first try was to

• decompile llblgen
• unserialize llblgen.exe.licenses resource
• add license for corelab driver manually
• recompile llblgen

but this dont works, still the same license problem

second try was

• removing the license check from corelab driver and recompile it
• recompile llblgen mysql driver with changed corlab driver

works fine, and it is the only was for me to get the llblgen designer working with mysql. for development and testing this way is ok for me. but i hope we have a better solution in near future.

A really better way of course would be using oracle, but odp.net drivers are not running on mono/linux and there is no information about the corelab oracle drivers for linux support :-(

Next week we'll have 3.20 build mysql drivers/dqe's, so the issue should be gone by then.

Your dedication to supporting mysql is great. With the new releases of their database it is a definite competitor to the other major providers for certain applications.

I do wish they would release their connectors under a BSD licenses or similar.

What is the effort involved in supporting a new driver? Would it be fairly easy to port the CoreLAB driver to a MySQL Connector driver?

pdegoede2 wrote:

Your dedication to supporting mysql is great. With the new releases of their database it is a definite competitor to the other major providers for certain applications.

I do wish they would release their connectors under a BSD licenses or similar.

What is the effort involved in supporting a new driver? Would it be fairly easy to port the CoreLAB driver to a MySQL Connector driver?

The problem is that the license of the free MySqlConnector.Net don't allows linking the driver with any closed source projects.

Ok, I've spend the whole day getting it to work but it fails.

It appears that if the assembly ran is compiled against .NET 1.1 it somewhere fails with obfuscated code: when you click on Test connection, it tries to load CoreLab.Common.DbConnection somewhere internally in their code, which isn't there as it's obfuscated in v3.20.7 for .NET 2.0. It ISN'T obfuscated on the .NET 1.1 version.

So, we're still stuck: the driver apparently has to be build against .net 2.0 to make it runnable on .NET 2.0. This is currently not possible due to the fact that the dll has to be placed somewhere and that can only be done with another driverid which is not what you want.

I've mailed corelab to see if they can unobfuscate Corelab.common.dbconnection. If not, mysql support will be pretty limited for now

Why oh why did I ever added support for this miserable database...

i think ist not really a miserable database, only corelab support sucks, because they have implemented a new license model with some fundametle design problems and realeased it without sufficient testing.

mysql itself is a great database, only the mysql driver licensing policys are horrible.

what about adding support for microsoft and only releasing the sourcecodes for llblgen -mysql driver? so every user can build it themself, is this also against gpl?

cjendro wrote:

i think ist not really a miserable database, only corelab support sucks, because they have implemented a new license model with some fundametle design problems and realeased it without sufficient testing.

mysql itself is a great database, only the mysql driver licensing policys are horrible.

Indeed. I got a tip from crlab how to avoid the error, and it now proceeds but I now get the licensing error. I've put licenses.licx files everywhere, no luck.

I give up. If they don't have a solution by 5PM this afternoon I'll pull Mysql support. The DQE and driver will be kept in binary form, but will be build against 2.80.7 like it was in the past.

what about adding support for microsoft and only releasing the sourcecodes for llblgen -mysql driver? so every user can build it themself, is this also against gpl?

The GPL is a distribution license. So if we purchase a license for the mysql provider from mysql, we can ship our code without worries. The problem is, if one of our customers, you for example, ship YOUR application, with our DQE (which is build against mysql's provider) and you don't have a license because you're using a GPL-ed version, you ship a piece of code which then can't be distributed in the current form: non-GPL-ed binary because you're not allowed to ship the DQE dll.

Besides that, the mysql provider from mysql is very expensive (>250 euro per developer) and it's downright silly to ask money for software which is required to actually USE your own software. Like mysql doesn't want .net developers to connect to the db apparently.

It's actually a grey area: it's not very clear defined what a derived work is when it comes to dynamic linking. The FSF, and owner of the GPL, states that dynamic linking is the same as static linking and if you link at runtime to a GPL-ed library, your software is with that a derived work. So even if you load the DQE dynamically, it's debatable if you then can ship the DQE.

But I don't want to mess with that. I have better things to do with my time than to play the stupid games of Mysql or the FSF. I respect their position, it's their license and code after all, but I feel that I don't have to play along with that. MySql is not able to answer simple questions about this licensing other than that we should become VAR for mysql... I don't want to resell any database, I just want to be able to compile against a driver

But enough of this. I hope corelab has an answer before 5PM, if not, I'm sorry.

Ok, Corelab responded very fast (whoa) and using a test program I was able to reproduce the behavior. I sent the stuff to them and ... it worked there. They compiled the code and mailed me the .exe. It worked. It turns out the license resource compiled into the .exe isn't containing the encrypted block of data, while it did in their .exe. While I just use a trial, it should work ok. So I'm waiting for their further replies. perhaps a light at the end of the tunnel...

You thought you all would never see 'solved' on this issue, well, neither would I.

Our problems were related to something in their installer. The trial installation apparently messed something up which caused this issue in the compiled code.

Once I tried it on a different box, with a test dll of corelab, it worked. We've now purchased a full 3.20 license and it both works with the designer on .net 1.1 and .net 2.0.

I hope to release the full installer tomorrow (wednesday). pfew

Otis wrote:

You thought you all would never see 'solved' on this issue, well, neither would I.

You got that right!

Otis wrote:

Our problems were related to something in their installer. The trial installation apparently messed something up which caused this issue in the compiled code.

Once I tried it on a different box, with a test dll of corelab, it worked. We've now purchased a full 3.20 license and it both works with the designer on .net 1.1 and .net 2.0.

I hope to release the full installer tomorrow (wednesday). pfew

I look forward to it!

This works for me (woohoo!).

BTW, if there are any ASP.NET 2.0 people working on shared webservers at ISPs, does anyone know if CoreLab has applied the AllowPartiallyTrustedCallers attributes?

Glad it's finally solved

It turns out, the llblgenpro.exe doesnt' work with the new 3.20.8.0 release, as that's a new version number.

I can't believe this is real. The sad part is, if I update the .exe to 3.20.8.0, it won't work with 3.20.7!!!

I've again mailed corelab, I also told them I'm sick and tired of this crap and that I want a clear solution.

Already got an update on this from Core Lab, they're very fast now .

They fixed it starting from the next version. (which will be 3.20.9).

Does anyone know if CoreLab's MySQLDirect provider is able to run under medium trust? (for webapplications, you can test this by putting <trust level="Medium" originUrl="" /> in the system.web section of web.config)

My understanding is that they've added the AddPartiallyTrustedCallers to the assembly as of this most recent version. This allows it to work in trust environments less than full.

I've not tested that yet myself. Let me know if you find out.

Otis wrote:

Already got an update on this from Core Lab, they're very fast now .

They fixed it starting from the next version. (which will be 3.20.9).

Got this version downloaded but I get while testing the connection:

**File or assembly name CoreLab.MySql, or one of its dependencies, was not found.

-----[Core exception]-------------------- at SD.LLBLGen.Pro.DBDrivers.MySql.MySqlConnectionData._testConnectionButton_Click(Object sender, EventArgs e) at System.Windows.Forms.Control.OnClick(EventArgs e) at System.Windows.Forms.Button.OnClick(EventArgs e) at System.Windows.Forms.Button.WndProc(Message& m) at System.Windows.Forms.ControlNativeWindow.OnMessage(Message& m) at System.Windows.Forms.ControlNativeWindow.WndProc(Message& m) at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)**

Any idea? I downloaded all recent LLBLGen files once again and reinstalled.

Edit: The policy file contains:

**<configuration> <runtime> <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"> <dependentAssembly> <assemblyIdentity name="CoreLab.MySql" publicKeyToken="09af7300eec23701" culture="neutral"/> <bindingRedirect oldVersion="2.80.0.0-3.99.99.99" newVersion="3.20.9.0"/> </dependentAssembly> </assemblyBinding> </runtime> </configuration> **

You installed the correct version of the corelab mysql provider ? e.g.: you installed the .NET 2.0 version if you run llblgen pro on .NET 2.0 ?

Edit: I uninstalled my 3.20.7 version and tried to install 3.20.9, but the installer FAILS!!!

@#^(@#$^@(#$^@#$@#