Ok, so let’s break this down.
First, you need to distinguish between in-IDE resolve, which happens automatically on project load (and when needed) and build, which happens when you press “Build” or “Run”. The are completely separate processes, though both perform a reference resolve (and ideally, should succeed or fail in the same way).
The in-IDE resolve is what drives what yo see in the tree view. Essentially, the IDE goes thru the same steps as the build would to find the appropriate .dll/.jar/.fx files for your references, and it uses them to populate the in-IDE “compiler” that drives code completion & co.
Any reference for which the .dll/.jar/.fx file(s) cannot be found is considered a resolve failure, as essentially whatever types that reference is supposed to provide you won’t be available. As such, if you have a project reference, and the output of that project does not exist yet, that’s a failure, and you will see the yellow icon on the reference. After all, the IDE won’t be able to load that reference and add its types to CC, and the icon is there to (among other things) let you know why.
And yes, the same is true when you clean. The clean is deleting the .fx or .dll file for the project reference, so the reference is then “broken”, until you build again, and will show the error icon.
(the same logic applies to the build, except for the build, the missing project reference would of course be created in time, because the two projects would build in order (if enabled). In-IDE resolve does not do full builds, so of the reference isn’t there yet, it’s, well, not there.
As mentioned before, in-IDE resolve uses the same EBuild resolve task as the actual build uses, and it generates similar output you can look at to diagnose unexpected problems yourself. The output is very details and usually makes it clear what the problem is — but it needs to be looked at, of course.
You can see the resolve log by selecting the “References” node. You can also (new since ~2391), force a re-resolve by right-clicking the “References” node.
There’s four main differences between in-IDE resolve and the resolve phase during build:
(a) it runs separate for each project; not once for the entire solution. as a result, it is a bit less able to recover form bad/missing project references (but essentially, if the ProjectFile path is correct, it should be able to deal). The resolve log will e explicit about this.
(b) as mentioned before, it just runs the resolve (and tasks resolve depends on), but it doesn’t build anything.
(c ) It uses a separate “configuration”, so that the them “
obj” data created as part of a resolve doesn’t conflict with that created by the build. That’s why in “
obj” you’ll see Debug, Release and Fire folders.
(d) it uses the a native Cocos build of EBuild, while the actual build uses the .NET/Mono version in ebuild.exe. This generally should not make a difference, but s the root of the “file access” bug you saw a few weeks back, with the Carter reference.
One last note, there’s a small bug/oversight that I fixed yesterday that might affect what you see WRT project references, and that is after a (re)build, Fire did not automatically re-resolve references (as that was purely driven by file change notifications, and if the project reference was missing before, of course there was no file to monitor for changes). So after your first build, the yellow icon won’t go away on its own yet; until you re-resolve manually or reload the project. That’s fixed for next week.
Does that make sense?