This is driving me crazy.
I have a rather large project that I am trying to modify. I noticed earlier that when I typed DbCommand, visual studio did not do any syntax highlighting on it, and I am using using System.Data.Common.
Even though nothing was highlighted, the project seemed to be running fine in my browser. So I decided to run the debugger to see if things were really working as they should be.
Every time the class that didn't do the highlighting is called I get the "the source file is different from when the module was built" message.
I cleaned the solution and rebuilt it several times, deleted tmp files, followed all the directions here Getting "The source file is different from when the module was built.", restarted the web server and still it tells me the source files are different when they clearly are not.
I cannot test any of the code I have written today because of this.
How can the source be different than the binary when I just complied
it?
Is there any way to knock some sense into visual studio, or am
I just missing something?
I got this issue running a console app where the source that was different was the source that had the entry-point (static void Main). Deleting the bin and obj directories and doing a full rebuild seemed to correct this, but every time I made a code change, it would go out-of-date again.
The reason I found for this was:
I had checked "Only build startup projects and dependencies on Run" (Tools -> Options -> Projects and Solutions -> Build and Run)
In Configuration Manager, my start-up project didn't have "Build" checked
(For #2 -> accessible via the toolbar under the 'Debug/Release' drop down list.)
I was just having this same problem, my projects were all in the same solution so they were using Project to Project references, so as one changed the others should have been updated. However it was not the case, I tried to build, rebuild, close VS2010, pulled a new copy from our source control. None of this worked, what I finally ended up trying was right clicking on the project and rebuilding each project individually. That updated the .dlls and .pdb files so I could debug through.
The issue here is that your dll and or your pdb files are not in sync.
Follow these steps
Just delete the bin directory from the project where the DLL is generated.
Re-build the project.
Remove reference from the project that make reference to the DLL.
Include again the reference.
Enjoy.
In addition to these answers I had the same issue while replacing new DLLs with old ones because of the wrong path. If you are still getting this error you may not refer the wrong path for the DLLs. Go to IIS manager and click the website which uses your DLLs. On the right window click Advanced Settings and go to path of the Physical Path folder on File Explorer and be sure that you are using this folder to replace your DLLs.
Some things for you to check:
Have you double checked your project references?
Do you have a Visual Studio started web server still running? Check the system tray and look for a page with a cog icon (you may have more than one):
(source: msdn.com)
Right click and close/exit it. You may have more than one. Can you debug your changes now?
Are you running the debug version but have only built the release version (or vice versa)?
Did the compile actually succeed? I know I've clicked through the "there were errors, do you want to continue anyway?" message a couple of times without realising.
With web services, the problem can be caused by using the Visual Studio "View in Browser" command. This places the service's DLL and PDB files in the bin and obj folders. When stepping into the web service from a client, somehow Visual Studio uses the PDB in the bin (or obj) folder, but it uses the DLL in the project's output build folder. There are a couple workarounds:
Try deleting the DLL and PDB files in the web service bin and obj files.
Try clicking "View in Browser" in Visual Studio.
If you previously got the source file mismatch error, Visual Studio might have added the filename to a black list. Check your solution properties. Choose "Common Properties -> Debug Source Files" on the left side of the dialog box. If your web service source files appear in the field "Do not look for these source files", delete them.
Unload the project that has the file that is causing the error.
Reload the project.
Fixed
I just had this issue.
I tried all the above, but only this worked:
delete the .pdb file for the solution.
delete the offending .obj files (for the file being reported out of sync)
build the solution.
This fixed the issue for all builds moving forward for me.
In Visual Studio 2017 deleting the hidden .vs folder in the resolved this issue for me.
This is how I fixed the problem in Visual Studio 2010:
1) Change the 'Solutions Configurations' option from "Debug" to "Release"
2) Start debugging
3) Stop debugging and switch the 'Solutions Configurations' option back to "Debug"
This worked for me. Step 3 is optional - it was working fine when I changed it to "Release" but I wanted to change it back.
My solution:
I had included an existing project from a different solution in a new solution file.
I did not notice that when the existing project was rebuilt, it was putting the final output into the NEW solution's output directory. I had a linker path defined to look into the OLD solution's output directory.
Switching my project to search in the new solution's output directory fixed this issue for me.
I had this problem, and it turns out I was running my console application as a windows application. Switching the output type back to console fixed the issue.
I had the same problem. To fix it I used the "Release Mode" to debug in VS2013. Which is sufficient for me, because I'm working in a node js\c++ addon.
My problem was that I had two projects in my solution. The second one was a test project used to call the first one. I had picked the path to the references from the bin folder's release folder.
So whenever I made a change to the first project's code and rebuilt it, it would update the dlls in the debug folder but the calling project was pointing to the release folder, giving me the error, "the source file is different from when the module was built."
Once I deleted the reference to the main project's dll in the release folder and set it to the dll in the debug folder, the issue went away.
In my case, the #Eliott's answer doesn't work.
To solve this problem I had Exclude/Include From Project my deficient file, andalso Clean and Rebuild the solution.
After these actions, my file with my last modifications and the debugger are restored.
I hope this help.
solution:-
the problem is:-
if your some projects in a solution , refer to some other projects,
then sometimes the dll of some projects, will not update automatically, whenever you build the solution,
some projects will have previous build dlls, not latest dlls
you have to go manually and copy the dll of latest build project into referenced project
I was using Visual Studio 2013 and I had an existing project under source control.
I had downloaded a fresh copy from source control to a new directory.
After making changes to the fresh copy, when building I received the error in question.
My solution:
1) Open Documents\IISExpress\config\applicationhost.config
2) Update virtualDirectory node with directory to the fresh copy and save.
My problem was that I had a webservice in the project and I changed the build path.
Restoring the default build path solved my issue.
I had this same problem and I followed the majority of the guidance in the other answers posted here, nothing seemed to work for me.
I eventually opened IIS and recycled the application pool for my web application. I have IIS version 8.5.9600, I right-clicked my web application, then: Deploy > Recycle > Recycle application pool > OK.
That seems to have fixed it, breakpoints now being hit as expected. I think that doing this along with deleting the bin and obj folders helped my situation.
Good luck!
I know this is an old question but I just had the same problem and wanted to post here in case it helps someone else. I got a new computer and the IT dept merged my old computer with the new one. When I set up TFS, I mapped a different local path than what I was previously using, to an additional internal drive. The old path still existed from the merged data on my hard drive so I could still build and run. My IIS paths were also pointing to the old directory. Once I updated IIS to the correct path, I was able to debug just fine. I also deleted the old directory for good measure.
I also experienced that. I just open the obj folder on the project and then open the debug folder delete the .pdb file and that's all.
This error also happens if you try to make changes to a source file that is not part of the project.
I was debugging a method from a .dll of another one of my projects, where Visual Studio had quite helpfully loaded the source because the .dll had been built on the same machine and it knew the path to the source. Obviously, changing such a file isn't going to do anything unless you rebuild the referenced project.
Delete all breakpoints.
Rebuild.
Done
At Visual Studio 2015, using C++, what fixed for me the the source file is different from when the module was built problem was
restart Visual Studio.
Check if the location you pointed to using mex() in Matlab is correct (contains lib and obj files which are modified to the last date you compiled the library in Visual studio).
If this is not the case:
Make sure you are compiling Visual studio in a mode that saves .lib files :
properties -> Config properties -> General -> Config type -> static library
properties -> Config properties -> General -> Target extension=.lib (instead of exe)
Make sure the output and intermediate directories match the Matlab directory in
properties -> Config properties -> General -> Output directory
properties -> Config properties -> General -> Intermediate directory
I get this issue when debugging sometimes w/ Visual Studio but when the application is served by IIS. (we have to develop in this form for some complicated reasons that have to do with how the original developer setup this project.)
When I change the file and rebuild, that fixes it a lot of the time. I know that sounds silly, but I was just trying to debug some code to see why it's doing something weird when I haven't changed it in a while, and I tried a dozen things from this page, but it was fixed just by changing the file..
In my case, the problem was that the debugger exe path was pointing to a net5.0 bin folder. I am using net6.0, so I should've updated the exe path back when I updated the target framework. Works fine now.
Debug-> start without debugging.
This option worked for me. Hope this helps!
Related
I'm unable to debug a project. I'm getting the "The breakpoint will not currently be hit. No symbols have been loaded for this document" error. I've tried everything I could find online, but nothing has worked. I'm hoping someone out there will be a fresh pair of eyes to find the problem.
First of all, I inherited this project from a coworker who has left. He did development on his machine where he was able to debug it. He uploaded it to Subversion which is where I got it. Another coworker was able to download it and debug, but I cannot.
Second, I'm using Visual Studio 2015. The project is an asp MVC project. There are two projects in the solution: the main project with the views, controllers, models, etc. and the secondary project which is only the Telerik.OpenAccess code (the "data layer"). It's this secondary project that I can't debug.
* Update *
Following a suggestion on another board, I hit a break point in my main project and went to Debug-Windows-Modules where I can see the message "Binary was not built with debug information". I went to the folder shown and can see my pdb file was not made at the same time as my latest dll fill. My project is set to debug mode and build. What do I need to change to get the pdb file to be recreated along with my dll?
* End Update *
So here's the line in the main project I've got my breakpoint:
rep.UpdateWorkOrderVendorHeader(oaObj);
The breakpoint hits here. It's calling a function in the secondary project. When I try to step into that function, it skips to the next line in the main project. If I look in the secondary project, I see the "symbols not loaded error". I also have a breakpoint directly inside the secondary project and still it gets skipped:
I've found two stackoverflow streams that covered a variety of scenarios, but nothing has worked for me:
Fixing "The breakpoint will not currently be hit. No symbols have been loaded for this document."
The breakpoint will not currently be hit. No symbols have been loaded for this document in a Silverlight application
Here is everything I think I've tried so far, but I may have missed something:
Restarted Visual Studio
Deleted code and copied code from co-worker that could debug secondary project
Build - Clean and Rebuild & Clean and Build
Deleting bin and obj folders
Checked configuration set to debug and build
Checked debug and trace constants are checked in the project properties
Click Debug - Start new instance on secondary project
Selecting multiple startup project (threw error saying the secondary project could not be started directly)
Debugging in IE instead of Chrome
Checked the reference to the secondary project in the main project has the correct directory
Checked that Project - Properties - Build - Optimize code was unchecked
Checked that Project - Properties - Build - Advanced settings were the same for both projects
Checked that Project - Properties - Build - Advanced - Output was set to full
Adding to the secondary project's App.config
Making sure I was running Visual Studio as administrator
Checked that Project - Properties - Build - Output path was /bin
I'll include seem screenshots of the config and properties below. Below is also a description of my project tree with some of the relevant files. I'd appreciate any suggestions you can give me. Thank you!
Koorsen (main project)
References
Koorsen.OpenAccess (secondary project)
C:\inetpub\wwwroot\Koorsen\Koorsen.OpenAccess\bin\Debug\Koorsen.OpenAccess.dll
bin
Koorsen.dll
Koorsen.pdb
Koorsen.OpenAccess (secondary project)
bin
Debug
Koorsen.OpenAccess.dll.config
Koorsen.OpenAccess.pdb
Koorsen.OpenAccess.dll
Telerik.OpenAccess.35.Extensions.dll
Telerik.OpenAccess.35.Extensions.xml
Telerik.OpenAccess.dll
Telerik.OpenAccess.xml
Release
Koorsen.OpenAccess.dll
Koorsen.OpenAccess.dll.config
Koorsen.OpenAccess.pdb
Telerik.OpenAccess.35.Extensions.dll
Telerik.OpenAccess.35.Extensions.xml
Configuration Manager:
Build properties:
Advanced debug properties for main project:
Advanced debug properties for secondary project:
Didn't receive an answer, but I was able to figure this out over a couple of days of trial and error. Posting this here in case it helps someone. Here is what I ended up doing.
Put a break point in the main project and ran the solution. When it hit the break point, I went to Debug->Windows->Modules. Found the name of the dll for the secondary project and noted the folder it was trying to use. I my case it was in C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files\vs\213421ba\66682af2\assembly\dl3\e121f20c\957624fe_d9ded101. The dll and pdb files did not have the same date. Rebuilt the project; the dll was updated, but not the pdb. Found a suggestion in another forum suggesting deleting the dll and pdb and rebuilding. This didn't work; the dll was recreated, but not the pdb. I deleted the entire vs folder.
Used NuGet package manager to uninstall and reinstall 2 Telerik Data Access packages to all projects.
Deleted the bin and obj folders in the secondary and main projects. May have been able to get away with just doing this in the secondary project.
At this point the secondary project compiled, but the main project did not.
Had to add some dll files back to the bin folder of the main project from third party extensions.
Still would not compile. Compared every reference, bin and obj file to those of a coworker who was having the same problem, but hadn't tried to fix being able to debug yet. Found 3 extra references. Removed them and the project worked again and I was able to debug the Telerik Open Access project.
I have searched and found other topics on this, but none of the solutions seem to work for me. Visual Studio is running old code in debug mode and release mode. If I go to the actual directory and launch the exe, it is the latest code. It is a XAML project.
Things I have tried:
1) Deleted bin and obj folders
2) Rebuilt solution
3) Cleaned solution
4) Made sure the project is set to build in Configuration Manager
Update: I tried adding a new configuration in Configuration Manager. The path is totally different, and it still running the old code. The exe built with the new config is the right code when I launch it manually, but it seems like visual studio is running a cached version of the exe.
Another gotcha I see a lot - be careful with shortcuts. If you are opening the solution via Recent Projects or another shortcut, try opening it via File -> Open or clicking on the solution file itself instead. I see a lot of developers looking at old code or the wrong branch because of this.
Can also try changing the assembly version number. Every once in awhile that will somehow make a difference.
I am not sure what exactly helped, but one thing is certain:
i marked .js file properties "Build action" as "Compile".
Tryed to deploy (got an error of course), and changed it back to "Content".
Rebuild, deploy, run debugger and FINALY it works on my current code.
The Error is back on my "new old" code
What i do is:
click "Continue", go to opened IE window with my page\site, press CTRL + F5,
and what i see?
My new current code inside VS debugger...
Error is gone
I am using Visual Studio 2012 and it was working all fine until I started observing some funny behavior. When I open my code it shows red Underlines which we usually see when there is an error in our code. Surprisingly, the code compiles all fine. I have made following observations that are not normal at all.
Red underlines in the code
While cleaning or building the solution no error.
Red underlines go away for some time after I build/clean the solution, but they come back eventually.
Because of this, my IntelliSense stopped working.
I can not right click on any component and go to its definition.
Any ideas?
Visual Studio 2017, Visual Studio 2019, Visual Studio 2022:
Closing Visual Studio and removing the .vs folder located in the solution directory worked for my C# projects.
This folder has a hidden attribute. You may need to change View settings to show hidden files in File Explorer.
Delete the contents of the temporary ASP.NET folder and then rebuild. It'll either be in your user folder (for IIS Express - \AppData\Local\Temp\Temporary ASP.NET Files) or the Windows directory (for IIS - C:\Windows\Microsoft.Net\Framework\vx.xx\Temporary ASP.NET Files)
Paths are off the top of my head and may not be correct
For me, this issue got fixed when I unloaded and reloaded the project again.
I had this issue and it was related to ReSharper.
Solution steps for me:
Disable ReSharper
VisualStudio\Tools\Options\ReSharper Ultimate\General\Suspend Now
Build Solution
(Ctrl + Shift + B)
Re-enable ReSharper
VisualStudio\Tools\Options\ReSharper Ultimate\General\Resume Now
Just had this problem while working with a solution created in Visual Studio 2012 but running in 2013. I closed Visual Studio, deleted all \bin and \obj directories and the problem was gone.
I had this problem after resolving some conflicts from Subversion (SVN). The solution has several projects in it and I resolved some conflicts in a few different projects. I did a menu Build → Clean Solution followed by a men Build → Rebuild Solution and everything was good again.
Do you have any plugins installed, like ReSharper? I had an issues with a bad plugin.
Try running Visual Studio in safe mode, to prevent plugins from running.
devenv /Safemode
If you are using ReSharper like me, you may delete ReSharper cache following by this link: Configure Caches
To specify the location for caches:
Open the Environment → General page of ReSharper options.
Use the Save solution caches in to select the location for cache files:
User local settings folder to store them in the following directory: %LOCALAPPDATA%\JetBrains\Transient
4.System TEMP folder to store them in the following directory: %TEMP%\ReSharperCache
Solution folder to store them in the root folder of the current solution
Custom folder to choose a custom location for ReSharper cache files.
Click Save to apply the modifications and let ReSharper choose where to save them, or save the modifications to a specific settings layer using the Save To drop-down list. For more information, see managing and sharing ReSharper settings.
Reopen your solution for the changes to take effect.
What works for me is deleting the IntelliSense indexfile.
The IntelliSense-file is in the same directory as you solution.
It's filename is SolutionName.sdf
Just delete this file, open you solution again, and IntelliSense will start rebuilding its indexfile. After that the problem will be gone.
In Visual Studio 2013 I solved this problem by deleting all of my obj and bin folders across all projects. The issue was probably due to solution configurations that I had deleted, but I hadn't been cleaned up properly, as doing a menu Build → Clean Solution doesn't remove the old outputs from the obj and bin folders.
This worked for me in Visual Studio Enterprise 2017:
Navigate to Tools > Options > Text Editor > JavaSCript/TypeScript > Linting > General
deselect "Enable ESLint"
I've run into this as well and was able to return Visual Studio to its normal state by doing the following -
Identify the project where the red lined code comes from
Remove the "red line" project from the references where it is being used (ProjectName\References - right click, add references, and uncheck the "red line" project)
Build (you should get errors now)
Readd the project reference that was just removed
Build again
The red lines should be removed and the project should build!
Steps that work
Open the solution and do a rebuild all
Close the solution
Open solution and do a clean
Close solution
Open solution and do a rebuild all
Close and then open the solution. It should be good. This works for me every time
Be careful deleting some of these settings files as you will lose saved debug settings, etc. And it may do more damage than you realize.
I have found recently it is easy to solve this by switching from Debug to Release in the dropdown to left of the Play Button. Then switching back from Release to Debug.
I had the same problem with lots of red lines in several *cpp source files. Though the code compiled perfectly. None of the other solutions worked for me.
Changing the order of #include lines of a *.cpp-file could make the red lines disappear - and reappear with the restored order.
Then I noticed a header file was included twice in a single *.cpp file. I removed the second one and - everything was fine.
Including a header file twice in the same *.cpp file seems to be no problem to the compiler but to the IntelliSense part.
Simply refresh the project/solution. It will get resolved.
I ran into this problem with the latest Visual Studio 2017.
Also the debug version of my program was running painfully slow.
I deleted the Solution file .sln and created a new one.
I had a similar problem when I was seeing lot of red squiggles in a couple of files. I tried all answers proposed previously, but nothing seemed to work.
The moment I started browsing through the classes, structures in other files for which complaining files had references, the problem disappeared. It seemed IntelliSense was not able to resolve dependencies on its own for some reason.
For me, I had at one time enabled fusion logging to debug some assembly dependency errors (fuslogvw from a CMD prompt). That was months ago and I had been experiencing much slower build times (5-7 minutes) since then.
I had also forgotten entirely that I had left them enabled. These logs were my bottleneck and disabling them has made iterating much faster.
In my case with Visual Studio 2017, I have many "red lines" shown below all symbols defined in a third-party library, but my project can actually build without problems. I have tried all suggested solutions (like delete the .VS folder, restart Visual Studio, etc.), but none of them working.
Finally, I fixed it and this is how: I open my application project's property page, then go to C/C++ → General → Additional Include Directories, which is the place I put all needed third-party library header paths.
I delete all the path (but save them somewhere), click "Ok" to confirm. Then I come back to the same setting, paste those paths back, click "Ok" to confirm, and then all those "red lines" disappear.
I have VS2019 with ReSharper, and ran into this issue.
What worked for me was:
Go to the ReSharper >> Options menu
Go to the General tab (should be the default)
Press the "Clear caches" button
Close all instances of Visual Studio (2019)
Restart Visual Studio
Using VS2022 without Resharper when this problem occurred, tried several things, this did help me in the end:
Close Visual Studio
Delete folder .vs in the Solution folder
Go to folder %USERPROFILE%\AppData\Roaming\Microsoft\VisualStudio\
Delete all folders whose names start with 17.
Reopen Visual Studio
More specific subfolders could exist that might be enough to delete, but I had no issues after deleting all of it. AFAIK these only contains user session data, temporary files and/or cache files that can be downloaded again or recreated as needed.
Found this solution:
Close Visual Studio (ensure devenv.exe is not present in the Task Manager).
Delete the %USERPROFILE%\AppData\Local\Microsoft\VisualStudio\xx\ComponentModelCache directory.
Restart Visual Studio.
I have had this problem for months and have finally fixed it. Closing Visual Studio and removing the .vs folder located in the solution directory did not work for me.
There was an assemblyIdentity tag in the web.config file which was referencing a library that was not in my references folder. I removed this tag, cleaned, closed and reopened, and the problem was fixed.
Check each of the assemblyIdentity tags in your web.config file and check them against the references folder in solution explorer
Remove any assemblyIdentity tags, including the parent dependentAssembly tag for any which aren't listed in your references folder.
Clean the solution
Close and reopen the solution
Deleting .vs folder did the trick for me.
for me this works:-
Open the Command Palette ctrl+⇧+p
Then type: reload Window.
Deleting all the folders which start with "asp.xxx" worked for me. You can reach these folders by:
(C:\Windows\Microsoft.Net\Framework\vx.xx\Temporary ASP.NET Files)
Hover over the word that has the red underline squibble. A mini dialog box will appear. Click on 'Quick fix' and then click on 'Disable error squibble'.
Any changes I make to my code aren't doing anything. I've even tried putting lines in that I know will crash my program, and nothing. It just keep running the old version. It's even loading old versions of files I've edited and saved.
There a 3 projects in my solution. 2 are pure C#. 1 is a WinForms application.
It sometimes happens that some files "are being used by another process".
Close your solution and delete all "bin" and "obj" subfolders of all your projects that are included in the solution.
Then open your solution again, execute "Clean solution" and build it again.
Check this setting in Tools/Options, then under Projects and Solutions>Build and Run.
On Run, when build or deployment errors occur:
My personal preference is for this value to be 'Do not launch'. It will prevent Visual Studio from launching the "last successful build".
Try Ctrl+Shift+B. This will build your solution (not just a particular project). Other environments might build when you save but this needs to be explicit in Visual Studio.
Had issue with saving code changes on VS2017 (mac) Version 7.3 Preview (7.3 build 740)
Only way to get file changes to save was to do File > Save All
Doing File>Save would act like the file saved. But, when I opened the file again and no changes were saved.
Ok, you need to add more detail, but you may want to have a look at this answer:
How to enable/disable compile errors warning in Visual Studio
delete Published DLL From Bin
file names -
projectName.ddl
projectName.pdb
delete these two files and run project
I had the same problem (Visual studio 2015 is not noticing my modifications in C# XAML files).
Problem solved by deleting 2 'debug' subfolders. One in the bin folder and one in the obj folder.
I met the same problem. the code changes is not saved.(you can see from the edit it is in Yellow color. e.g. indicating changes). SAVE and BUILD will not let it save the changes. i have to wait sometime, then it could possibly save success..
Deleting the whole project and the corresponding folder from local and check out the solution again. This worked for me=> VS2017
I solved the problem like this:
1. I closed the program
2. I opened the folder that contains the file (.csproj) and opened it with Visual Studio.
Next, I chose the folder to run the command as in the image
Had the same problem. Turns out I had moved a project folder. Even when opening the solution from the moved folder and editing and saving this source code, VS 2019 was building and running a different instance of the program with the same name. Go to File-> Save yourproject.cs as..and manually walk back through the directory structure to find the instance VS is actually running. Hope this helps.
also check another option in Tools>Build and Run>Only build startup project & dependencies if you have more than 1 nested dependency, especially when using Prism or any other reflection-based frameworks that prevent "dependency detection". Also, make sure you're in the editor when using shortcuts like Ctrl+S (Save) or Ctrl+Shift+S (Save all)
Go to this location:
C:\Users\<your_system>\AppData\Local\Microsoft\VisualStudio\<studio_version>
Then remove all files and start Visual Studio.
this was the error , no changes made after build.
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)".