I have a web application in Visual Studio 2008 with a web service and a couple web forms. When I try to debug, none of my breakpoints are available; if I mouse over them, I see:
"The breakpoint will not be hit. The source code is different than the original version."
The list of loaded debug modules includes the old version 1.0.* of my assembly. I have since changed it to 1.1.0.0 but that version never gets loaded. I tried stopping IIS and deleting the files out of Temporary ASP.NET Files, but when I restart it the 1.0.* version comes right bac开发者_开发知识库k! The build output is definitely 1.1.0.0 and not 1.0.*, so where can it possibly be coming from? The same thing happens when I use the VS Development Server instead of IIS.
Thanks
I've seen this happen when the DLL is cached in the Temporary ASP.NET Files folder. Try doing a "Rebuild All", and if it's still happening remove the DLL from the temp folder, or clear the folder contents altogether.
I had a very similar problem:
- Web application referencing assembly containing resources.
- When using non-default culture (one with resources build into satellite *.resources.dll assembly), some of the resources were used ok but some falling back to default languagage.
- Deleting Temp ASP.NET files or Clear\Build didnt help
Problem is that most of the tools you can use for diag assembly loading problems (Process Explorer for list of loaded assemblies and paths, fuslogvw for assembly binding log) don't show satellite assemblies at all.
But finally i found that there is old version of the satellite assembly right in my web app bin folder (still dont know how it get there) and it was getting priority during assembly probing\loading...
It looks like this is triggered when a files LastWriteTime does not update. I can reliably reproduce this by taking two completely separate builds of a dll, with the exact same LastWriteTime, and deploying them into IIS one after another. If I then use GNU touch to update the files LastWriteTime, IIS picks up the current correct version.
精彩评论