A public class is not visible in the namespace ... why

[Andrew Falanga]

Hi,

The code in which this is happening is too large to post here, not to
mention, I can't post snippets from this code here. So, right up
front, I know that the problem may be masked in whatever "skeleton"
code I write below. Never the less, it's all I've got to work with at
this point.

So, the question is simply, why would a public class not be "visible"
to other classes and methods within the same namespace? In fact,
using .NET reflector, I don't see this class either. So, here's what
I have, roughly:

In file1:

namespace some.name.space {
public class SingletonClass {
private SingletonClass instance = null;

public static SingletonClass Instance() {
if(instance == null)
instance = new SingletonClass();
return instance;
}

// private ctor and other stuff
}
}

Then, in file2:

namespace some.name.space {
public ClassInFile2 {
ClassInFile2() {
SingletonClass.Instance().<call_some_method>;
}
}
}

I don't understand why, but I cannot see SingletonClass in file 2,
even though SingletonClass is typed as public AND they're both in the
same namespace AND part of the same solution. What's further odd, the
SingletonClass doesn't show up in .NET reflector. What gives? What
subtle aspect of access modifiers am I missing?

Again, I know that it's much more difficult to help without the code
I'm actually working. Again, I simply can't paste snippets from that
code here.

Thanks,
Andy

 

[Harlan Messinger]

Hi,

The code in which this is happening is too large to post here, not to
mention, I can't post snippets from this code here. So, right up
front, I know that the problem may be masked in whatever "skeleton"
code I write below. Never the less, it's all I've got to work with at
this point.

So, the question is simply, why would a public class not be "visible"
to other classes and methods within the same namespace? In fact,
using .NET reflector, I don't see this class either. So, here's what
I have, roughly:

In file1:

namespace some.name.space {
public class SingletonClass {
private SingletonClass instance = null;

public static SingletonClass Instance() {
if(instance == null)
instance = new SingletonClass();
return instance;
}

// private ctor and other stuff
}
}

Is the actual class error-free?

Then, in file2:

namespace some.name.space {
public ClassInFile2 {

Is the word "class" omitted in the actual code as it is here?

 

[Family Tree Mike]

Hi,

The code in which this is happening is too large to post here, not to
mention, I can't post snippets from this code here. So, right up
front, I know that the problem may be masked in whatever "skeleton"
code I write below. Never the less, it's all I've got to work with at
this point.

So, the question is simply, why would a public class not be "visible"
to other classes and methods within the same namespace? In fact,
using .NET reflector, I don't see this class either. So, here's what
I have, roughly:

In file1:

namespace some.name.space {
public class SingletonClass {
private SingletonClass instance = null;

public static SingletonClass Instance() {
if(instance == null)
instance = new SingletonClass();
return instance;
}

// private ctor and other stuff
}
}

Then, in file2:

namespace some.name.space {
public ClassInFile2 {
ClassInFile2() {
SingletonClass.Instance().<call_some_method>;
}
}
}

I don't understand why, but I cannot see SingletonClass in file 2,
even though SingletonClass is typed as public AND they're both in the
same namespace AND part of the same solution. What's further odd, the
SingletonClass doesn't show up in .NET reflector. What gives? What
subtle aspect of access modifiers am I missing?

Again, I know that it's much more difficult to help without the code
I'm actually working. Again, I simply can't paste snippets from that
code here.

Thanks,
Andy

Fixing the errors in the code above, as you suspected, does not
illustrate your problem. The errors I see are that you need a static
keyword on the declaration of SingletonClass.instance, and a class
keyword in the class definition for ClassInFile2.

Is by chance ClassInFile2, actually in a separate project?

 

[Andrew Falanga]

Is the actual class error-free?



Is the word "class" omitted in the actual code as it is here?

The code is error free and compiles. That was a typo on my part.
Can't believe I missed that one.

Andy

 

[Jeff Johnson]

I don't understand why, but I cannot see SingletonClass in file 2,
even though SingletonClass is typed as public AND they're both in the
same namespace AND part of the same solution. What's further odd, the
SingletonClass doesn't show up in .NET reflector. What gives? What
subtle aspect of access modifiers am I missing?

Are they part of the same assembly?

 

[Andrew Falanga]

Are they part of the same assembly?

They are in the same assembly and in the same solution, though they
are in different projects (i.e. DLLs then). I'm terribly sorry about
the typos. The code, as it exists now, compiles and has been working
for quite some time. I need to make some additions for new support.

Andy

 

[Arne Vajhøj]

The code in which this is happening is too large to post here, not to
mention, I can't post snippets from this code here. So, right up
front, I know that the problem may be masked in whatever "skeleton"
code I write below. Never the less, it's all I've got to work with at
this point.

So, the question is simply, why would a public class not be "visible"
to other classes and methods within the same namespace? In fact,
using .NET reflector, I don't see this class either. So, here's what
I have, roughly:

In file1:

namespace some.name.space {
public class SingletonClass {
private SingletonClass instance = null;

public static SingletonClass Instance() {
if(instance == null)
instance = new SingletonClass();
return instance;
}

// private ctor and other stuff
}
}

Then, in file2:

namespace some.name.space {
public ClassInFile2 {
ClassInFile2() {
SingletonClass.Instance().<call_some_method>;
}
}
}

I don't understand why, but I cannot see SingletonClass in file 2,
even though SingletonClass is typed as public AND they're both in the
same namespace AND part of the same solution. What's further odd, the
SingletonClass doesn't show up in .NET reflector. What gives? What
subtle aspect of access modifiers am I missing?

Again, I know that it's much more difficult to help without the code
I'm actually working. Again, I simply can't paste snippets from that
code here.

It is not just difficult. It is impossible.

If you can create a simple example that actually compiles
and shows the problem, then we can tell you what the problem is.

If not then the answer is 42.

Arne

 

[Peter K]

They are in the same assembly and in the same solution, though they
are in different projects (i.e. DLLs then). I'm terribly sorry about
the typos. The code, as it exists now, compiles and has been working
for quite some time. I need to make some additions for new support.

Do you references between the projects?

And I have an additional question: can you have separate projects that
compile to the same assembly?

 

[Peter Duniho]

[...]
I don't understand why, but I cannot see SingletonClass in file 2,
even though SingletonClass is typed as public AND they're both in the
same namespace AND part of the same solution. What's further odd, the
SingletonClass doesn't show up in .NET reflector. What gives? What
subtle aspect of access modifiers am I missing?

Reflector (and the ildasm.exe tool) shows you everything in the
assembly, regardless of access modifiers. If the class isn't showing up
in Reflector then either you are using Reflector incorrectly, or the
module is not being compiled as part of the assembly.

Others have already pointed out the futility of you posting code that is
_not_ the code that's giving you trouble, so I won't belabor that point.

Individual files can be excluded from the build in the project settings,
so it's possible that got misconfigured somehow. Or it's possible you
just are confused about the way your solution and projects are
configured. Without a real code example, it's not possible to provide
real answers.

Pete

 

[Jeff Johnson]

Do you references between the projects?

And I have an additional question: can you have separate projects that
compile to the same assembly?

No, you can't, which is where Andrew is confused. If they are part of
different DLLs then they are in different assemblies. There is only one
NAMESPACE, but there are multiple ASSEMBLIES. Remembers, an assembly is
ultimately a file, whether it be an EXE or a DLL. This is why I asked the
question in the first place, and I think the whole issue might simply be one
of needing project references between the two, like you suggested.

 

[Andrew Falanga]

[...]
I don't understand why, but I cannot see SingletonClass in file 2,
even though SingletonClass is typed as public AND they're both in the
same namespace AND part of the same solution.  What's further odd, the
SingletonClass doesn't show up in .NET reflector.  What gives?  What
subtle aspect of access modifiers am I missing?

Reflector (and the ildasm.exe tool) shows you everything in the
assembly, regardless of access modifiers.  If the class isn't showing up
in Reflector then either you are using Reflector incorrectly, or the
module is not being compiled as part of the assembly.

Others have already pointed out the futility of you posting code that is
_not_ the code that's giving you trouble, so I won't belabor that point.

Individual files can be excluded from the build in the project settings,
so it's possible that got misconfigured somehow.  Or it's possible you
just are confused about the way your solution and projects are
configured.  Without a real code example, it's not possible to provide
real answers.

Pete

I completely understand, and appreciate, the struggle to help without
the actual code. I cannot post that here due to company
restrictions. Also, you wouldn't want to wade through it since it's
several thousand lines.

Unfortunately, I cannot post a working example, much beyond the
skeleton code already posted, because to do so would require that I
understood the problem. I do not. The answers given will prove
helpful. I'm going to go and look through my references to see if the
project I'm working in isn't referencing the other project correctly.

It must be something like this because a different project, also in
the same solution, but using a different namespace, has access to this
class singleton that I'm trying to get a hold of.

Thanks everyone for the help. I do not believe the code is the
problem, but something else. All of the access specifiers, to what I
need to get access to, are public. I needed some ideas for where to
go, and they've been given.

Thanks again,
Andy

 

[Andrew Falanga]

No, you can't, which is where Andrew is confused. If they are part of
different DLLs then they are in different assemblies. There is only one
NAMESPACE, but there are multiple ASSEMBLIES. Remembers, an assembly is
ultimately a file, whether it be an EXE or a DLL. This is why I asked the
question in the first place, and I think the whole issue might simply be one
of needing project references between the two, like you suggested.

Jeff,

You're correct, and I'm posting this here mainly for anyone who might
search and find this thread. The problem is references. Also, thank
you for clarifying these differences for me. I knew that the projects
were built into different DLLs, thus assemblies, but I wasn't
connecting the next dot that this was the reason why I couldn't see in
that file (different project). I was thinking, since they're all part
of the same solution this should work. I was wrong.

So, now that I know the problem it's on to fix it. Unfortunately,
fixing it won't be as easy as adding a new reference. I tried that
and VS refused to do so because it made a circular dependency. LoL,
if it's not one thing, it's another.

Thanks again everyone,
Andy

 

[Peter Duniho]

[...]
So, now that I know the problem it's on to fix it. Unfortunately,
fixing it won't be as easy as adding a new reference. I tried that
and VS refused to do so because it made a circular dependency. LoL,
if it's not one thing, it's another.

A circular dependency generally means that you have some commonality
between two projects that really ought to be in a project of its own.
Then the other two projects can both reference that single common project.

Pete

 

[Chris Dunaway]

No, you can't, which is where Andrew is confused. If they are part of
different DLLs then they are in different assemblies. There is only one
NAMESPACE, but there are multiple ASSEMBLIES. Remembers, an assembly is
ultimately a file, whether it be an EXE or a DLL. This is why I asked the
question in the first place, and I think the whole issue might simply be one
of needing project references between the two, like you suggested.

Technically speaking, you can have a multi-file assembly (several
files make up a single assembly) but I don't think VS can do it.

http://msdn.microsoft.com/en-us/library/226t7yxe.aspx

I'm not sure if there is any benefit to a multifile assembly.

Chris

 

[Jeff Johnson]

Technically speaking, you can have a multi-file assembly (several
files make up a single assembly) but I don't think VS can do it.

I'm not sure if there is any benefit to a multifile assembly.

I didn't read the article, but if it's what I think it is I believe the main
reason for it was to be able to merge the output of multiple languages into
a single assembly. And no, Visual Studio can't do it; you have to use
command-line tools.

 

[Jeff Johnson]

I didn't read the article, but if it's what I think it is I believe the
main reason for it was to be able to merge the output of multiple
languages into a single assembly. And no, Visual Studio can't do it; you
have to use command-line tools.

Also, the ultimate output of the assembly linker is a SINGLE file, unless I
read incorrectly, so when it come to the final output, an assembly is still
one and only one file. I believe that's pretty much part of the .NET
definition of "assembly."

 

[Arne Vajhøj]

Technically speaking, you can have a multi-file assembly (several
files make up a single assembly) but I don't think VS can do it.

http://msdn.microsoft.com/en-us/library/226t7yxe.aspx

I'm not sure if there is any benefit to a multifile assembly.

Those "multifile assemblies" are still just one DLL - they
are just called multifile because they contain multiple modules.

Arne

 

[Arne Vajhøj]

I didn't read the article, but if it's what I think it is I believe the main
reason for it was to be able to merge the output of multiple languages into
a single assembly.
Yes.

And no, Visual Studio can't do it; you have to use
command-line tools.

But command line tools are an option. And an option used for
many large projects.

Arne

 

[Arne Vajhøj]

I completely understand, and appreciate, the struggle to help without
the actual code. I cannot post that here due to company
restrictions. Also, you wouldn't want to wade through it since it's
several thousand lines.

Unfortunately, I cannot post a working example, much beyond the
skeleton code already posted, because to do so would require that I
understood the problem. I do not.

You can almost always create an SSCCE.

Take the real code.

Delete all classes/methods/properties/fields not
necessary to reproduce the problem.

Delete everything in method bodies not necessary
to reproduce the problem.

Rename all names to neutral names.

Post it with build instructions and the error
you get.

Arne

 

[Chris Dunaway]

Also, the ultimate output of the assembly linker is a SINGLE file, unlessI
read incorrectly, so when it come to the final output, an assembly is still
one and only one file. I believe that's pretty much part of the .NET
definition of "assembly."

I'm not so sure I agree with this. Reading Jeffrey Richter's book
makes me think that an assembly can, in fact, span several files:

"The assembly file that contains the manifest also has an AssemblyRef
table in it. This table contains and entry for all the assemblies
referenced by all the assembly's files."

He goes on to show that 2 files can are created. One file has the
Assembly manifest in it and can be directly referenced. The other is
just IL which cannot be directly referenced.

He cites an example:

Two source files:

RUT.cs contains rarely used types.
FUT.cs contains frequently used types.

He compiles RUT.cs with this command:

csc /t:module RUT.cs

which produces a module file called RUT.netmodule

He compiles FUT.cs with this command:

csc /out:MyTypes.dll /t:library /addmodule:RUT.netmodule FUT.cs

This produces MyTypes.dll which contains the IL for FUT.cs but NOT the
IL for RUT.cs. But the assembly manifest includes the RUT.netmodule
public types.

If an app is written to use MyTypes.dll but never calls any methods
that reference any of the types in RUT.netmodule, then the RUT
netmodule doesn't have to be present.

--Taken from Applied Microsoft .Net Framework Programming, pp 49-52,
Jeffrey Richter.

Again, I don't know if there is any practical use for this, but it is,
in theory, possible.

Chris