471,627 Members | 1,571 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,627 software developers and data experts.

Same namespace in EXE and dll

Im currently writing an application that will have some plugin
functionality and therefor Ive 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 couldnt 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 (Im not sure what the correct term
is) several "compilation units"?

In case it will help Ill 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)

Jan 31 '06 #1
1 1956
<pe*******@hotmail.com> wrote:
Im currently writing an application that will have some plugin
functionality and therefor Ive 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 couldnt 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 (Im not sure what the correct term
is) several "compilation units"?
Namespaces themselves should be irrelevant here.

<snip>
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)


Yes, that's probably the problem. However, your assembly doesn't need
to be named after the namespaces it contains. I'd name the application
exe file after the application itself, and then have separate plugin
assemblies with different names.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Jan 31 '06 #2

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

1 post views Thread by Steve George | last post: by
9 posts views Thread by David Thielen | last post: by
3 posts views Thread by tuanhoanganh | last post: by
1 post views Thread by XIAOLAOHU | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.