From: Andrew Falanga on
On May 6, 2:02 pm, "Jeff Johnson" <i....(a)enough.spam> wrote:
> "Andrew Falanga" <af300...(a)gmail.com> wrote in message
>
> news:27c2f003-e291-45ee-9279-c5a308dd8dbc(a)o11g2000yqj.googlegroups.com...
>
> > 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
From: Arne Vajhøj on
On 06-05-2010 14:53, Andrew Falanga wrote:
> 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
From: Peter K on
"Andrew Falanga" <af300wsm(a)gmail.com> wrote in message
news:e20e03f6-d3e6-4e29-bb26-acdc7536606a(a)s29g2000yqd.googlegroups.com...
> On May 6, 2:02 pm, "Jeff Johnson" <i....(a)enough.spam> wrote:
>> "Andrew Falanga" <af300...(a)gmail.com> wrote in message
>>
>> news:27c2f003-e291-45ee-9279-c5a308dd8dbc(a)o11g2000yqj.googlegroups.com...
>>
>> > 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.

Do you references between the projects?

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



From: Peter Duniho on
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
From: Jeff Johnson on
"Peter K" <peter(a)parcelvej.dk> wrote in message
news:OcTU3jZ7KHA.420(a)TK2MSFTNGP02.phx.gbl...

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