Is there a solution to DLL Hell for DotNetNuke?

Module 1 running version 1 of a third party vendors grid.

Module 2 is installed running version 3 of the same third party vendors control. Now Module 1 fails.

Is is possible to put such controls into DesktopModules\MyModule\bin and refer to them there? If so how?

-d

How would this resolve the possible clash of using Telerik or Component One grids or any other 3rd party component in modules.

If for example vendor X used Telerik RadGrid version 4 and I subsequently purchase a module from vendor Y who happens to use Telerik RadGrid version 5, I have a problem. Ver 5 will overwrite ver 4 in the bin folder thus, most likely, rendering the module from vendor X useless!!!

This problem must also apply to ASP.Net applications. If so there must be some solution otherwise anytime a vendor releases an update to a control the complete application (all modules using the control) would need to be recompiled. This is not always desireable in a large-ish suite of modules. Dynamic compilation is not necessarily a desired solution and does not overcome the 3rd party controls issue.

Am I missing something fundamental?

Declan

If the component uses dynamic compilation it does solve the problem.

Modules should not use shared components because they cannot control the DotNetNuke environment. If you want to use the latest greatest grid control you need to get the source code and compile the grid code inside your module in the namespace of your module or use dynamic compilation. Otherwise don't use it.

I am guilty of this myself. I made a module:

http://www.adefwebserver.com/DotNetNukeHELP/Misc/DynamicForms.htm

That uses "DBauer.Web.UI.WebControls.DynamicControlsPlaceholder.dll". However I have the source code for this control and I should have used it. I recently used this for a paying client and I realized that I was about to put this client into .dll hell. So I put the code in the app_code directory as dynamic code.