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. (XXX is the name of the client, sorry, can't share...) 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" %> arameterTabControl ID="ParameterTabControl1" runat="server" /> 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 this 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?

Probably the best way to do this is to put the common control in it's own class file and namespace, and compile it into a dll. Then, you would reference that dll in each module and have only one version of the dll installed. A good example of this is the DotNetNuke.dll that contains all sorts of controls, classes, etc.

Joe, that is what I am trying to do. But the problem is that regular DLL library classes don't have associated ASCX controls in the same namespace.

They don't have to be in the same namespace if you use the full name, including the namespace.

I figured it out. I was including the whole directory with the control in it into my child projects. Subsequently the .vb codebehinds, with their namespace declarations, were being compiled into the project module DLLs and never being referenced from the subcontrols own DLL. That's why it worked with one module on the system but not both of them. When I removed the .vb scripts (and the project reference back to the subcontrol project) from the main module projects, leaving just the ascx file, the ascx file had to get it's code from it's own precompiled DLL and all was right. Both controls could use the same precompiled DLL and just use the ascx and the DLL, not the vb source.