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

How to make Telerik assemblies of different versions coexist?

20 Answers 1579 Views

General Discussions

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

20 Answers, 1 is accepted

answered on 22 Mar 2010, 02:44 PM

Hi ChunChang,

Thank you for contacting us.

You cannot use different assembly versions referenced within the same project. For example latest RadGridView assembly will have dependencies on the latest Telerik.Common.dll, Telerik.WinControls.dll and Telerik.WinControls.UI.dll assemblies. If you supply different version of any of these assemblies you will end up with an exception since AppDomain will not be able to load the desired types.

Could you please elaborate a bit more why using the latest version is not an option for you? I mean have you experienced some problems or other bugs? If this is the case we will be more than happy to assist you with the migration process.

I am looking forward to hearing from you.

All the best,
Georgi
the Telerik team

Do you want to have your say when we set our development plans? Do you want to know when a feature you care about is added or when a bug fixed? Explore the Telerik Public Issue Tracking system and vote to affect the priority of the items.

answered on 05 Jul 2010, 10:49 AM

Hello,

We managed to use assemblyBinding, dependentAssembly, probing to use 2 different versions in one solution. Currently, the two versions are 2009.3.9.1103 and 2010.1.10.504.

</dependentAssembly>

</dependentAssembly>

</dependentAssembly>

</dependentAssembly>

</dependentAssembly>

</dependentAssembly>

</assemblyBinding>

We found a new problem that the theme of the two versions seems incompatible with each other. For example, RadTreeView looks very strange comparing to its look & feel in one-version projects. We have no clue to solve this at this moment. Do you have any hint for us?

Thanks in advance.

BR/shortie

answered on 08 Jul 2010, 12:06 PM

Hi ChunChang,

Thank you for sharing this useful information.

Actually I was not aware of these particular advanced .NET features. The default assembly binding will search for referenced assemblies of the same version as the assembly being loaded.

I suppose that themes are mismatched in some way due to the different assembly versions. For example if you have loaded a theme assembly with the latest version, it will contain Visual State selectors. The logic behind these selectors however is not present in the 2009.3.9.1103 version and property settings may not be mapped to actual element instances.

Could you please open a new support ticket and attach a sample project that demonstrates the issue so that I may debug it locally and further help you with this issue?

I am looking forward to helping you with this issue.

Sincerely yours,
Georgi
the Telerik team

answered on 10 Aug 2010, 05:58 PM

I just wanted to weigh in on this topic.

Our company has just finished developing a very complicated application suite using Telerik WinForms controls. We are working with DLLs from last fall because it is not practical to keep changing the DLLs while we are developing.

Now that we have finished our version 1, we're starting on version 2. We want to do this with the latest Telerik DLLs.

The problem is that we have to keep maintaining version 1 for the next few months, including making bug fixes, running in the debugger, editing the design screens, etc.

Since it appears that we can't have two different versions of our Telerik controls on the same machine at the same time, we're put in an untenable position. I don't know any solution except to update our version 1 to the latest DLLs also. That means that our hundreds of man-hours of testing are thrown out the window and we have to test everything all over again.

We really wish Telerik would reconsider this insistence that the DLLs be installed in the GAC. We have used several other third-party controls and this was never the case. In the past, with other vendors' DLLs, it was never a problem to have two or more versions of the DLLs on the same computer. We could always run older versions of our software with older versions of the DLLs with no problem. As long as the DLLs were in the directory we're running in, there was never a confusion over versions.

Please reconsider this position.

Thanks,

Mark Kelton

answered on 16 Aug 2010, 11:50 AM

Hello Mark K.,

Thanks for writing.

I am not quite sure I understand your inquiry correctly. Currently, different Telerik versions are installed in the GAC and can be used in separate projects. In other words, we do install our assemblies in the GAC.
However, if you wish to reference different Telerik versions in the same project (as mentioned on this thread), you might experience undesired behavior related to our themes due to the fact that the same themes from different assemblies (based on the old and the new theming mechanism) might interfere.

In conclusion, you can easily install different Telerik versions on a single machine and use them in your separate projects. You will simply have to make sure that you reference the correct version in your project.

I hope this helps.

Kind regards,
Deyan
the Telerik team

answered on 16 Aug 2010, 05:28 PM

Every time we have had problems with the Telerik controls your support team first points to checking to make sure all the Telerik DLLs on the machine, and especially in the GAC, are the same version. When we first started using your Winform controls and did our first couple of updates, we constantly had problems with exceptions trying to load certain design screens in Visual Studio. Again, your support staff always told us that we couldn't have more than one version of the Telerik controls on the machine at one time. We always solved our problem by deleting any older versions of the DLLs.

Now, we do not install Telerik updates on our computers without first deleting the previous version. Since we adopted that policy we have not have any problems with exceptions editing design screens in Visual Studio.

If there is a way to make this work, I don't know what it is. All our projects reference the correct (and same) Telerik DLLs that are copied into the directory where we run our execuatables. We do not use different Telerik versions on the same project.

Mark

answered on 16 Aug 2010, 07:45 PM

Good Topic...

As Mark stated I have found issues when installing a new version of the Telerik controls without removing the previous version. I get weird Visual Studio integration errors, weird design-time problems, and sometimes a wonderful "Unspecified Exception". Usually deleting all Telerik versions and installing only one version resolves most of the problems. However, I could not install the New Q2 2010 SP1 without Q2 2010, I received a lot of Visual Studio issues. But then again, if I tried it again it might of work....oh well, point is the installation of the telerik controls and the way they are integrating with Visual Studio could be improved. I'm sure a lot of Visual Studio is still using COM which causes some issues but I used to be a manager at a Third Party Component company that pre-dated Telerik and we were able to use multiple versions of the product on the same machine without any issues.

If you set your references to Copy Local = True it would copy them to the local bin and would not even look in the GAC for the latest version of the assembly. If you set Copy Local = False it would pull the latest version in the GAC. Shouldn't it be that easy? Actually, when I did upgrade to the latest version my project was still using the old assemblies even though the old version was removed and Copy Local was set to False. All the old assemblies were copied to the bin directory and I guess since the assemblies Specific Version = True it was still using them.

So Mark, I think that is what you wanted correct? My project was still using the old version of Telerik controls even though that version was not installed on my machine anymore. I'm assuming you are branching the source so I think there should be solution to have to branches using different version. Like I said, it use to be set the old one to Copy Local = True and that should be it. Done. Assemblies are in the Bin and nothing else should matter....well that is my opinion.

Eric

answered on 16 Aug 2010, 09:47 PM

Yes, I agree with what you said. We have all our third-party DLLs in a file folder in our project. (We don't reference the location in which they are originally installed by your installer.) They are all set with Copy Local = true.

The ideal situation would be that we could continue to maintain the previous version of our application with the previous version of the third-party DLLs, including being able to run in a debugger and edit design screens with Visual Studio. At the same time, we would be able to develop the new version of our application with the latest version of our third-party DLLs, including being able to debug and edit design screens.

I don't believe this is a problem right now with any of our other third-party vendors (we have 4 altogether). But, we have not been able to find a way to do this with the Telerik controls.

Mark

answered on 17 Aug 2010, 03:13 PM

Telerik,
I do understand that Visual Studio uses COM and you can probably only integrate one version with it at a time but I still feel a certain project should be able to use older versions of the assemblies by Copy Local = true and still be able to use the design time features without a problem. I guess my question is does the VS design time features only work with same version of assemblies that are registered with Visual Studio? I would think it should be smart enough to check which version the project is using through the references and reference that assembly instead of the latest version installed.

Eric

answered on 20 Aug 2010, 07:49 AM

Hi guys,

Thank you for the interesting thread.

As you can see from the attached screen I have 9 versions of our assemblies installed on my machine (this allows me to test projects against different builds) and everything is working perfectly.

The AppDomain will always look-up an assembly from the GAC first and if it does not reside there it will search in local folders (either an explicitly specified binaries folder or the Application's start-up directory). Hence CopyLocal is irrelevant if the same assembly resides in the GAC (actually this is the exact purpose of the GAC). There should be no problems for different Telerik assemblies to co-exist in the GAC. One of the major reasons that force us to put our assemblies in the GAC is better Visual Studio integration.

Issues will be experienced if assemblies from different versions are used within the same project (unless if you use the solution provided by ChunChang). The design-time experience in VS might be fragile sometimes. The designer serializes a whole lot of information in its resource files and sometimes it is the assembly version which may silently break the whole user experience without any meaningful explanation. That is why we recommend having only one version of Telerik installed in the GAC.

@ChungChang
Thank you for the sample project, I will debug it and try to isolate the problem and share the solution with the others.

Regards,
Georgi
the Telerik team

answered on 20 Aug 2010, 03:09 PM

Georgi,

"There should be no problems for different Telerik assemblies to co-exist in the GAC. One of the major reasons that force us to put our assemblies in the GAC is better Visual Studio integration."

This is the statement that isn't true for me. I seem to have a lot of issues with Visual Studio (2008 SP1, XP) integration when I have multiple versions of the Telerik WinForms installed in the GAC. I have problems with "GridView Property Screen", sometimes it doesn't open, fires an error, then when it did open it was really funky. I have issues with Themes not being in the VS property dropdowns, just weird stuff. I had to uninstall all versions of the Telerik Controls and install only 2010 Q2 Sp1 and the errors went away. I don't think the problem is with multiple versions in the GAC, it is the installation creating the Visual Studio integration. Thanks.

Eric

answered on 25 Aug 2010, 03:53 PM

As I stated before, after we did our first update of the Telerik WinForms controls we had a lot of problems with going into the Design Screens in Visual Studio 2008. Many times VS just gave us an exception and we couldn't load the screen at all. Many times the design screen would load and then change some of the properties of the objects on it. We wasted a lot of time trying to get this worked out. The only solution we found was to uninstall the previous version and delete all .DLLs that were not the current version from our machines.

We still have one design screen that changes the properties of the objects when we load it, but other than that, the other problems have gone away and we no longer get exceptions.

This might have to do with which controls are being used and the fact that we use a lot of different ones. We also have nested RadDock controls--RadDock toolwindows that contain other RadDock controls. I don't know that that in particular is an issue. I'm just saying that our user interface is not a simple form.

Mark

answered on 26 Aug 2010, 09:11 AM

Hi guys,

Thank you for your feedback. We appreciate it.

I confirm that in the past we had issues where two different versions of RadControls for WinForms could not coexist on the same machine. As Georgi said, this issue is addressed now. The main issue that remains is the design time experience. We know that there are issues with some designers and with the themes. We will research this issue and will try to find a solution that covers this scenario.

Thank you again for this valuable feedback. Should you have any idea regarding the issue or question, please contact us.

Sincerely yours,
Jack
the Telerik team

answered on 27 Aug 2010, 04:25 AM

Hello Georgi,

This morning we received the final answer from support that we couldn't mix assemblies from different version in one solution. We feel very upset on this.

Our system consists of hundreds of subsystems and thousands of forms. The main program dynamically load application DLLs at run-time. We have already developed tens of subsystems using 2009.Q3 and don't have the spare resource to patching them to the latest Telerik version. And still, we want to develop subsystems using latest version in the future.

This feature is a must for our existing projects to keep in good shape. Or we have to develop all the subsystems using 2009.Q3. That's not what the intention we started to use Telerik in the first place. And this limitation also makes our renew looks unreasonable. Why do we keep renew our subscription if we were not allowed to use the newer in our existing project?

Anyway, the architecture of our system can't be changed at this moment. I am afraid that we will be forced to survey another components to replace Telerik in the existing projects at last.

Sorry, I was too upset to wrote this reply. You can delete this post if you want.

Best regards,
shortie

answered on 30 Aug 2010, 09:45 PM

Hello ChunChang,

Thank you for your feedback.

We understand your position and your concerns. Therefore I looked at your application in detail and I think that I found a suitable solution.

When using assemblies from different versions in the same application, we cannot guarantee that they will coexist without any collisions and that is exactly what my colleague wanted to say. However, by using reflection like you said, it is possible to create a complex plugin system where different plugins use different third party components and assemblies which have different versions. If this is the case, you should consider some of the specifics that the .Net framework requires.

The Assembly.Load method loads the assembly in the current application domain where the application exists. Once loaded, this assembly can not be unloaded until the whole domain is unloaded. In order to avoid any confrontation between assemblies with different versions you have to use different application domains. This way you can instantiate a type in another application domain, execute any methods on it and then unload the domain, and thus unlock the assembly and remove any references from memory. This is quite a common scenario for plug-ins.

You should follow these steps:

1. Create a new AppDomain by using the AppDomain.CreateDomain method.

2. Use the CreateInstanceAndUnwrap method to create an object in the new AppDomain.

3. Extend the MarshalByRefObject interface to use .NET Remoting to access objects in the newAppDomain.

4. Unload the domain when it is no longer needed.

You can find a modified version of your application in your support ticket regarding the same issue.

Please, note that this solution has not been tested and we do not guarantee that it will work as you would like it to.

Finally, we have a question, which we hope you can clear for us. You said that you were left with the impression that two Telerik versions can be used in the same application; do you remember what sentence or help article left you with that impression? This will help us improve our documentation and fix this in order to avoid future misunderstandings of this kind. Thank you in advance.

Kind regards, Jack
the Telerik team