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 "compilatio n units"?
In case it will help I´ll add the project structure
<Solution>
<ApplicationPro ject what='Will produce Application.exe '>
<DefaultNamespa ce>Application</DefaultNamespac e>
<Reference>Appl ication.dll</Reference>
<MainFormClas s>
namespace Application.ui
{
public class MainForm: Form
{
private void InitializeCompo nents()
{
//load a SuperControl from the Framework assembly
superControl = new
Application.For ms.SuperControl ();
}
}
</MainFormClass>
</ApplicationProj ect>
<FrameworkProje ct what='Will produce Application.dll '>
<DefaultNamespa ce>Application</DefaultNamespac e>
<SuperControlCl ass>
namespace Application.For ms
{
public class SuperControl : UserControl
{
}
}
</SuperControlCla ss>
</FrameworkProjec t>
</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 "Applicatio n" and when it's time to load
the reference the "virtual machine" will find Application.exe before
Application.dll and be satisfied with that)
