This question is locked. New answers and comments are not allowed.
Hello,
I am adding a support ticket discussion onto this thread for two reasons:
1 - the larger community will find it useful to understand the ramifications of this problem when the /bin folder may hold the old RadChart.Net2.dll from more than one third party vendor.
2 - I want a public URL to give to my clients who are in disbelief and are assuming this is the fault of our product
**********************************************************
From: Chris Wylie
Date: 8/14/2008 5:45:50 PM
We are using the Telerik charting control in one of our commercial DNN products. It is a DNN module that will be installed in DNN portals that could contain any number of other third party DNN modules.
In the current release, Telerik has renamed the RadChart.Net2.dll to Telerik.Charting.dll. There is a serious problem. The new charting DLL has a different file name - so it does not overwrite the old DLL file.
If any of our clients have installed a previous version of our product or if any of our clients have any other thrid party DNN modules that use RadChart.Net2.dll then they need to manually delete the old DLL using an FTP client. If you they do not do this, then the IIS DLL handler will find duplicate namespaces within the two different DLLs and this will cause a run time error when loading the module.
In the case where a thrid party DNN module was using RadChart.Net2.dll our clients must also manually update any of the other module’s .ascx pages that references the old DLL. The must download from their server and open the .ascx files in Notepad. At the top of the file the must find a register directive similar to the one below:
<%@ Register Assembly="RadChart.Net2" Namespace="Telerik.Charting" TagPrefix="my.tag.prefix" %>
And then update this directive to the following and then restore the files to their server:
<%@ Register Assembly=" Telerik.Charting" Namespace="Telerik.Charting" TagPrefix="my.tag.prefix" %>
~ ~ ~
This creates a lot of confusion and concern - even for clients that do not have any other applications utilizing the RadChart control.
First, let me make sure. Is the nightmare true? Or is this all a bad dream? If this is true, is there any better way for our clients to resolve this problem other than the "solution" I describe?
Thanks,
Chris
*********************************************************
From: telerik
Date: 8/15/2008 5:48:46 AM
Hello Chris,
I am afraid your statement is correct and the users will have to remove RadChart.Net2.dll manually. The reason for taking such decision is our policy to encourage our clients to use the latest versions of our products. This way you will be able to take advantage of the new features and bug fixes introduces with each new version.
I just need to clarify the Register directives substitution. RadChart for ASP.NET AJAX is now in Telerik.Web.UI.dll, while the chart engine is in Telerik.Charting.dll. So, when migrating to RadChart for ASP.NET AJAX there are two Register directives that should be replaced:
<%@ Register Assembly="RadChart.Net2" Namespace="Telerik.WebControls" TagPrefix="myTagPrefix1" %>
<%@ Register Assembly="RadChart.Net2" Namespace="Telerik.Charting" TagPrefix="myTagPrefix2" %>
should become
<%@ Register Assembly="Telerik.Web.UI" Namespace="Telerik.Web.UI" TagPrefix="myTagPrefix1" %>
<%@ Register Assembly="Telerik.Charting" Namespace="Telerik.Charting" TagPrefix="myTagPrefix2" %>
I have already notified our developers of this problem. Please, accept our apologies for the inconvenience caused. Do not hesitate to contact us if any further questions arise.
Best regards,
Ves
the Telerik team
**********************************************************
From: Chris Wylie
Date: 8/15/2008 9:48:26 AM
Hello Ves,
Please try to imagine the difficulty this will cause for some of my clients (and my support team).
1 - a client already has other third party DNN modules installed using the old DLL.
2 - the client now installs our product, which uses the new DLL, and now there are namespace conflicts that cause run time errors
3 - the client must now search through all his third party DNN module /Desktop Modules/directories (could be dozens) and search each .ascx file for the Register Directives that need to be updated.
This whole process is even more difficult for clients with remote shared hosting accounts. Should they FTP down their entire /Desktop Modules/ directory tree to their local server and then begin the piecemeal search?
Not only does this appear to the client as something our product is causing, but many of my clients may not have the technical expertise to do this. What do your engineers suggest we do then?
Please give your engineers some feedback from the trenches and ask then to avoid this in the future.
Thanks,
Chris
I am adding a support ticket discussion onto this thread for two reasons:
1 - the larger community will find it useful to understand the ramifications of this problem when the /bin folder may hold the old RadChart.Net2.dll from more than one third party vendor.
2 - I want a public URL to give to my clients who are in disbelief and are assuming this is the fault of our product
**********************************************************
From: Chris Wylie
Date: 8/14/2008 5:45:50 PM
We are using the Telerik charting control in one of our commercial DNN products. It is a DNN module that will be installed in DNN portals that could contain any number of other third party DNN modules.
In the current release, Telerik has renamed the RadChart.Net2.dll to Telerik.Charting.dll. There is a serious problem. The new charting DLL has a different file name - so it does not overwrite the old DLL file.
If any of our clients have installed a previous version of our product or if any of our clients have any other thrid party DNN modules that use RadChart.Net2.dll then they need to manually delete the old DLL using an FTP client. If you they do not do this, then the IIS DLL handler will find duplicate namespaces within the two different DLLs and this will cause a run time error when loading the module.
In the case where a thrid party DNN module was using RadChart.Net2.dll our clients must also manually update any of the other module’s .ascx pages that references the old DLL. The must download from their server and open the .ascx files in Notepad. At the top of the file the must find a register directive similar to the one below:
<%@ Register Assembly="RadChart.Net2" Namespace="Telerik.Charting" TagPrefix="my.tag.prefix" %>
And then update this directive to the following and then restore the files to their server:
<%@ Register Assembly=" Telerik.Charting" Namespace="Telerik.Charting" TagPrefix="my.tag.prefix" %>
~ ~ ~
This creates a lot of confusion and concern - even for clients that do not have any other applications utilizing the RadChart control.
First, let me make sure. Is the nightmare true? Or is this all a bad dream? If this is true, is there any better way for our clients to resolve this problem other than the "solution" I describe?
Thanks,
Chris
*********************************************************
From: telerik
Date: 8/15/2008 5:48:46 AM
Hello Chris,
I am afraid your statement is correct and the users will have to remove RadChart.Net2.dll manually. The reason for taking such decision is our policy to encourage our clients to use the latest versions of our products. This way you will be able to take advantage of the new features and bug fixes introduces with each new version.
I just need to clarify the Register directives substitution. RadChart for ASP.NET AJAX is now in Telerik.Web.UI.dll, while the chart engine is in Telerik.Charting.dll. So, when migrating to RadChart for ASP.NET AJAX there are two Register directives that should be replaced:
<%@ Register Assembly="RadChart.Net2" Namespace="Telerik.WebControls" TagPrefix="myTagPrefix1" %>
<%@ Register Assembly="RadChart.Net2" Namespace="Telerik.Charting" TagPrefix="myTagPrefix2" %>
should become
<%@ Register Assembly="Telerik.Web.UI" Namespace="Telerik.Web.UI" TagPrefix="myTagPrefix1" %>
<%@ Register Assembly="Telerik.Charting" Namespace="Telerik.Charting" TagPrefix="myTagPrefix2" %>
I have already notified our developers of this problem. Please, accept our apologies for the inconvenience caused. Do not hesitate to contact us if any further questions arise.
Best regards,
Ves
the Telerik team
**********************************************************
From: Chris Wylie
Date: 8/15/2008 9:48:26 AM
Hello Ves,
Please try to imagine the difficulty this will cause for some of my clients (and my support team).
1 - a client already has other third party DNN modules installed using the old DLL.
2 - the client now installs our product, which uses the new DLL, and now there are namespace conflicts that cause run time errors
3 - the client must now search through all his third party DNN module /Desktop Modules/directories (could be dozens) and search each .ascx file for the Register Directives that need to be updated.
This whole process is even more difficult for clients with remote shared hosting accounts. Should they FTP down their entire /Desktop Modules/ directory tree to their local server and then begin the piecemeal search?
Not only does this appear to the client as something our product is causing, but many of my clients may not have the technical expertise to do this. What do your engineers suggest we do then?
Please give your engineers some feedback from the trenches and ask then to avoid this in the future.
Thanks,
Chris