Accessing static members of class in main Assembly

[Jack Addington]

I've got a bit of a problem acceessing a class that I am using as a 'global'
placeholder of numerous static variables I'm using across the application.
Basically I need a place to store a reference to my MDIframe so I can access
it from anywhere.

I have a class called AppObj in a framework assembly. I inherited it in my
main application assembly and called it EPMApp. In my mainform (which is a
mdiframe) I am setting the EPMApp.MDIFrame to the form.

In a separate assembly where I want to open a new MDI child I am trying to
access the AppNameApp.MDIFrame but I cannot find a way to call it. I think
it is because it is in the main assembly. I keep getting the "The type or
namespace name 'EPMApp' could not be found (are you missing a using
directive or an assembly reference?)" compiler error.

I know I'm just doing something silly wrong but I'm not sure what it is. I
was able to move the inherited object into another assembly and then get
things to compile but there must be something wrong if I cannot reference
objects in my main assemble/exe.

could someone please fill in what I'm missing.

thanks

jack

 

[David Browne]

I've got a bit of a problem acceessing a class that I am using as a
'global' placeholder of numerous static variables I'm using across the
application. Basically I need a place to store a reference to my MDIframe
so I can access it from anywhere.

I have a class called AppObj in a framework assembly. I inherited it in
my main application assembly and called it EPMApp. In my mainform (which
is a mdiframe) I am setting the EPMApp.MDIFrame to the form.

In a separate assembly where I want to open a new MDI child I am trying to
access the AppNameApp.MDIFrame but I cannot find a way to call it. I
think it is because it is in the main assembly. I keep getting the "The
type or namespace name 'EPMApp' could not be found (are you missing a
using directive or an assembly reference?)" compiler error.

I know I'm just doing something silly wrong but I'm not sure what it is.
I was able to move the inherited object into another assembly and then get
things to compile but there must be something wrong if I cannot reference
objects in my main assemble/exe.

could someone please fill in what I'm missing.

No. You're not missing anything. You cannot reference items in an EXE.
Only a DLL can be the target of a reference.

Why inherit the type in your exe? Just leave the type in a library and set
its value from code in the EXE.

David

 

[Jon Skeet [C# MVP]]

No. You're not missing anything. You cannot reference items in an EXE.
Only a DLL can be the target of a reference.

Note that this is a VS.NET limitation, not a .NET limitation. .NET
itself allows you to reference an executable instead of a DLL with no
problem.

 

[Jack Addington]

Why is that?

thanks...

Note that this is a VS.NET limitation, not a .NET limitation. .NET
itself allows you to reference an executable instead of a DLL with no
problem.

 

[Jon Skeet [C# MVP]]

Why is that?

Not sure, to be honest. While it's not useful hugely often, every so
often it's handy.

 

[Justin Rogers]

The reason behind this problem is legacy OS support. Aka Windows 95
I believe. We had smiliar issues when certain languages started disabling
support for linking executables as references (aka vbc.exe). This may not
be 100% accurate, since this is an old issue I remember from when I
worked on the .NET QuickStart Tutorials pre-V1.

 

[Jon Skeet [C# MVP]]

The reason behind this problem is legacy OS support. Aka Windows 95
I believe. We had smiliar issues when certain languages started disabling
support for linking executables as references (aka vbc.exe). This may not
be 100% accurate, since this is an old issue I remember from when I
worked on the .NET QuickStart Tutorials pre-V1.

Interesting. Of course, V1.1 doesn't even support Windows 95, so those
issues may have gone.

The common example I can think of where it would be useful would be for
a plugin architecture. If the plugin interface can be in the
executable, with no extra libraries needed, it's often possible to
deploy just the executable itself, making things a bit simpler.