A public class is not visible in the namespace ... why
in [CSharp]
|
From: Andrew Falanga on 7 May 2010 09:46 On May 6, 10:21 pm, Peter Duniho <no.peted.s...(a)no.nwlink.spam.com> wrote: > 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 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
From: Andrew Falanga on 7 May 2010 11:12 On May 7, 7:35 am, "Jeff Johnson" <i....(a)enough.spam> wrote: > "Peter K" <pe...(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. 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
From: Peter Duniho on 7 May 2010 11:41 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
From: Chris Dunaway on 7 May 2010 12:41 On May 7, 8:35 am, "Jeff Johnson" <i....(a)enough.spam> wrote: > "Peter K" <pe...(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. 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
From: Jeff Johnson on 7 May 2010 13:39 "Chris Dunaway" <dunawayc(a)gmail.com> wrote in message news:78a826db-98dc-4ac0-bc86-03f55dfa2acb(a)n15g2000yqf.googlegroups.com... > 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. 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.
First
|
Prev
|
Next
|
Last
Pages: 1 2 3 4 5 Prev: Create and sort on XML File Next: SQL Job, Impersonation and Process.Start |