VS built dll without debug info. even set to include debug info - c#

same GitHub issue here.
the solution of
https://github.com/kerryjiang/WebSocket4Net
did generate two files
WebSocket4Net.dll
WebSocket4Net.pdb
but WebSocket4Net.dll didn't contain Debug Table.[checked with PE viewer].thus no pdb file location info is contained. thus vs debugger refuse to load the pdb. even manually.
The catch is;
the project is set to debug.
optimize is off.
output debug info is set to full.
Is there anything else need to be set?

Oh! I tricked myself.
I copied the dll and pdb to my project's output dir.
but every time the my project build. it would be overwritten by project's dll. thus I would see a dll without debug info.
Hope this would help someone. There's no other config needed. check the simplest assumptions that taken for granted.

Related

ILMerge: Combining assemblies in one exe, App.Config

I am using ILMerge to combine .ddls in one executable, however when I run the Output.exe, it seems not to be finding the App.Config file. It is returning an error of: InvalidOperationException: No connection string name could be found in application config file.
I wonder whether ILMerge has included the App.Config file in the Output.exe at all.
How can I not include it and make sure that the Output.exe is referencing it?
I used the ILMerge GUI - this doesn't give me the option to include anything but the .dlls - which I select from the bin/Release folder where the ConsoleApplication compiles into.
Here is an image from the bin/Debug folder. ILMerge doesn't give me the option to include ConsoleLayer.vshost.exe.config - which includes the (basically) App.Config file. How can I make it include it so that the Output.exe knows the connection string details when it runs?
Thanks.
The default configuration file is app_name.exe.config. You need to take the config file you want and rename it to match the exe file.
In your case Output.exe.config.
This may be a bit late for this if you have found a solution, but any file with vshost in it's name is generally associated with debug mode in your application. It's you application running in debug mode. So when you are clicking on the application.exe to run you app, it does not look for any file with vshost in the file name. it looks for the application.exe.config instead. You can turn this off for debugging.
Unless you are planning on including your debug files in you merged exe, I see no need to include it. it's only useful in debugging.
Here are some links that may be helpful...
google search for disabling vshost
Stackoverflow question and answer...
what-is-the-purpose-of-vshost-exe-file answered by the famous Jon Skeet

"PDB does not match image" error in C# VS2010 project

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.

How to read a crash dump file (I have source code and .pdb files)

I have read the questions that already on StackOverflow, but I still can't make it work.
I have
a mini dump file from a customer
the exact same version of our code that the customer has got
in the debug directory, .pdb files for the code.
I tried putting the mini dump file in the debug directory, then opening it in Visual Studio 2010.
I don't know if this was the correct thing to do, or what to do next.
"Start Debugging" is greyed out in the normal Debug menu.
There is a box with "Actions" in the top right hand corner of the Minidump File Summary tab. So I clicked on "Debug with Native Only" but all I get is "There is no source code available for the current location."
I must be missing something really simple - please can someone give me a hint?
Just to pull the various bits of information together into an answer:
Do you have .pdb files that were created when the program was built? Just rebuilding the same source doesn't work, you need to keep .pdb files for every build. – Alex Farber Feb 20 '13 at 11:05
"The debugger matches information like filename, timestamp and checksum when matching a PDB with a binary (DLL or exe)." (Saikat Sen, Codeproject article)
Following AlexFarber's hint, I copied the source code and release folder from the customer's build onto my computer (the whole build had been saved, including the .pdb and .exe files in the Release folder).
Then I copied the dump file into the release folder, and loaded the Microsoft symbols into the same folder.
Then I opened the dump file again into Visual Studio 2010.
I didn't see anything more helpful than before, which I assume is due to this - see the accepted answer on this SO question. I am using a C# and a .NET 2.0 assembly, and it seems that I can only view source code for a .NET 4.0 assembly.
I will try the WinDbg add-in called sos.dll recommended by Hans Passant on the same question next.
How to get round the need to use the pdb files from the same build:
I think you can get round this requirement for the same .pdb files if you use WinDbg. From virtualdub "If the debugger is stubborn and doesn't want to load symbols because it thinks they don't match, you can use .symopt+ 0x40 to set the "load anything" flag."
Also, if I understand correctly, you can use the chkmatch tool referred to by sergmat above, to match up the .exe and .pdb files.
As I understand it you have a minidump for a customer which I presume he is using a Release build of your application and a Debug PDB file.
That's your problem right there, Your PDB and the mini dump do not match. In order to view clear stack traces the PDB should have the same build configuration/platform as the one of the application that generated the dump file.

Regarding PDB usage

Its always recommended to store the PDB files for each public build so that we can debug if there is any issue on Production server.
My doubt is if my source code is changed even due to addition of two lines whether i will be able to debug when i run the program and try to attach it to my debugger?
In my understanding since PDB contains the line no. and local variable only,if the source code is changed we can't debug , so how its helpful unless we go back to original source which created the dll but if we know the source file then why we need the original pdb since we can replace it our local pdb.
I am sure i am missing something here..Will be glad if you clear this.
When using a symbol server with a source server, you should be able to debug binaries (or a dump from a customer) without requiring access to the source that produced the modules and symbols. It is tremendously helpful.
We update both servers for every build, which allows us to debug an application in a QA environment even if we do not have the source code on disk.
PDB files on their own isn't too helpful if the source that produced them is missing.

Standalone debug window?

I'm writing a library that compiles to a DLL which is ran by another C# app. I need some way to "see" some variables in my code. I don't have a console, and there's no way for me to output text to the other app.
I think I found before some program that would display all the Debug.WriteLine for all running porgrams... can't remember the name of it. Anyone know it? Or at least know some way for me to debug this?
If you compile your library in debug mode, it will generate a pdb file alongside with the dll. You can then step in through your methods calls in the dll if you have the pdb in the same folder. To do this you need to open the .cs files from your library and put a breakpoint on the code.
I do not know if I'm clear enough, but say solution A uses dll B. Make sure that where dll B is you also have a related pdb file. Then in VS just use the Open File from the menu to open the .cs file you need to debug in. If the debugging symbols have been loaded correctly from the pdb the breakpoint symbol will be full and you will be able to debug the code.
If your not already in a VS session, you can just start VS. Attach a debugging session to the process which is running yourt code, open the .cs code file(s) from the dll (again you will need the pdb file, and the pdb file will need to be in the same folder as the dll) and you can then put breakpoint in the code file.

Categories