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

Andrew Falanga wrote:
[..]
>
> 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?
[..]

On 5/6/2010 2:53 PM, Andrew Falanga wrote:
[..]
> 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?

>
> 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?
>
> >       ClassInFile2() {
> >          SingletonClass.Instance().<call_some_method>;
> >       }
> >    }
> > }

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

Andy

"Andrew Falanga" <af300wsm> wrote in message
news:8dbc

> 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?

On May 6, 2:02 pm, "Jeff Johnson" <i> wrote:
> "Andrew Falanga" <af300> wrote in message
>
> news:8dbc
>
> > 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?

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

On 06-05-2010 14:53, Andrew Falanga wrote:
[..]
>
> 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

"Andrew Falanga" <af300wsm> wrote in message
news:606a
> On May 6, 2:02 pm, "Jeff Johnson" <i> wrote:
>
> 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?

Andrew Falanga wrote:
> [...]
> 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

"Peter K" <peter> wrote in message
news:a420

>
> 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.

On May 6, 10:21 pm, Peter Duniho <nopeteds>
wrote:
> Andrew Falanga wrote:
>
> 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

On May 7, 7:35 am, "Jeff Johnson" <i> wrote:
> "Peter K" <pe> wrote in message
>
> news:a420
>>
>>
>> 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

Andrew Falanga wrote:
> [...]
> 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

On May 7, 8:35 am, "Jeff Johnson" <i> wrote:
> "Peter K" <pe> wrote in message
>
> news:a420
>>
>>
>> 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

"Chris Dunaway" <dunawayc> wrote in message
news:2acb

> 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.