I’m guessing this is a Visual Studio problem, but thought I’d ask in case someone can help me out. For the past couple of days, I see that the final compiled target of my Silverlight app is pulling in some old version of a dll. I don’t even know where it is getting it. But the pdb and assembly are not correct. The pdb is correct and the assembly is wrong. I can see because the date on the pdb is today and the assembly is from over a week ago. When I look in the project, they match, but the final web site application folder bin ends up with the mismatch.
I can’t debug while this is happening. I have no idea where it is finding this old one, nor even why it SHOULD find it. I cleaned out the asp.net temporary folders, but that didn’t seem to help.
Any clues?
oh, I tried, solution clean, and rebuild to no avail. Tried putting the desired assembly in the target folder just to watch it be replaced. Tried removing all references to that project and adding it back in. Have been searching the entire hard disk all day and so far haven’t turned up the source of the old one.
and… During the build of the solution, I can see it put the right thing in the target folder as it is working its way through the projects. Then at the very end, I see it get replaced with the old one. Also, none of the projects’ folders contain this old version of the dll.
Looking in the modules windows I see there are 2 others that are also “mismatched”.
After the compile, I had the debugger stop in the client code. Then I copied the good dll and pdb to the target folder. Then continued the program. The breakpoint was hit. But it is a nuisance to do this every time I need to recompile and test.
I finally figured this one out by searching the entire hard disk for that old version. It turned up in a folder of files that my co-worker gives me. Each of us is using parts of the others assemblies to make the final application. So, I give her my parts and she gave me all of hers (which included an old version of a few of my assemblies). Although my solution does not REFERENCE that old file from her folder at all, the build process was compiling mine, and then at the last second, replacing it with hers. So then it had MY pdb and her old assembly. I deleted my assemblies from her folder and now it finally compiles and runs okay again.
I don’t know if the problem was that HER assembly was referencing the one in that folder or what, but now that I deleted mine from her folder, it all works. I find it odd that it would suck in her version of the file when it already had MY version of the file. oh well.
IIRC VS maintains a list of folders to look in for Debug Symbols. Maybe you browsed for it earlier, and VS kept that folder in its list, but now when yu were running your own build, it still looked for the PDB in the old folder.
The problem was sort of the other way around, the PDB was actually the right one. But the build was copying the old assembly into the target. That was causing the mismatch.
That was part of what was confusing the heck out of me about this problem. WHY was it replacing the assembly with the old one. I could watch the target bin folder and see both assembly and pdb put there with the correct ones during the compile and then suddenly, at the end of the build, it would replace the assembly with the old one.
The replacement seemed to be happening when the final target bin for the “.web” part of the solution was built.
On thinking about it a bit more, I’m thinking that VS just gets a list of directories where it searches for files and if it HAPPENS to find a file that is in the references in multiples of those directories, it just choses the first one it comes to. Just guessing.