Hello,
We have a .NET 1.1 WinForms application which does not itself use the TeeChart control. The application manually loads an add-in assembly which uses the TeeChart for .NET v2 control.
At some point in the past, it was explained to us that even though the main application itself did not use or referenced the TeeChart control, it should include "licenses.licx" file as a binary resource. (At the time, I assumed that this was due to the fact that component was searching for the license resource in the primary assembly). We followed the recommendation and application worked as expected.
Recently we upgraded our application to .NET 2.0 + VS2005 and installed an updated TeeChart control (to version 2.0.2652.22325). In the process we had to remove the reference to the original TeeChart control and manually replace the reference to the TeeChart control to allow the add-in project to build.
It is then that we noticed that while add-in assembly built fine, the main executable application stopped building. Compile time error message was:
C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\bin\LC.exe /target:TestChartLicense.exe /complist:Properties\licenses.licx /outdir:obj\Debug\ /i:C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\System.Data.dll /i:C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\System.Deployment.dll /i:C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\System.Design.dll /i:C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\System.dll /i:C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\System.Drawing.dll /i:C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\System.Windows.Forms.dll /i:C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\System.Xml.dll
Properties\licenses.licx(1): error LC0003: Unable to resolve type 'Steema.TeeChart.TChart, TeeChart, Version=2.0.2652.22325, Culture=neutral, PublicKeyToken=9c8126276c77bdb7'
The only way to remove this build error was to add a reference to TeeChart control to our main application. It did not matter that TeeChart was installed and registered on the machine that was building the main application. (I tried the manual registration tool just in case, no help either)
Apparently .NET 1.1 application did not attempt to instantiate the type referred by the licenses.licx file at build time so no error was generated.
The main application is being developed by another group of developers in our organization. Being an infrastructure component it does not and cannot have live references to 3rd party components.
We would prefer to make main binary completely unaware of the 3rd party controls used in add-in assemblies. If that is not possible, we are willing to keep the licenses.licx file in the main application as long as it does not require a reference to the TeeChart at build time. Our only other option is to stop using the TeeChart control completely and move to another vendor (that would be unfortunate since we like the control otherwise)
P.S. A ridiculous thought comes to mind, what if I was making a add-in for Microsoft's Outlook and wanted to use TeeChart? I guess I would then have to ask Microsoft to add license to the Outlook.exe!
-alexs
Licensing changed after upgrade from VS2003 to VS2005
Hello alexs,
The machine that compiles the end-application should have a TeeChart designtime license installed. You can use the TeeReg utility (available on customer download page) to install that. The licenses.licx file of the project should include the TeeChart line, similar to that in your dll project, for TeeChart v2.
If you were to develop with TeeChart in Outlook you would need to install a TeeChart designtime license on the machine compiling the project. It is the designtime use (compilation) of TeeChart that is subject to license control. IOnce compiled the resulting assembly carries the embedded license with it.
Regards,
Marc Meumann
The machine that compiles the end-application should have a TeeChart designtime license installed. You can use the TeeReg utility (available on customer download page) to install that. The licenses.licx file of the project should include the TeeChart line, similar to that in your dll project, for TeeChart v2.
If you were to develop with TeeChart in Outlook you would need to install a TeeChart designtime license on the machine compiling the project. It is the designtime use (compilation) of TeeChart that is subject to license control. IOnce compiled the resulting assembly carries the embedded license with it.
Regards,
Marc Meumann
Steema Support
Marc,
As I have mentioned, TeeChart control is installed on the build host. Both main application and plugin are built on that host. And, in fact, I did ran registration utility as you are suggestion (just in case)
I can compile add-in with TeeChart reference on the build server.
When I attempt to load the add-in assembly it into the main program that does not itself reference TeeChart (and does not contain licenses.licx resource) on a machine without design time license, add-in tries to create the control and gets licensing exception.
Tutorial chapter 17 explains that this is because the primary assembly (exe) must also have license.licx resource with TeeChart.
I used to be able to do just that - add the licenses.licx file to the main exe. However since move to Visual Studio 2005 the main binary does not compile with just that file, even on a machine that have design time license. It actually requires that I have a reference to the control in the project. As soon as I add the control itself to the main application it compiles fine with no other changes on the same box. That behavior has changed since VS2003. It is likely that VS2003 required design time license to build such application. However it did NOT require that my project actually reference the control. This change makes it even harder for add-in design to work.
The situation you describe related to outlook add-in is the ideal solution for me. Unfortunatelly, it does not work as you are suggesting. At run time, TeeChart fails to instantiate if main executable (primary assembly) does not have licenses.licx embedded in it with TeeChart name. Which is pretty much what your Tutorial 17 states.
IMHO, the requirement that primary assembly contain TeeChart reference is inappropriate. Control should check the caller assembly, not the primary assembly.
Thanks,
-alexs
As I have mentioned, TeeChart control is installed on the build host. Both main application and plugin are built on that host. And, in fact, I did ran registration utility as you are suggestion (just in case)
I can compile add-in with TeeChart reference on the build server.
When I attempt to load the add-in assembly it into the main program that does not itself reference TeeChart (and does not contain licenses.licx resource) on a machine without design time license, add-in tries to create the control and gets licensing exception.
Tutorial chapter 17 explains that this is because the primary assembly (exe) must also have license.licx resource with TeeChart.
I used to be able to do just that - add the licenses.licx file to the main exe. However since move to Visual Studio 2005 the main binary does not compile with just that file, even on a machine that have design time license. It actually requires that I have a reference to the control in the project. As soon as I add the control itself to the main application it compiles fine with no other changes on the same box. That behavior has changed since VS2003. It is likely that VS2003 required design time license to build such application. However it did NOT require that my project actually reference the control. This change makes it even harder for add-in design to work.
The situation you describe related to outlook add-in is the ideal solution for me. Unfortunatelly, it does not work as you are suggesting. At run time, TeeChart fails to instantiate if main executable (primary assembly) does not have licenses.licx embedded in it with TeeChart name. Which is pretty much what your Tutorial 17 states.
IMHO, the requirement that primary assembly contain TeeChart reference is inappropriate. Control should check the caller assembly, not the primary assembly.
Thanks,
-alexs
Marc,
I made a simple project to illustrate the problem.
Basically I have a solution with 4 projects in it:
HostApp (exe)
PluginShared (dll) assembly which defines a factory interface
Plugin (dll) a simple plugin which does not use chart
PluginWithChart (dll) another simple plugin which does use chart.
Main app exposes two buttons which instantiate the plugins, plugins themselves expose a factory type with a known name and that type implements a shared factory interface and returns something inheriting from System.Windows.Forms.Form type.
HostApp DOES NOT include licenses.licx and has never contained a reference to the TeeChart object. It also does not have compile time knowledge of the plugins (except the files name of the plugin assemblies)
Within included solution, project dependencies are as follows:
HostApp, Plugin and PluginWithChart all depend on PluginShared
PluginWithChart also depends on TeeChart.
After the build, I set up custom build steps to copy all necessary files into the output directory of the main app, so, at minimum, all you have to do is: expand the zip, go to HostApp/bin/Release (or Debug both are there), and run HostApp.exe
The results I got are as follows:
On a machine with a valid design license, both plugins instantiate properly.
On a machine without such license (I have a wmware image with virgin-clean XPSP2 + .NET 2.0) chart plugin fails to instantiate, the exception caught during construction of the plugin is output via a message box.
I have also included the error.bmp file which contains the image of the error.
The archive of the whole solution dir (with binaries and temp files created during build) (about 3.5 mb) can be downloaded here:
http://www.elitesoftwaregroup.com/files ... inTest.zip
The pic of the error is also below:
-alexs
I made a simple project to illustrate the problem.
Basically I have a solution with 4 projects in it:
HostApp (exe)
PluginShared (dll) assembly which defines a factory interface
Plugin (dll) a simple plugin which does not use chart
PluginWithChart (dll) another simple plugin which does use chart.
Main app exposes two buttons which instantiate the plugins, plugins themselves expose a factory type with a known name and that type implements a shared factory interface and returns something inheriting from System.Windows.Forms.Form type.
HostApp DOES NOT include licenses.licx and has never contained a reference to the TeeChart object. It also does not have compile time knowledge of the plugins (except the files name of the plugin assemblies)
Within included solution, project dependencies are as follows:
HostApp, Plugin and PluginWithChart all depend on PluginShared
PluginWithChart also depends on TeeChart.
After the build, I set up custom build steps to copy all necessary files into the output directory of the main app, so, at minimum, all you have to do is: expand the zip, go to HostApp/bin/Release (or Debug both are there), and run HostApp.exe
The results I got are as follows:
On a machine with a valid design license, both plugins instantiate properly.
On a machine without such license (I have a wmware image with virgin-clean XPSP2 + .NET 2.0) chart plugin fails to instantiate, the exception caught during construction of the plugin is output via a message box.
I have also included the error.bmp file which contains the image of the error.
The archive of the whole solution dir (with binaries and temp files created during build) (about 3.5 mb) can be downloaded here:
http://www.elitesoftwaregroup.com/files ... inTest.zip
The pic of the error is also below:
-alexs
Marc,
Sorry for double post but I forgot to mention something.
If I add licenses.licx file to the HostApp project and try to build it on the same box (with design license present). it fails to build with the following output:
C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\bin\LC.exe /target:HostApp.exe /complist:licenses.licx /outdir:obj\Release\ /i:D:\PluginTest\PluginShared\bin\Release\PluginShared.dll /i:C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\System.Data.dll /i:C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\System.Deployment.dll /i:C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\System.dll /i:C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\System.Drawing.dll /i:C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\System.Windows.Forms.dll /i:C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\System.Xml.dll
licenses.licx(1): error LC0003: Unable to resolve type 'Steema.TeeChart.TChart, TeeChart, Version=2.0.2652.22325, Culture=neutral, PublicKeyToken=9c8126276c77bdb7'
This started happening after the move to VS2005 and prevents the workaround you described in chapter 17 tutorial concerning dlls using the control from working. A quotation from the tutorial 17:
Sorry for double post but I forgot to mention something.
If I add licenses.licx file to the HostApp project and try to build it on the same box (with design license present). it fails to build with the following output:
C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\bin\LC.exe /target:HostApp.exe /complist:licenses.licx /outdir:obj\Release\ /i:D:\PluginTest\PluginShared\bin\Release\PluginShared.dll /i:C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\System.Data.dll /i:C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\System.Deployment.dll /i:C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\System.dll /i:C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\System.Drawing.dll /i:C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\System.Windows.Forms.dll /i:C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\System.Xml.dll
licenses.licx(1): error LC0003: Unable to resolve type 'Steema.TeeChart.TChart, TeeChart, Version=2.0.2652.22325, Culture=neutral, PublicKeyToken=9c8126276c77bdb7'
This started happening after the move to VS2005 and prevents the workaround you described in chapter 17 tutorial concerning dlls using the control from working. A quotation from the tutorial 17:
-alexsUsing TeeChart in a dll
If you have successfully compiled TeeChart with license into a dll, please note that if you then use that dll in another application you need to be sure to add the TeeChart license lines to the Licenses.licx file of the final application even though that application may not itself have a direct reference to TeeChart. If your end-user application is not developed in Visual Studio .NETthen the license file and license itself should not be necessary at the point of final compilation.
Hello alexs,
The licensing works as expected in our test projects, ie. you do not need a reference to TeeChart in the final executable application but a key point differs to your project, you do need a reference to your own dll. We hadn't picked up from earlier posts that your final project doesn't reference your own assembly dll. I see from your example project that it does not, that you are using Assembly.LoadFrom.
In the area of licensing no change has been made to TeeChart for .NET v2 behaviour with respect to version 1. It may be that your version 1 final build was referencing a pre-licensing version or that there was a Uses in your final application to one of your own dll assemblies or that the issue lies with VSNET2005 itself.
We'll do some tests to see whether another licensed option can be offered besides that of adding a 'uses' to you plugin assembly. We'll get back to this thread.
Regards,
Marc
The licensing works as expected in our test projects, ie. you do not need a reference to TeeChart in the final executable application but a key point differs to your project, you do need a reference to your own dll. We hadn't picked up from earlier posts that your final project doesn't reference your own assembly dll. I see from your example project that it does not, that you are using Assembly.LoadFrom.
In the area of licensing no change has been made to TeeChart for .NET v2 behaviour with respect to version 1. It may be that your version 1 final build was referencing a pre-licensing version or that there was a Uses in your final application to one of your own dll assemblies or that the issue lies with VSNET2005 itself.
We'll do some tests to see whether another licensed option can be offered besides that of adding a 'uses' to you plugin assembly. We'll get back to this thread.
Regards,
Marc
Marc,
Assembly.LoadFrom or similar alternatives are the key - it allows the plugin architecture to work.
Keep in mind the outlook.exe example, a 3rd party vendor needs to be able to deliver a plugin assembly not known to Microsoft at build time. So outlook.exe will do exactly what I am doing - call LoadFrom and ask for an interface shared by the application and the plugin.
I am fairly certain that the change is in VS2005 itself, but it just confirms to me that the approach you take when looking for the license file does not support plugin design.
From what I can see in ildasm, your implementation of LicenseProvider called FrAccessProvider, overrides GetLicense method. In that method you invoke GetSavedLicenseKey() method which you do not override, so it functions in a standard way. Based on the parameters passed in I see that you pass null value for the reference to the assembly containing the license resource. Documentation states that when you do that, .NET looks inside the primary assembly only - (EXE). Unfortunatelly, this is what makes it impractical to use your control in a plugin.
An alternative approach would be to get a reference to the calling assembly in the constructor of your control, then use that assembly's reference in GetLicense() implementation in the call to GetSavedLicenseKey(), this will cause .NET to look only in the assembly which calls the constructor of the control - which, in my opinion, is exactly what you care about as far as licensing is concerned.
We are very concerned about this issue and need to address it.
Please let me know as soon as possible about any resolution.
-alexs
Assembly.LoadFrom or similar alternatives are the key - it allows the plugin architecture to work.
Keep in mind the outlook.exe example, a 3rd party vendor needs to be able to deliver a plugin assembly not known to Microsoft at build time. So outlook.exe will do exactly what I am doing - call LoadFrom and ask for an interface shared by the application and the plugin.
I am fairly certain that the change is in VS2005 itself, but it just confirms to me that the approach you take when looking for the license file does not support plugin design.
From what I can see in ildasm, your implementation of LicenseProvider called FrAccessProvider, overrides GetLicense method. In that method you invoke GetSavedLicenseKey() method which you do not override, so it functions in a standard way. Based on the parameters passed in I see that you pass null value for the reference to the assembly containing the license resource. Documentation states that when you do that, .NET looks inside the primary assembly only - (EXE). Unfortunatelly, this is what makes it impractical to use your control in a plugin.
An alternative approach would be to get a reference to the calling assembly in the constructor of your control, then use that assembly's reference in GetLicense() implementation in the call to GetSavedLicenseKey(), this will cause .NET to look only in the assembly which calls the constructor of the control - which, in my opinion, is exactly what you care about as far as licensing is concerned.
We are very concerned about this issue and need to address it.
Please let me know as soon as possible about any resolution.
-alexs
Hello alexs,
Unfortunately the license control that is proving inconvenient at exe level is what is intended to prevent unauthorised designtime use of TeeChart, requiring a designtime license to be present at any moment that an assembly is compiled with intended access to TeeChart. Open plugin support would negate that. Steema introduced this form of license control in response to customer request to offer better control where the teechart.dll form a closed-part of a public-domain runtime/designtime accessible assembly suite.
There are documented alternatives that might be worth a look such as the use of Microsoft's lc.exe to externally add a key. We've not had positive results in tests to date but will add advice to documentation if status changes.
Unauthorised designtime use of TeeChart lies within the field of customer responsibility so whilst Steema attempts to help customers by offering a controlled version, it also offers a physically-unlicensed version of TeeChart for those environments where use of the licensed format is restrictive and distribution manageable.
Please mail a request to sales@steema.com for access to the unrestricted version.
Regards,
Marc
Unfortunately the license control that is proving inconvenient at exe level is what is intended to prevent unauthorised designtime use of TeeChart, requiring a designtime license to be present at any moment that an assembly is compiled with intended access to TeeChart. Open plugin support would negate that. Steema introduced this form of license control in response to customer request to offer better control where the teechart.dll form a closed-part of a public-domain runtime/designtime accessible assembly suite.
There are documented alternatives that might be worth a look such as the use of Microsoft's lc.exe to externally add a key. We've not had positive results in tests to date but will add advice to documentation if status changes.
Unauthorised designtime use of TeeChart lies within the field of customer responsibility so whilst Steema attempts to help customers by offering a controlled version, it also offers a physically-unlicensed version of TeeChart for those environments where use of the licensed format is restrictive and distribution manageable.
Please mail a request to sales@steema.com for access to the unrestricted version.
Regards,
Marc
Marc,
I think I understand your position. You want to ensure that any binary that loads TeeChart directly or indirectly at run time was compiled with a design time license to the TeeChart.
So for example, if you had:
exe -> assembly 1 -> assembly 2 -> TeeChart assembly,
then you want to place a license into all of the components: exe, assembly 1 and assembly 2. The fact that exe -> assembly 1 is done with dynamic loading does not change things. The fact that exe and assembly 1 do not call even a single method of the TeeChart control directly changes nothing as well. As a side note, your current implementation appears to care only if exe has the license at run time.
Bottom line - it is not possible to use a license-protected version of TeeChart control to develop a plugin for an application developed by another company. Personally I find this rather limiting, since so many real-world applications allow plugin-based extension systems.
Since no acceptable workaround appears to be available in our situation, I will now contact the sales department to seek the version without licensing restrictions that you have mentioned.
Thank you very much for your assistance.
-alexs
I think I understand your position. You want to ensure that any binary that loads TeeChart directly or indirectly at run time was compiled with a design time license to the TeeChart.
So for example, if you had:
exe -> assembly 1 -> assembly 2 -> TeeChart assembly,
then you want to place a license into all of the components: exe, assembly 1 and assembly 2. The fact that exe -> assembly 1 is done with dynamic loading does not change things. The fact that exe and assembly 1 do not call even a single method of the TeeChart control directly changes nothing as well. As a side note, your current implementation appears to care only if exe has the license at run time.
Bottom line - it is not possible to use a license-protected version of TeeChart control to develop a plugin for an application developed by another company. Personally I find this rather limiting, since so many real-world applications allow plugin-based extension systems.
Since no acceptable workaround appears to be available in our situation, I will now contact the sales department to seek the version without licensing restrictions that you have mentioned.
Thank you very much for your assistance.
-alexs
Hello alexs,
Re. Bottom line - it is not possible to use a license-protected version of TeeChart control to develop a plugin for an application developed by another company. Personally I find this rather limiting.
With respect, the non-restricted version removes the limitation. That's its role.
Regards,
Marc
Re. Bottom line - it is not possible to use a license-protected version of TeeChart control to develop a plugin for an application developed by another company. Personally I find this rather limiting.
With respect, the non-restricted version removes the limitation. That's its role.
Regards,
Marc
Marc,
Non-restricted version, while technically satisfying our needs, require that we distribute the unprotected TeeChart.dll with our product. This is far from ideal. I am not sure it is even within our right. This is still something that we need to determine.
We intend to make our application available for unrestricted download via internet, so, should we go this route, anybody with the right URL will be able to get your unrestricted TeeChart DLL.
I have sent a request to sales@steema.com as you have suggested with reference to this thread, right now this matter is very much in focus of our development team.
Thank you
-alexs
Non-restricted version, while technically satisfying our needs, require that we distribute the unprotected TeeChart.dll with our product. This is far from ideal. I am not sure it is even within our right. This is still something that we need to determine.
We intend to make our application available for unrestricted download via internet, so, should we go this route, anybody with the right URL will be able to get your unrestricted TeeChart DLL.
I have sent a request to sales@steema.com as you have suggested with reference to this thread, right now this matter is very much in focus of our development team.
Thank you
-alexs
Hello alexs,
Ok, some interesting points here, when we receive your mail perhaps we can take a look at what new license control possibilities we can open up technically within the framework of the distribution you have in mind. As you suggest, general licensing issues of the distribution of a plugin dll housing TeeChart might also open up questions of wider interest.
In general terms, if an application using a .NET assembly is not a .NET assembly itself then the physical license works as you would wish it to, it does not require the exe to have a license key. We can review the possible containers for a closer look.
Regards,
Marc
Ok, some interesting points here, when we receive your mail perhaps we can take a look at what new license control possibilities we can open up technically within the framework of the distribution you have in mind. As you suggest, general licensing issues of the distribution of a plugin dll housing TeeChart might also open up questions of wider interest.
In general terms, if an application using a .NET assembly is not a .NET assembly itself then the physical license works as you would wish it to, it does not require the exe to have a license key. We can review the possible containers for a closer look.
Regards,
Marc
Steema Support
Hello alexs,
Following up on some of your observations and comments we have prepared a TeeChart assembly that could offer better support for the plugin architecture you have described. Please let us know if you are interested to test the pilot assembly. We'll need some contact information from you as we've been unable to contact you offline, so please mail info at steema.com with your correct contact information.
With thanks.
Regards,
Marc
Following up on some of your observations and comments we have prepared a TeeChart assembly that could offer better support for the plugin architecture you have described. Please let us know if you are interested to test the pilot assembly. We'll need some contact information from you as we've been unable to contact you offline, so please mail info at steema.com with your correct contact information.
With thanks.
Regards,
Marc
Steema Support
Marc,
Thank you for continuing interest in this issue. I would be interested in trying out the new assembly, please me know what changes you made to the licensing mechanism and how I can get the new package.
I did receive your earlier email at my work address but was too busy to respond until now. You can continue to use that address or this forum.
-alexs
Thank you for continuing interest in this issue. I would be interested in trying out the new assembly, please me know what changes you made to the licensing mechanism and how I can get the new package.
I did receive your earlier email at my work address but was too busy to respond until now. You can continue to use that address or this forum.
-alexs