Related
This question is about why an assembly cannot find a library that resides in the same folder. As far as I can tell, the bitness of the caller (x64) agrees with the unfindable NuGet package (AnyCPU).
Even when I recompile everything to AnyCPU, the error message remains:
Could not load file or assembly 'ChoETL.Core, Version=1.2.1.28, etc.' The system cannot find the file specified.
My published NET 5 exe (x64) file calls a published NET 5 library that calls the Nuget package ChoETL.Core in the error message (exe->lib->ChoETL.Core).
Here is the command line that I used to build the program exe and intermediate library .csproj files. I do not use Visual Studio and do not use the solution .sln file. All files build without errors or warnings.
msbuild -t:restore;publish /p:Platform=x64 /p:PlatformTarget=x64 /p:Configuration=Debug /p:TargetFramework=net5.0-windows7.0 /p:RuntimeIdentifier=win-x64 /p:PublishDir=c:\dev\holding\core.plt xxx.csproj
Here is the reference in the .csproj file of the library that references the ChoETL.Core package. Keep in mind that the msbuild command line properties override the AnyCPU values in the csproj file below.
<PropertyGroup>
<UseWindowsForms>true</UseWindowsForms>
<Platforms>AnyCPU</Platforms>
<PlatformTarget>AnyCPU</PlatformTarget>
<TargetFramework>net5.0-windows7.0</TargetFramework>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="ChoETL" Version="1.2.1.28" />
</ItemGroup>
I thought maybe the CorFlags values might be the issue, so I checked them. There were as follows (32bitreq/prefs were zero):
Program.exe: PE32+, flags 0x9, ILONLY 1, Signed 1
Library.dll: PE32+, flags 0x9, ILONLY 1, Signed 1
ChoETL.Core: PE32, flags 0x1, ILONLY 1, Signed 0
PE32+ means x64, and PE32 means AnyCPU (if the assembly is loaded into a 64 process, it runs as a 64-bit assembly). So, they should be compatible (and besides, I cannot compile the NuGet package).
I looked at this SO question, but it did not help.
Could not load file or assembly, system could not find the file specified
Does anyone have any idea why the library cannot find the ChoETL.Core.dll library when all three assemblies are side by side in the same folder?
I've spent days on the problem without progress or success. Thank you.
After yet another day of debugging, I have things working, but I don't know exactly why. I started with a simple console program, then exe + lib, then exe + lib (that called ChoETL), and finally made a test case with part of my real system. By the time I got to experiments with part of the real system, things were working okay. But fragile, I imagine.
Here are some theories that might help the next person.
One key issue (in the real system that was failing) was that the ChoETL package was not being published by the msbuild ... -t:clean;restore;publish operation. I think this was a major part of the problem. Yet, as I built up my test experiments using the same msbuild command lines, ChoETL was always being published correctly beside the executables and libraries that consumed the package.
At that time, I recognized that my experiments always completely deleted the bin and obj folders before starting a new build, whereas my real system build files did not take that drastic action (thinking that msbuild clean/restore would be sufficient for a clean build). But, not so. Msbuild is not that smart. I modified my real-system build files to completely delete all obj/bin folders in the 70-project build sequence at the start of the build, and ChoETL was correctly published beside the assemblies that consumed it.
And at last, the original problem was solved (but not really understood). The system could find ChoETL and load it. All I know is that completely deleting the obj and bin folders at the start enabled a successful build. I do not have a clear idea of what file(s) or data elements in the obj/bin folders might have prevented a successful publish operation. Maybe it was the project.assets.json file, or maybe it was one of the other json files.
I do know that msbuild does not easily regenerate the json files when csproj files and msbuild command line properties are changed. I have developed the habit of completely deleting the obj/bin folders in the months since starting to work with NET 5 because of such problems.
I thought msbuild would do dependency and timestamp analysis like make does, and regenerate the json files if they were "out of date" (whatever that might mean in this context; I don't know). But it does not. Thus I have started to develop the habit of completely deleting the obj/bin folders before a build. Obviously, this experience (a development delay of weeks) shows that I still have much further to go with developing that into a rigid habit. I hope this answer might help someone else.
I migrated a visual studio solution from using a "website" to a "ASP.net project" to be able to use Web.config transformation.
Now, after having migrated, Visual Studio completely ignores syntax erros when I clean/build/rebuild my solution.
Those syntax errors will be shown in my browser as soon as I open the web application - but seeing them during compile time would be helpful. They used to be shown in my error list - where I can now only see some uninteresting warnings.
I can still run my web application, and everything works well.
How can I configure my solution, so that compile errors will appear during compile time?
edit (in response to answers/comments):
As soon as I open the .cs file (by double clicking on it) the syntax errors are shown (inside the file and inside the error list view).
I'm using Microsoft Visual Studio Professional 2012 (Version 11.0.61030.00 Update 4) with .NET 4.5.50709 (german language version). I'm locally deploying to Visual Studio's IIS.
I'm not using NuGet, all my sources are in one single project
I'm actually only providing a REST-Backend using WCF. I only have c# sources. The syntax errors are in my c# classes.
The syntax errors are in my .cs files in my App_Code folder.
When I migrated my website to a project I manually edited my .csproj file (added missing "Content Include"s etc.). I hope that this did not break my solution...
I am not using the default "DEBUG" and "RELEASE" build configurations, but created my own server-specific configurations (named after the names of each server).
( #Guvante ) When I edit the build configurations, I see one line in the "project context table". The first and only line shows:
the name of my project
the configuration name in a dropdown
the plattform "Any CPU"
a checked checkmark "build"
the empty field "deploy"
My error list is filtered to "current project" and it won't show the syntax errors, no matter which item I select in my solution explorer.
Sometimes (can't tell when exactly) VS shows a warning, when starting debugging, telling my that my module was build with optimizations or without debugging information. Don't know, whether this warning is related to this issue.
Console output of successful build (though sources contain syntax error) is:
1>------ Erstellen gestartet: Projekt: MyProject, Konfiguration: localdev Any CPU ------
1> MyProject -> C:\path\MyProject\bin\MyProject.dll
========== Erstellen: 1 erfolgreich, 0 fehlerhaft, 0 aktuell, 0 übersprungen ==========
I saved, closed VS, rebooted machine, reopened VS, closed eyes, crossed fingers - #chief-two-pencils ;)
In the .csproj file you can change
<Content Include="C:\...\foo.cs" />
back to
<Compile Include="C:\...\foo.cs" />
More info on the MSDN documentation and this stackoverflow question.
You should change it to:
<Compile Include="....." />
The MSDN article on the build action property says:
Compile - The file is compiled into the build output. This setting is used for code files.
Content - The file is not compiled, but is included in the Content output group. For example, this setting is the default value for an .htm or other kind of Web file. Means that it is a deployable project item, it signals that the file needs to be copied to the target machine. Also note that Content will be included when using one-click deploy.
See more about build action here.
if you have Nuget packages run an update-package
try to unload the project and reload it into the solution
This worked for me
I need to build some application in two configurations: x86 and x64 (each config has reference on some dll, which is in 32 and 64 bit versions).
I want to build in some time(one build) and as result i want to have two folders,i.e.:
1) sln_dir/x86/
2) sln_dir/x64/
Also x86 contains 32 bit dll and x64 contains 64 bit dll.
Is it possible?And if it is possible how?
Thanks!
Well, I'd add new project configurations, and set the build type for each configuration, along with the output directory. So you might have "Debug x86" and "Debug x64" project configurations, with output directories of "bin\DebugX86" and "bin\DebugX64" for example.
That's a change that can even be done within Visual Studio, unlike most of the project file hacks I perpetrate :)
That won't build configurations with a single "build project" button press, but:
You could add a post-build step for one configuration to build the other
If this is only relevant when you build the Wix installer, I'd just script the building of that to first build both configurations
Another Visual Studio feature you should look at is the "Batch Build" option. Unfortunately it doesn't look like there's a way of saving a batch build to perform it multiple times easily :(
You can:
1) Create 2 different projects with different target CPU architecture and build solution.
Solution
ProjectA x86
ProjectB x64
Build solution. Both projects are pointing to the same source code files, naturally. There is no any source copy.
2) You can create external batch build with code like (example)
"C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\devenv.exe"
"PATH TO SOLUTION" /Rebuild "CONFIG NAME"
Where
"PATH TO SOLUTION" is a path to your solution file
"CONFIG NAME" is a configuration name, like Release86 or Relese64.
Write there code for every confifguration you need (those configuration have to be already configured in visual studio before). And just run that batch ones.
So, as the title reads, I have a VS2010 solution with ~50 projects in it right now. If I make a change to a "top level" project that nothing references then VS still rebuilds all 50 projects. I'm running Visual Studio 2010 Ultimate without any add-ons. I am using ILMerge to consolidate all of the projects into a single file.
I have verified this by checking the time stamps of the lower level dlls and see that they are indeed rebuilt even though their code wasn't touched.
I've read all responses and comments for:
Visual Studio 2008 keeps rebuilding
Visual studio keeps building everything
Strange VS2010 build glitch occurs in my solution
Reasons for C# projects to rebuild in Visual Studio
But most of them just offer suggestions on unloading projects to speed up build times but nothing concrete as to a fix. I'm trying to figure out why VS thinks these dependent projects need to be rebuilt when they don't and fix it.
I've turned on 'Tools > Options > Projects and Solutions > Build and Run > Only build startup projects and dependencies on run' but with no effect.
Also, if I just rebuild a "mid-level" project that only has 8 (in)direct dependencies then it still builds all 8 projects even though ILMerge isn't invoked and none of the dependent projects have been modified.
Thank you everyone for any insight you may be able to provide.
Added
To test some of the suggestions I created a new WinForms project from scratch. I then created two new projects inside that solution. I copied all of the code and resources (not project file) from my two 'lowest level' projects into the two brand new projects (I did this by dropping the files and folders from Explorer onto the project in Visual Studio).
The lowest project, let's call it B, did not reference any other project. The next project, A, referenced B only. So once I added the required .NET and external assembly references to the projects then the solution would build.
I then had my new WinForm project reference A and did a full build. So the ref chain is:
WinForm -> A -> B
I then modified WinForm only and did a standard build (F6). As before, Visual Studio rebuilt all three projects.
After some systematic eleminiation of source files in project B I found that if I removed my Resources.Designer.cs and Resources.resx (and commented out the code that made use of the .Properties.Resources object of those resources) then a modification of WinForm would no longer rebuild the entire solution and would only rebuild WinForm.
Adding the Resources.resx and Resources.Designer.cs back to project B (but leaving the referenced code commented out so that nothing was making use of the resources) would re-introduce the full build behavior.
To see if perhaps my resource files were corrupted, I deleted them again and then created a new one (via Project Properties -> Resources) and re-added the same resource as before, which was a single Excel file. With this setup the full rebuild would still occur.
I then removed the single resource, but left the resource file in project B. Even with no resources added, but the resource file still in the project, the full (unneeded) rebuild would occur.
It appears that just having a resource file added to a (.NET 3.5) project will cause Visual Studio 2010 to always rebuild that project. Is this a bug or intended/expected behavior?
Thanks all again!
Open Tools - Options, select Projects and Solutions - Build and Run in tree, then set "MSBuild project build output verbosity" to Diagnostic.
This will output the reason for building a project, i.e.
Project 'ReferencedProject' is not up to date. Project item
'c:\some.xml' has 'Copy to Output Directory' attribute set to 'Copy
always'.
or
Project 'MyProject' is not up to date. Input file
'c:\ReferencedProject.dll' is modified after output file
'c:\MyProject.pdb'.
In this case the fix is to copy some.xml only if newer.
Pre and post build events can trigger build as well.
While I don't think this is a fix, it is a workaround that has worked for my situation...
I originally had about 5 projects out of 50 that contained a Resources section. These projects would always be rebuilt and thus anything that they depended on would also be rebuilt. One of those 5 projects was a "base" level library that 48 of the other projects referenced, thus 96% of my project would be rebuilt every time even if it didn't need it.
My workaround was to use dependency injection, interfaces, and a dedicated "Resources" project. Instead of having those 5 projects reference their own Resources object, I created an interface in each project that would supply the desired resources. Then, the classes that needed those resources would require that interface be passed in during their creation in the constructor (constructor injection).
I then created a separate "Resources" project that had an actual Resources section like normal. This project only contained the resources themselves, and a class for each interface that was needed to provide those resources via an interface. This project would reference every other project that had a resource dependency and implement the interface that the project needed.
Finally, in my "Top Level" project which nothing referenced (and where the exe was actually built and my composition root lives) I referenced the "Resources" project, wired up the DI, and away we went.
This means that only two projects (the "Resources" and the "Top Level") will be rebuilt every time, and if I do a partial build (Shift-F6) then they won't get rebuilt at all.
Again, not a great work around, but with 48 projects being built every time a build would take about 3 minutes, so I was losing 30 to 90 minutes a day with needless rebuilds. It took awhile to refactor, but I think it was a good investment.
Here is a simplified diagram. Note that the dependencies from Main.exe to Proj1 and Proj2 are not shown in order to reduce clutter.
With this design, I can do a build of Proj1 or Proj2 without triggering a full rebuild, since they don't have any dependencies on a Resources section. Only Main knows about the Resources implementation.
This happens when a project has a file that doesn't really exist.
The project can't determine if the file was changed (because it's not there) so it rebuilds.
Simply look at all the files in the project, and search for the one that doesn't have an expandable arrow near it.
I had the same issue in VS 2015.
What did the trick for me is:
One project was referencing itself copy in some other project bin (magic, yes). This kind of stuff could be found when switching to diagnostic build output (in build options) and then trying to build projects one by one from the top of projects hierarchy - if you see the project that rebuilds even if nothing has been changed then see it's references.
I've changed all "copy always" files in all projects to "copy if newer". Basically, in all .csproj files replace <CopyToOutputDirectory>Always</CopyToOutputDirectory>
to <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
Then I've disabled NTFS tunneling as described in this article with this powershell script:
New-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem" -Name "MaximumTunnelEntries" -Value 0 -PropertyType "DWord"
After that I needed on rebuild and it seems working for now.
In my case the culprit was "Copy Local" setting of a referenced dll set to true and "Copy to Output Directory" setting a file set to Copy always.
For .Net Core Projects, all solutions above are not working.
I've found the solution. In case you are using Visual Studio 2019:
Build the solution twice
Turn on Tools -> Options -> Projects and Solutions -> SDK-Style Projects -> Logging Level -> Verbose
Clear the output window
Build your start project
Inspect the output window. All the string starting with FastUpToDate
You will find some project items that are making your project not up to date.
Fix these issues and try again from step 1. If your fixes are correct, you will achieve Build: 0 succeeded, 0 failed, {n} up-to-date, 0 skipped in the last string of build output.
The MSBuild team is collecting documentation about investigating build incrementality issues here:
https://github.com/Microsoft/MSBuild/wiki/Rebuilding%20when%20nothing%20changed
UPDATED LINK: https://github.com/dotnet/msbuild/blob/main/documentation/wiki/Rebuilding-when-nothing-changed.md
Based on your observations, it sounds like you have projects expressing dependencies to other projects in a way that isn't obvious. It is possible for orphaned dependencies to remain in project files without being apparent in the UI. Have you looked through a misbehaving project file after opening it in a text editor? Checked solution build dependencies?
If you're not able to spot anything, try recreating one of your projects from scratch to see if the new project exhibits the same problem. If the clean project builds correctly, you'll know that you have unwanted dependencies expressed somewhere. As far as I know, these would have to be in the project file(s) or the solution file, unless you have makefiles or other unusual build steps.
Another problem that frequently happens is when some item in your solution has a modified stamp that is in the future. This can happen if you set your clock forward, and then set your clock to the correct time. I had this happen while installing Linux.
In this case you can recursively touch all the files using git bash (yes, in Windows):
find . -exec touch {} \;
I've finally found one more culprit that I had hard time finding by increasing the build log verbosity.
In some cases, MSBuild looks for vc120.pdb in the output folder, and if this file doesn't exist, it will rebuild the entire project. This occurs even if you have disabled debug symbol generation.
The workaround here is to enable debug symbols and let this file get generated, then disable the setting again without deleting the PDB file.
I had this same problem and it turned out to be related to a couple of project that had a copy local reference to a dll in their own output directory.
The key to finding this was having diagnostic output set for the build output, but also knowing what to look for in the log. Searching for: 'not up to date' was the key.
Here is an answer from VS2010 always rebuilds solution?
This issue is solved by changing the project files, cleaning solution,
deleting all bin folders by hand, restarting Visual studio and
rebuilding everything.
I had the same issues with you.
I found that it came from some deleted files.
When I had removed the files from my project, the issues was gone.
Regards.
For this category of build problems setting MSBuild output verbosity to 'diagnostic' is indeed a necessary first step. Most of the time the stated reason for the re-builds would be enough to act upon, BUT occasionally MSBuild would erroneously claim that some files are modified and need to be copied.
If that is the case, you'd need to either disable NTFS tunneling or duplicate your output folder to a new location. Here it is in more words.
I had the problem of Visual Studio rebuilding projects when upgrading from Visual Studio 2015 to 2017 and I add this answer for the benefit of those who might experience similar problems, as it does not seem to be documented anywhere.
In my case, the problem was that all projects in the solution had the same intermediate Output path (obj). The file GeneratedInternalTypeHelper.cs gets generated by all projects containing XAML. Up to Visual Studio 2015, the build process apparently did not check for the file date of this file and thus no problem with it occurred. With VS2017 the file date of this file is checked and because a later project in the build process will overwrite it (with the same content), the earlier project will re-build, re-triggering the later build, ad infinitum.
The solution in this case is to ensure that all projects have differing intermediate output directories, which will make the problem go away.
In my case (mixed C#, C++/CLI and native C++ solution) , some C++ projects were being re-linked even if nothing had changed. I spent ages trying to work out what was happening. In the end I worked out from the "Command Line" option that the PDB output path (option /Fd) could not handle the folder setting $(IntDir). I removed that - an empty value will do the default correctly - and my issue went away.
As others have noticed, a likely reason is that CopyToOutputDirectory is set to Always. This can be fixed simultaneously in all project files by applying the powershell script below:
$folder = "C:\My\Solution\Folder"
$csvFiles = Get-ChildItem $folder *.csproj -rec
foreach ($file in $csvFiles)
{
(Get-Content $file.PSPath -Encoding UTF8 -Raw) |
Foreach-Object { $_ -replace "<CopyToOutputDirectory>Always</CopyToOutputDirectory>", "<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>" } |
Set-Content $file.PSPath -Encoding UTF8 -NoNewline
}
Files that do not exist are a problem and obviously files producing no output as well. That can happen, wenn you have a resource file in a static library. (C++)
I want to use debug symbols, but I am receiving the following error:
a matching symbol file was not found in this folder
What is this problem, and how to solve it?
One of the things I've ran into with was because debug was off on the project referenced where the code lives. In my case, I made a new configuration called "Developer" and by default debug was turned off.
Right click the project in question
Properties
Build
Advanced (right bottom corner)
Set Debug Info to full
Recompile
I had the same problem as #DmainEvent. Apparently the dll that I was using was not the same version as the pdb that I had just compiled, so I got the error message.
If you have this problem, try using the dll and pdb from the same compilation run.
The error I got was "a matching symbol file was not found in this folder" in the Debug => Modules window even after both the DLL and PDB were available and built together, so I was unable to debug into the target DLL referenced by my main project.
Posting this here in case it helps someone browsing with "Mixed Platform" build for target DLL. I did two things to get past this:
In the solution using the target DLL, Uncheck "Just My Code" in Tools => Options => Debugging => General => Enable Just My Code (JMC).
Check "Enable native code debugging" in target DLL solution in relevant Project Properties => Debug.
I tried all the possible solutions, finally it worked when I disabled the option Enable native code debugging under the Debugger engines of Properties > Debug.
I ran into this problem and the answer was simple.
Visual studio has two project level settings that can create .pdb files.
Linker: Configuration Properties -> Linker -> Debugging -> Generate
Program Database File = "xxxx.pdb"
Compiler: Configuration Properties -> C/C++ -> Output Files -> Program Database File Name =
"yyyy.pdb"
You want #1 for debugging. Forget about #2.
Give file #2 a different name than file #1 to solve this error.
I don't know why microsoft specifies #2 as a .pdb file. That is just confusing.
I have fixed my debug symbols, forcing them to match using this tool:
chkmatch tool
edit: the website is down now. the wayback machine helps: https://web.archive.org/web/20210205095232/https://www.debuginfo.com/tools/chkmatch.html
So, my problem was I was trying to debug my project and the debugger couldn't step-in to the in-house nugets sources. I had the source files of the nuget project. Still the visual studio didn't accept the pdb files I was trying to show it to.
Showing exact same error:
a matching symbol file was not found in this folder
So, what I did was I added this to the .proj file of the nugets project:
<DebugType>full</DebugType>
And created the dll and pdb file again using the rebuild option.
In the command line I ran:
.\ChkMatch.exe -m name_of_your.dll name_of_your.pdb
It said this:
Writing to the debug information file...
Result: Success.
Great success!
So, next, I referenced this dll instead to the proj I was trying to debug. I worked when I tried to load the symbol again.
Hope it helps.
Without more details as to what you're doing, it's difficult to go beyond "the debugger is looking for a symbol file which matches the compiled code, and couldn't find one in the folder where the compiled code lives."
Some things to think about:
Are you creating symbols as part of your compilation? (check the project properties)
Are you using a symbol server (if so, does it point to the right place)
Is this compiled code from a third party? In which case, as you apparently have the source, compile it yourself.
Consider clarifying your question if you want a better answer. Especially what do you mean by "I want use of Symbols".
For BizTalk (and other) projects, it could be because there's a version of the assembly you're trying to debug already in the GAC. When you run a unit test or hit F5 to debug, a new version is compiled locally. However, the version in the GAC is being used, and the newly created PDB doesn't match the DLL in the GAC.
One way around this is to deselect a build for everything except your unit test project using the Configuration Manager, as shown below:
Well, the solution depends on your specific problem. I tried everything that could be possibly found on Stackoverflow and other sites. One of the thread that I followed is this. That did not help too.
The problem was at once resolved when I noticed that my executable project did not contain a reference to the library that I wanted to debug. So I just added the reference to that project.
**PS: ** This problem might also arise because the assembly referenced by the executable assembly might not match that in the references. So in that case, you just remove the already existing reference and add the new one.
Hope this helps!
The same happen to me because the .pdb file of the project have not been copied to the debug\Bin folder, so the symbols could not be loaded from the .pdb file.
You must rebuild your project and manually copy the symbols (.pdb file) to the debug\Bin folder of executable project.
I was trying to load symbols for a installed nuget package published on our local dev server. I had to uninstall and add a normal reference built from the code instead. This worked for me. Just remember install the original nuget package again once finished debugging.
If it works for you, try to embed debug symbols in the dll itself, so the symbols are loaded automatically. This worked for me in netcoreapp3.1 and net5.0:
<DebugType>Embedded</DebugType>
<EmbedAllSources>True</EmbedAllSources>
Beware that you may find this in documentation:
<AllowedOutputExtensionsInPackageBuildOutputFolder>$(AllowedOutputExtensionsInPackageBuildOutputFolder);.pdb</AllowedOutputExtensionsInPackageBuildOutputFolder>
but it does not work.
I ran into this with Visual Studio 2022, tried the most of answers here. Fixed by switching back to Visual Studio 2019, seems like a bug in 2022.
My issue was a bit simpler to resolve, but still the issue the question asked. At first, I was not publishing the pdb file with the nuget package another project was using. Once I confirmed that, I removed the nuget package from my project and readded it from our network nuget source. That still didn't let Visual Studio pick identify the PDB location.
Then I noticed that if you select one of your nuget packages, ( Project --> Dependencies --> Packages --> Choose nuget package), there is a Path property. I checked that location and it pointed to %USERPROFILE%.nuget\packages. The pdb was not at this location and the Date Modified was older than the latest package I published. Once I deleted the folder for the given package version, removed it from my project, and re-added it, the latest .dll and .pdb file were added to this location.
After that, I was able to step into the code of my nuget package and had no further issues.
To get the nuget project to produce the pdb file in the first place, I added <IncludeSymbols>true</IncludeSymbols> inside of a PropertyGroup within the csproj file as other answers had directed.
Once I rebuilt that nuget project, it generated 2 *.nupkg files:
Namespace.x.x.x.x.nupkg
Namespace.x.x.x.x.symbols.nupkg
I found this was because the Properties => Debug => Start Action was set to Start external program instead of the Project. So the newly generated pdb file didn't match, because the actual exe was the wrong one.
I have had this problem recently as well.
Was able to fix it by selecting MyProject->Properties->Linker->Debugging->Generate Debug Info->"Optimize for debugging (/DEBUG)".