Same namespace in EXE and dll

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

I´m currently writing an application that will have some plugin
functionality and therefor I´ve created two projects one that will
build the exe and one that contains the "framework" for the application
as a dll, which also contains reusable controls that the application
and "plugin developers" use.

I was suprised that I couldn´t load a control in my dll assembly from
my application. This worked before I decided to have the same top
namespace in both application and assembly. Is there a problem with
having a namespace duplicated over (I´m not sure what the correct term
is) several "compilation units"?

In case it will help I´ll add the project structure

<Solution>
<ApplicationProject what='Will produce Application.exe'>
<DefaultNamespace>Application</DefaultNamespace>
<Reference>Application.dll</Reference>
<MainFormClass>
namespace Application.ui
{
public class MainForm: Form
{
private void InitializeComponents()
{
//load a SuperControl from the Framework assembly
superControl = new
Application.Forms.SuperControl();
}
}
</MainFormClass>
</ApplicationProject>

<FrameworkProject what='Will produce Application.dll'>
<DefaultNamespace>Application</DefaultNamespace>
<SuperControlClass>
namespace Application.Forms
{
public class SuperControl : UserControl
{
}
}
</SuperControlClass>

</FrameworkProject>

</Solution>

.....
I just tried renaming my assembly dll to a different name and it worked
so the above question becomes void. So it appears that if your
application is Application.exe and you try to load controls from a
Application.dll assembly it won't work. Is there a reason for that? (It
looks like, eventhough I add Application.dll as a reference, it only
tries to load the control from Application.exe. I get a feeling the
reference is just stored as "Application" and when it's time to load
the reference the "virtual machine" will find Application.exe before
Application.dll and be satisfied with that)

.

Relevant Pages

  • Re: Current.Handler is nothing within business object
    ... Did some debugging, and it looks like current.handler is only available to ... controls after the page load has executed. ... >> get a reference to the page object via ...
    (microsoft.public.dotnet.framework.aspnet)
  • RE: Usage of AppDomain.CreateInstanceFromAndUnwrap method
    ... The reason for other failures is that Controls are not inherited from ... so the program will attempt to load them into the ... Create an AppDomain, do a CreateInstanceAndUnwrap on ... Assemblies in to a seprate ...
    (microsoft.public.dotnet.framework.clr)
  • Re: The Command event of dynamically loaded controls
    ... to load a hierarchical list of folders and files from a database and display ... I'll need to load the folder list in the first pass to wire up the ... controls and corresponding event handlers. ... > and triggers events. ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: Strategies for autoloading ruby files
    ... Following up on my post about complicated problems, ... # Load here, rather than require, because otherwise ... In fact, it'd be ideal if you could write a module that allows you to register autoload paths (e.g., I'd use 'facter', 'puppet/type', 'puppet/type/package', 'puppet/type/service', and lots more), and then just have hooks into that module so that you could autoload all instances, or just load a specific name. ... class PlugIn ...
    (comp.lang.ruby)
  • Re: Form Performance
    ... can take a lot of time to load. ... it is not the number of controls. ... So, combo box controls, and sub-form controls are very expensive in terms ... > that tab. ...
    (microsoft.public.access.modulesdaovba)