The type or namespace name 'blah' does not exist in the class or namespace 'abc.def'

[WineNCheese]

Hi all,

I have a seemingly simple but strange problem: In an exe assembly, I get
the error above (CS0234) when I build my solution the first time. The
assembly that defines the namespace (abc.def.blah) is correctly referenced,
and the build order is correct. The compile error occurs on a using
statement on the first build (and on subsequent builds if I don't do a
complete rebuild). If I do a second rebuild the error goes away. Also, I
reference and use the assembly that defines that namespace in many other
assemblies (both dll and exe), and they compile just fine in all cases.
Copy Local is set to true, and when the error occurs, the assembly in
question is definitely where it is supposed to be. Any idea what this could
be?

TIA

WNC

 

[recoil]

Logic dictates that obviously one assembly that is being relied upon is
not being built. The Rebuild builds it and puts it where it is needed.
Have you tried looking at the Output. Sometimes while the Task List
window will only show one error the Output window will show more errors
and more detailed information. When this error happens go to the View
-> Other Windows -> Output and scroll all the way up and down carefully
investigating for any informative errors or details that may better
describe what is gong on behind the scenes.

 

[WineNCheese]

*grin*

Logic doesn't seem to have much to do with this one. The assembly is being
built just fine. As proof, there are other assemblies that get built before
the exe assembly which reference and use the rogue assembly, and they build
just fine. That is why I am baffled.

However, I have new information. I had changed my output directory for the
solution to ../bin/debug instead of the default bin/debug. If I undo this
change, the build works fine. Even more baffling. I am going to attempt
to reproduce this in a new solution environment, as I think this is a bug...

WNC

 

[WineNCheese]

OK, I've gotten further. Here's the findings. I'd be really happy if
someone from MS who knows the internals of how the IDE does its builds and
rebuilds could explain this to me (a peek inside the black box)...

1. I've found out that when you build a project in a solution, all other
projects that reference that project (with Copy Local set to true) get a
copy in their output directory at the time the referenced project is built.
So if projectB references projectA, when projectA is built, a copy of the
dll is placed in projectB's output directory. This is important for me
because I have two exe projects in my solution that have been set to have
the same output directory.

2. If I build the solution in a clean environment from the IDE, the build
error occurs. On a complete rebuild, the build error does not occur. If I
change the output directory for the exe project to anywhere but the shared
location, there are no problems.

3. If I build the solution in a clean environment from the command line, the
build error does not occur (everything works fine).

4. If I build the solution in a clean environment from the IDE, and use
'filemon' to monitor the assembly in question in the shared output
directory, when the build fails, filemon reports a couple of "SHARING
VIOLATIONS". A rebuild does not result in any of these violations.

So, it seems that something in the ide has an exclusive lock on the shared
assembly in the shared output directory, which is correctly unlocked on a
rebuild. Could this be the dreaded intellisense? I tried to reproduce
this with simple empty projects, and the problem did not occur, which I was
suprised about.

Therefore, I guess I will bend to convention and have a separate folder for
each exe. I will start another thread on this, because I have questions on
it...

WNC