P
peeping_t
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)
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)