Where does Visual Studio look for assemblies?

Question

I've got a framework which consists of many base classes that can be derived to develop many apps. Among these classes there is a subclass of System.Windows.Forms.Panel for which I wrote its own designer. Everything is working fine with Visual Studio 2005, but something goes wrong when I try to move to VS2010. This is a much simplified version of what I am doing:

I have a project called CoreClasse which contains an interface and two classes:

public interface IConf
{
    string foo { get; set; }
    void InitFoo();
}

public class SimpleClass
{
    public string foo;
}

public class ConfLoader
{
    public static IConf LoadConf()
    {
        AssemblyName anAssemblyName = new AssemblyName("ConfClasses");
        Assembly anAssembly = Assembly.Load(anAssemblyName);
        IConf result = (IConf)anAssembly.CreateInstance("ConfClasses.ConfClass");
        result.InitFoo();
        return result;
    }
}

Then there is a project ConfClasses which references CoreClasses and contains just one class implementing IConf:

public class ConfClass : IConf
{
    public SimpleClass confVal;

    public string foo
    {
        get { return confVal.foo; }
        set { confVal.foo = value; }
    }

    public void InitFoo()
    {
        confVal = new SimpleClass();
        confVal.foo = "bar";
    }
}

And finally there is a project for the controls which references only CoreClasses and contains a subclass of Panel and the associated designer:

[Designer("MyControls.Design.SimplePanelDesigner", typeof(IRootDesigner))]
public class SimplePanel : Panel
{
    public SimpleClass dummy = new SimpleClass();
}

public class SimplePanelDesigner : DocumentDesigner
{
    public IConf DesignerConf;

    public SimplePanelDesigner()
        : base()
    {
        DesignerConf = ConfLoader.LoadConf();
    }
}

Now I create another solution which references all these dlls and contains an empty subclass of SimplePanel. When I double click on this class in SolutionExplorer the constructor of SimplePanelDesigner is executed and the method LoadConf of ConfLoader is called. This means that ConfClasses.dll is loaded dinamically and an instance of ConfClass is created. Everything is fine up to this moment, but when InitFoo is called this exception is raised:

Could not load file or assembly 'CoreClasses, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified.

To make things harder, the exception is not actually raisedin this example, but this is exactly the kind of istructions my real app is executing, and the exception I am getting. I haven't got a clue of what's happening here. VS is executing a method which IS in CoreClasses. Why is it trying to load it again? And where is it looking for it? I checked the current AppDomain, too, but it has CoreClasses among its loaded assemblies, and it does not seem to change.

Just to add some more details, every project is build in a common folder (not the usual obj/debug folder inside the project folder), and there is no other copy of my dlls on the PC at the moment I start my test. Then a copy of all the referenced dlls is done in a series of folders in the AppData\Local\Microsoft\VisualStudio\10.0\ProjectAssemblies folder of my userprofile, and this seems to be the place VS is looking for the assemblies when Assembly.Load is executed, and I can find a copy of CoreClasses there. I tried to clean all the folders, to rebuild everything, and to keep the different solutions opened/closed in every combination, but without any improvement.

EDIT:

As GranMasterFlush suggested, this is the FusionLog generated by the exception:

=== Pre-bind state information ===
LOG: User = FCDB\fc0107
LOG: DisplayName = XEngine.Core, Version=1.0.0.1, Culture=neutral, PublicKeyToken=null (Fully-specified)
LOG: Appbase = file:///C:/Program Files (x86)/Microsoft Visual Studio 10.0/Common7/IDE/
LOG: Initial PrivatePath = NULL
Calling assembly : (Unknown).
===
LOG: This bind starts in default load context.
LOG: Using application configuration file: C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\devenv.exe.Config
LOG: Using host configuration file: 
LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework\v4.0.30319\config\machine.config.
LOG: Policy not being applied to reference at this time (private, custom, partial, or location-based assembly bind).
LOG: The same bind was seen before, and was failed with hr = 0x80070002.
ERR: Unrecoverable error occurred during pre-download check (hr = 0x80070002).

EDIT 2

Just to add some info, I took a look at the fusion logs generated by my simple example and found out that exactly the same log has been generated while trying to load CoreClasses, but someway VisualStudio finds a way to cope with it.

Answer 1

I've just found out what's happening. The difference between the simple example and the real thing is the fact that there is an AddIn involved. It's quite a log story, but this is it.
As you can see from the code sample, I load the ConfClasses dll via reflection in order to avoid to add a reference to it. This is fine at runtime, but the designer complains saying that it's not able to cast IConf to IConf. This happens because CoreClasses.dll is loaded from AppData\Local\Microsoft\VisualStudio\10.0\ProjectAssemblies when the designer starts, but ConfClasses.dll is loaded from my bin folder and so are its references, so there are two versions of CoreClasses.dll and different versions of IConf.
To bypass the problem I developed an AddIn that, when an assembly is loaded with Assembly.Load at design time, adds a reference to that assembly, and then cleans the references when the last designer window is closed.
Everything was OK with VS2005, but using ProcMon.exe I found out that VS2010 added a new folder where the addins look for assemblies: Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\CommonExtensions\DataDesign
I copied my assembly there and everything works again. Now it's only a matter of finding a way to add things there manually.