I've been using a library in my code base for a while now, and I wanted to debug right into the library level. To do that, I downloaded the source code and included the project as an existing project into my C# solution. I then had my other projects reference that project instead of the downloaded .DLL.
Once the project was referenced instead of the DLL, I ran my solution through the debugger and tried to step into a function call that would have called into the external project, but it stepped right over it. While debugging, I opened up the "Modules" window and saw that the DLL's Symbol Status read "PDB does not match image", which is the likely cause of not being able to debug this project.
My question is simple, why does the PDB not match the image if my project is directly referencing the .csproj file as a reference? There should never be any ambiguity as to what version to run.
I've run into this issue before when I have another project open that also references the DLL and uses its debug info (PDB). Basically the other project puts a file lock on the PDB in the referenced project and when you compile or debug the referenced project, it quietly fails to generate an up-to-date PDB file.
If this is what is going on, make sure you have no other apps running or instances of VS open that reference your DLL, and then seek out and delete all copies of the PDB from beneath the BIN and OBJ folders, then recompile it.
I hope that helps.
Sometimes it happens because you might have build the project as a release.
Right click on the solution and click on "Batch Build" > Check all your projects and click "Clean"
For me this happened for an Excel Add-In. I went to the modules window to see why it wasn't loading for my dll. I looked at the folder where the .dll was located and went to that location. There was an .ini file in that location. Opening it revealed the install location of my application, which turned out to be in "C:\Program Files\" as opposed to the bin\debug location of my project.
Basically I had an old version of the add-in already installed that was getting loaded up upon me trying to debug the project. I uninstalled the old project, deleted the old .dll location in "C:\Users[user]\AppData\Local\assembly\etc..." and voila, the debugger loaded up the newly compiled dll.
Faced same issue, it was due to old assembly and latest PDB. There was mismatch between both.
The assembly was built properly, but again my post build dll copy script was overwriting it with older one.
Removing the dll from post build script resolved issue.
Need to ensure that dll or pdb are up to date when debugging finally commences.
This happened to me today while I was trying to debug notepad++ dll plugin , I had to change build output directory to notepad++'s plugins directory and set the Debugger to launch notepad++ instead of the current project dll to proceed with set breakpoint. This had me nuts as Visual Studio 2019 was telling me that SYMBOLS were not loaded for the plugin dll which I was trying to debug.
Finally checking the modified date and time as others here suggested, made me realize the pdb was not up to date with the the build output dll timestamp. I tried rebuilding the solution but the pdb generated has same older timestamp though I delete them manually and initiate build. So all I had to do was to make a change in the source code by deleting a white space and rebuild. Voila! this time I got the debugger to load the symbols for my dll automatically and hit the set breakpoint.
Maybe cleaning the solution also might have worked.
Related
I'm using Visual Studio to "Publish" my application, but when I install it on another PC I get an error for a missing .DLL
Is there a setting in the properties that I'm overlooking maybe?
This is very frustrating because on my development PC it works.
It is called FK623Attend.dll
This is the FKAttendDLL.cs Code
This is the DLL Properties
The Original Program doesn't have the DLL in the solution... It was registered during installation.
Thanks in advance
right click on the dll and go to properties. then set "Copy to Output directory" to " always copy" .then publish... Let me know if it works
If it is a managed dll (.NET assembly) it should be added as a reference to the project and not as a file. If it’s a native DLL that just needs to be included, check the properties of the file and make sure the settings for copying are either Copy always or Copy if newer and type is Content. Otherwise the file is ignored.
My Visual Studio 2013 ASP.NET webform application has 3 DLL assemblies. When debugging, DLLs and PDBs are created in the same Temporary ASP.NET Files directory for only two of the three DLLs (the Project/VB module and a C# module. The third DLL is also a C# module, and the PDB is not being generated to the same directory as the DLL.
The symbols for that last problem module are not being found. When I attempt to load the symbol files manually selecting a PDB that was created on the same Date/Time as the DLL, I get the error "A matching symbol file was not found in this folder."
Why would PDBs be built in the DLL's directory for two modules and not for the third module? I've tried a variety of options on the Symbol Settings dialog, changing the Symbol file locations and cashe directory, cleaning and rebuilding the solution, and the results are not changed.
Did you check in the advanced build dialog (in your project properties(the one where the pdb is missing) and then, debug info : pdbonly or full ?
it must not be set to "none"
This problem was resolved. The C# module that was not producing a symbol file was an old copy of the DLL. Attempts to rebuild the module did not replace the old DLL.
All copies of that old DLL were deleted first and then the module was rebuilt. The next debug attempt showed a new DLL and PDB file were properly created.
I also suddenly got this error when I attempted to run a test after I made changes to the app.config of the test project. These changes turned out to be invalid.
In a C# project, I create minidump at UnhandledException.
In my Dev machine, project source and bin are under path K:\projects\*MYPROJECT*, if I manage to let it crash in my Dev machine, everything work perfectly, I can open the minidump file and correctly see source code, callstack, threads etc.
End-user program path will obviously be different; as an example, in our Test machine project is installed under C:\*MYPROJECT*. It's deployed with pdb symbol files. Anyway, when I try to open the minidump, generated on that machine, on my Dev computer (where I have the source files), Visual Studio try to find the executable and pdb file under "Test Path" (C:\*MYPROJECT*) without of course find it.
I tried setting Symbol path to include K:\projects*MYPROJECT* without any result, so I recreated the same Test directory structure, creating C:\*MYPROJECT* and copying .exe and .pdb files under that directory. Now, Visual Studio is be able to find them, but it's saying "No native symbols in symbol file", and it doesn't let me see any source code.
How can I accomplish to load the correct Symbols?
To change the directory, Microsoft describes to open the immediate window and type .exepath [path] to change it.
You can also use .srcpath [path] and .sympath [path].
Finally came across a solution.
After weeks trying to figure out what I were missing, I've found that on my development machine I have a different Framework version (in details, I have v4.0.30319.18444 vs v4.0.30319.17929 on test machine). I still don't understand why I shouldn't be able to debug my application without having the exact Framework version, but the solution was to copy mscordacwks.dll and mscordbi.dll (both of them found in C:\Windows\Microsoft.NET\Framework) from the Test machine to the folder where the minidump is.
Reference:
Managed Minidump Debugging in SP1
In Eclipse when I implement a class library and I'm ready to deploy, I usually export and package it into a JAR file that later you can just add to the build path in another project. Is there an equivalent feature in Visual Studio? Is there a proper way to "publish" a class library and package it into a dll file to later add as a reference in another project? Or do you just usually go and dig for it in the bin folder yourself?
Most VS projects compile into a DLL. If you want your DLL to be "published" to some particular location when you build, you can use build events which can also package up your dll (you could call a batch script, for example, that takes care of that for you).
Is there a proper way to "publish" a class library and package it into a dll file to later add as a reference in another project? Or do you just usually go and dig for it in the bin folder yourself?
Sure, just add the bin\debug\yourdll.dll or bin\release\yourdll.dll as a reference in your other project, or otherwise to the location you moved it to in your build event. No need to go digging for it every time.
Change the output type to 'release' or 'Debug'.
Go to Build, Build Solution (Or f5)
Navigate to: The Solution Bin folder for release or debug.
3a. You can quickly navigate to the solution folder by right clicking the solution in the
'Solution explorer' and selecting 'Open folder in File Explorer'.
The compiled DLL file will be in that directory. (bin\release or bin\debug)
I'm trying to deploy an application written in wpf c#. I use an external library (irrklang). I added a reference in visual studio to that dll (it is placed in the same folder as the executable). It shows up in my application files, I deploy, install on a different machine and I get the file not found exception. I looked up the exe folder and the DLL is in the folder.
What am I doing wrong, the reference seems to be correct but the program isn't finding the dll at all
UPDATE: added solution below. Still same error:(
Check the following points:
Properties of the DLL -> Use local copy = true
Project Properties -> ClickOnce Properties -> ApplicationFiles -> Check if your dll is enlisted and manually set "Include" on it.
Then try again. ClickOnce often has annoying bugs.
Found it, the external dll requires the visual studio redistributable.