Problem:
Commerical control ChilKat has a naming collision with DNN's TreeNode Class; any module that installs this control will no longer be able to access the DNN filemanager.
Effected versions 3.x / 4.x
Problem Summary:
This seems to be a problem with .NET and resolving class names outside of the orignal assembly. DotNetNuke should be able to resolve the reference to DotNetNuke.UI.WebControls.TreeNode, but instead of resolves it down to Chilkat's privately-marked TreeNode Class - even though there is no reference or other association with chilkat in the dotnetnuke assembly.
What we believe we are seeing here is a bug with .NET's Imports statement under vb.net, as it's not taking that as a priority method of resolving the class name.
To replicate this issue:
Load the DotNetNuke source project.
Add a reference in the DotnetNuke project to Chilkat.dll's (you can download an eval version to test this)
VS.NET will immediately report: 'TreeNode' is not accessible in this context because it is 'Private' - this identifies the collision of the class names.
Resolution:
Fully qualifying the class name resolves the issue, in other words, change:
TreeNode references to DotNetNuke.UI.WebControls.TreeNode
Larger fundamental issues going forward:
.NET seems to have difficulty with class resolution across DLL's - thus collisions like this may occur with any third party control or commerical module loaded into the same application space as DNN.
Long-term resolution I propose is that all satellite assembly classes should be prefixed with DNN to prevent this behaviour from occuring in the future.
Reference Microsoft's recommendations:
Classes with the Same Name
When you create a new instance of an object, you might have to qualify the class with the namespace or type library to which it belongs. For example, the System.Windows.Forms and System.Web.UI.WebControls namespaces both contain a Label class (System.Windows.Forms.Label and System.Web.UI.WebControls.Label). If your application uses both, or if it defines its own Label class, you must distinguish the different Label objects. Include the namespace or import alias in the variable declaration. The following example uses the import alias.
Taken from http://msdn2.microsoft.com/en-us/library/9z4yz8w6.aspx