How do I use the same Web User Control in two different DotNetNuke (DNN) modules?

I am developing a number of modules for a client that will share some user interface functionality using a common Web User Control to provide the UI. When I wrote the first module and added in the .ascx file, all was fine. When I add the same control to the second module, I get the following error:

DotNetNuke.Services.Exceptions.ModuleLoadException: The type 'XXX.ParametersControl.ParameterTabControl' is ambiguous: it could come from assembly 'C:\Clients\XXX\Code\Reporting\DotNetNuke_BaseInstall\bin\XXX.KPI_Configurable_Chart.DLL' or from assembly 'C:\Clients\XXX\Code\Reporting\DotNetNuke_BaseInstall\bin\XXX.Survey_Grid.DLL'. Please specify the assembly explicitly in the type name.

Both modules install and run just fine without this additional UI control.

I developed the UI control as a separate project that compiles it's own DLL for the included back end functionality, then deploy the application with just the compiled DLL and the control ASCX file in the module install files.

The include into the main module ASCX is done this way:

<%@ Register src="ParameterControl/ParameterTabControl.ascx" tagname="ParameterTabControl" tagprefix="uc1" %>

As you can see, I include the interface control by getting it from a subdirectory, which I implement as a Subversion external.

I reference the control's objects and properties in the main module's .vb codebehind like this:

ParameterTabControl1.DateRangeTabVisible = True
If (ParameterTabControl1.StartDate Is Nothing) Then
     ParameterTabControl1.StartDate = DateAdd(DateInterval.Day, -90, Now)
End If

Any tips on how to engineer t开发者_Python百科his so it doesn't happen? Some way to get the sub-control ASCX to connect only to it's own DLL and not be bound to the main module control while still allowing me to query properties and objects on the control to set and get it's properties?

Have you tried specifying the shared assembly and/or namespace in your @ Register tag? I don't know the exact values for your shared component but you can specify exactly which namespace and assembly to use:

<%@ Register src="ParameterControl/ParameterTabControl.ascx"
tagname="ParameterTabControl" tagprefix="uc1" assembly="XXX.SharedControls"
namespace="My.Shared.Control" %>  

Check out the @ Register documentation for more information.

I think that I solved this for good using a workaround to break the link between the projects. Having them both in the same solutions as the main control seemed to be the issue. I pulled the ParameterTabControl out of the solutions for the DNN Modules and just open it in a second copy of VS. Without the "project reference" in VS it just links the code to the DLL directly and doesn't import the DLLs namespace.

I had to add some post-build events to the ParameterTabControl to automatically push the new DLL to the testing platform in order to prevent version control issues between the two DNN Module solutions, but that wasn't too much work. Then the latest common DLL is always available to both and they both see the same version when compiled. It's a hack, but it works.

For once, I was pleasantly surprised with both the completeness and correctness of the error thrown and displayed.

Thanks Lance and Ian.