Licensing problem from native code

[Mark Graham]

How do I solve the problem of licensing TeeChart when my assembly is called from a 32 bit (Delphi 5) program?

I have a C# application which contains a TChart. This application is then called from an older application written in Delphi 5 (ie regasm the assembly and import into the delphi app).

My C# program will run fine standalone on a fresh machine, so the license file must be getting included correctly. But when the application is instantiated from D5, I get the null reference exception.

Is this possible?
(I use TeeChart v2.0.1992.14012 with Visual Studio 2002.)

Thanks,
Mark.

[Mark Graham]

Anyone ?

Is this not something that other people have run in to? Is it something that isn't supported by Steema?

Thanks
Mark.

[Marc]

Hello Mark,

There should be no problem calling a compiled Assembly that uses TeeChart from a non NET assembly exe. How exactly is the assembly being called?

With thanks.
Regards,
Marc Meumann

[Mark Graham]

Hi Marc,

My c# .net assembly is an executable, containing TeeChart in a user control, which is then used in a form. This assembly is then 'regasm'ed to produce a tlb for use in Delphi 5.

In my delphi 5 app I produce a _tlb.pas wrapper from the tlb file (project -> import type library)

Then I create the assemby using CreateComObject(guid)

Is there something I've missed? I have uploaded a sample project to the attachments newsgroup.


Mark.

[Marc]

Hello Mark,

We've run some tests on this, running your executable and re-compiling in 2 different environments though not exactly the environment you're running, because we don't have that combination readily available here. The results should be similar though.

- Test 1: Running your application in a machine with Framework 1.0 with TeeChart v2.0.1992.14012
- Test 2: Delphi2006 with TeeChart v2 compiled in Visual Studio NET2005 (Framework 2)
- Test 3: Delphi7 with TeeChart v2 compiled in Visual Studio NET2003 (Framework 1.1)

Running your application:
We ran it in a machine with VSNET2002, framework 1.0.3705 and registered the TeeChartAssembly with regasm based on your batch file. It ran ok. The TeeChartAssembly.tlb that was generated was slightly different, so you might want to take note of the regasm.exe version that we have installed here in case it's any different: v1.0.3705.0, date: 5th Jan 2002.

Our compilation tests:
We tested by compiling the TeeChartAssembly with license active. That runs fine too if we go to the visible TeeChart registry license key and modify the contents (to make our development machine act as if it doesn't have a designtime license):

ie.

[HKEY_LOCAL_MACHINE\SOFTWARE\Steema Software\TeeChart.NET]

TeeChart for .NET v2:

"DesignKeyV2"="Steema.TeeChart.TChart is a licensed component."
change to:
"DesignKeyV2"="xxSteema.TeeChart.TChart is a licensed component."

Running the application is successful if the license is properly compiled into the application.

On both the Delphi 2006 and Delphi 7 projects we needed to re-regasm the mscorlib.dll to update to the correct version relative to the framework we were using. Compiling the Project1.exe in both environments and moving it to the folder where the TeeChartAssembly is located resulted in successful execution of the exe and opening of the .NET Assembly (all tests run with the Developer license key disabled in the test machine).

-------------
Recap:
The app seems to work well here from the original to the recompiled versions in different frameworks. The only difference we noticed is the resulting tlb that differed from yours after regasm, so the only factor that we see as possibly different is that. Does the application fail in all your machines? If not, please check the framework versions running on those machines to confirm they match those of the developer machine. Please note that on the developer machine you can check the runtime license 'runnability' by modifying the registry key as described above.

Please let us know if these findings don't shed any light and if we should look for further possible causes of the problem.

With thanks.
Regards,
Marc Meumann