This is a migrated thread and some comments may be shown as answers.

Problem with dll

6 Answers 211 Views
Chart (Obsolete)
This is a migrated thread and some comments may be shown as answers.
This question is locked. New answers and comments are not allowed.
Javier Rodríguez
Top achievements
Rank 1
Javier Rodríguez asked on 18 Aug 2008, 03:48 PM
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

6 Answers, 1 is accepted

Sort by
0
Vladimir Milev
Telerik team
answered on 18 Aug 2008, 03:50 PM
Hello Chris Wylie,

Let me start off with our full acknowledgment of the problem at hand. At telerik we highly value honest and direct communication with our customers. As the person responsible for the decision to reuse the namespace I will try to explain our reasoning behind it.

An year ago we started a massive campaign of migrating our ASP.NET controls from separate controls to the unified Telerik.Web.UI suite. This move created many challenges for us the main one of course being the work our customers will have to perform in order to migrate their applications. As a measure to reduce the changes needed to migrate the classic RadChart control to Telerik.Web.UI we decided to keep the namespace. Choosing another option would have meant an insurmountable amount of code to be fixed - something we cannot afford to ask our customers to do. We were aware that this decision had its drawbacks which you have elaborated here. Still we had to choose the lesser evil and pick a decision and stick with it.

Not a lot of our customers need to run the classic chart and the new one side-by-side. Actually for a whole year since we introduced RadChart in Telerik.Web.UI you are the first one to complain about this problem. Still we appreciate where you are coming from and what you have to say about our products. I can assure you that as a leading component vendor we take backwards compatibility very seriously and always do everything possible to minimize the impact major upgrades have on our user base. Unfortunately, as seen here, this is not always possible. Please, accept my sincere apologies.

Greetings,
Vladimir Milev
the Telerik team

Check out Telerik Trainer, the state of the art learning tool for Telerik products.
0
Javier Rodríguez
Top achievements
Rank 1
answered on 18 Aug 2008, 05:08 PM
Thank you Vladimir.

As a programmer myself, and a manager of a development team, I understand your position and, finally, your decision.  I appreciate your frankness and that you have taken the time to understand our situation.

The DotNetNuke environment does present a fairly unique deployment challange for your controls.  Different modules from different manufacturers can utilize different versions of your controls.  This results in different versions of your dll in the same /bin folder.

As you may know, DNN is becoming increasingly popular with the install package downloaded daily over 6000 times.  With major web hosts providing auto-installations it is hard to say how many new DNN portals are being set up every day.  DNN has become an enterprise class portal with the third party modules becoming more mature, robust and feature rich every week.

As you can imagine, utilizing the Telerik control set is a significant contribution to any DNN module application.  The problem for developers using your controls, and an entry barrier to those considering using your controls, is the DLL hell that we face every time Telerik upgrades versions.

Two of the major DNN module providers that are using your controls:
http://www.onyaktech.com/ and http://dnnsoft.com/ must orchestrate every time either one of them upgrades to a new version of your controls - requiring all of their customer to upgrade the two different products at the same time!  This has been true throughout all of the net2 dlls releases - which they are still using.

I am currently in dialog with both of these companies over how to handle the DLL situation when our product releases in a few months using the latest Ajax version of your DLLs.  We've already run into significant problems at our beta test sites.

Let me ask you this, once all of the DNN module developers go through the final upgrade to the Ajax version of your controls - can you guarantee us that for all following releases:
- the existing dll file names will stay the same (additions are accepted)
- the existing namespaces will remain the same (additions are accepted)
- the dll/namespaces will be backwards compatible so that we do not have to do synchronized product releases based on your control set versions

Not only will this assurance be of great relief to us and our clients, it will also be assuring to any other DNN module developer considering your controls.

Thank you for your time and consideration. 
Chris
0
Vladimir Milev
Telerik team
answered on 21 Aug 2008, 03:38 PM
Hi Chris Wylie,

Sorry for the delay. My answer is YES for the three questions.

- the existing dll file names will stay the same (additions are accepted)
- the existing namespaces will remain the same (additions are accepted)
- the dll/namespaces will be backwards compatible so that we do not have to do synchronized product releases
based on your control set versions


I can most certainly promise you all three.

Thanks once again for your great feedback, understanding and patience.

Best wishes,
Vladimir Milev
the Telerik team

Check out Telerik Trainer, the state of the art learning tool for Telerik products.
0
Javier Rodríguez
Top achievements
Rank 1
answered on 03 Sep 2008, 06:32 PM
Hi Vladamir,

We have now found that clients using the RadEditor in their DNN portal must upgrade to version 2008.2 826 or greater or there are conflicts with the Rad Ajax panels that our DNN module/application is using.

Our "known issues" page is quite long and is almost entirely about the problems introduced by your controls.  From the client's perspective, when they try to install our product they encounter many complex upgrade problems - this can only reflect poorly on us.

Please try to insure smooth upgrades for future releases.

Thanks,
Chris
0
dlee
Top achievements
Rank 1
answered on 09 Sep 2008, 05:01 PM
Just finish upgrading and removing all the dll and reference.
It was the most painful thing I had to deal with because we have 7 projects using the graphs and telerik controls.

We were pretty close to remove the whole thing all together because of this pain. Just hope this kind of thing doesn't happen in the future.

0
Vladimir Milev
Telerik team
answered on 10 Sep 2008, 03:34 PM
Hi dlee,

Thank you guys for the sincere feedback. Backwards compatibility is now a critical priority for all new releases. We now have a mature product which will not change as much as in the past and we can assure you that breaking changes will be restrained to the absolute minimum.

We apologize to everyone for the caused inconveniences.

Kind regards,
Vladimir Milev
the Telerik team

Check out Telerik Trainer, the state of the art learning tool for Telerik products.
Tags
Chart (Obsolete)
Asked by
Javier Rodríguez
Top achievements
Rank 1
Answers by
Vladimir Milev
Telerik team
Javier Rodríguez
Top achievements
Rank 1
dlee
Top achievements
Rank 1
Share this question
or