-
Notifications
You must be signed in to change notification settings - Fork 214
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
How to debug a merged assembly (.EXE)? #368
Comments
what version are you using? how do you invoke it? |
if there's a way for me to debug I'm happy to take a look |
I switched to the ILRepack MSBuild Task, here, but I'm getting the same result. The version number there appears to align with yours, so it might be reasonable to assume it's the latest—v2.0.34. Here's my target:
Note that I'm including the I'll see if I can whip up a quick repro project. Give me a day or two—I'm busy tomorrow with other stuff. |
One thing I should mention is that you should make sure all input assemblies have a matching .pdb file next to them. ILRepack supports merging pdb files, but if the original pdb files are missing or not matching, things will obviously not work. You need to be able to debug the original assemblies to be able to debug merged assemblies. You can use the pdb dotnet tool to verify whether a pair of .dll and .pdb match:
|
Ah, that may have something to do with it. Most of the assemblies I'm merging are Microsoft's, so I don't believe I have access to those PDBs. Another one is Autofac, and I'm pretty certain I won't be able to get that one either. In fact, the only PDB that I do have access to is the entry point, Setup.exe—my application. It's worth noting that I'm targeting |
ChatGPT tells me that I'll have to use ILSpy to decompile the newly merged assembly and recompile it to get a new (and matching) PDB. Which sounds like a recipe for failure to me, at least when trying to automate it. Is there anything to this claim? (I've learned not to place too much trust in that thing.) |
as long as your setup.exe has a pdb you should be fine I think |
I'll need my ration of sleep first, and then I'll get that repro project together. |
you can compile your setup.exe with You shouldn't need to roundtrip via ILSpy because normally VS can debug without pdbs and decompile on the fly. |
Good tip, thanks. |
I get this, even after embedding That's from the source of Setup.exe. One clarification, please... when VS reports "Binary was not built with debug information," what exactly does that mean?
(Hat tip to your earlier tip I'll get started on that repro project now. It shouldn't take me long. |
Oh interesting, this is VB. Might be related (or not??) In VS, try going to Debug -> Windows -> Modules, find the module for Setup.exe, right-click and do Symbol Load Information... Also run the |
I'm guessing not, since we're talking IL here. Correct me, please. Here's the Symbol Load Information for the merged Setup.exe (which contains the .pdb from the pre-merged Debug build): The command
Note there is no .pdb in the Merged folder, which is expected after the embedding. |
I wasn't able to reproduce this in my test project. My Setup.exe project is targeting |
Oh, I think you must've meant run the Here's what I got from that:
Maybe there's something wonky going on with the generation of that .pdb file? It's also quite large, weighing in at 7.63MB where the source .pdb is only 146KB. |
Nope, that wasn't it. I added a I think a big clue is that Native pdb. Something's triggering ILRepack to create that format—one of the input assemblies, perhaps? Here's the list:
See any immediate suspects? FWIW I'm eyeballing that BouncyCastle. It's only there as a transitive package, so I'll see if I can get rid of it. |
Nope, that's not the one:
I guess I'm going to have to go through those 22 assemblies one-by-one and see if I can figure out what's triggering the broken .pdb. Whew. |
No match is key here - it means that pdb doesn't even match the dll |
Right. The pre-merge .pdb matches, but the post-merge .pdb doesn't. My next troubleshooting step is to add the packages one-by-one to my repro project that are currently on the Setup.exe project and try merges for each one. If I can get a repro that'll pinpoint the culprit. |
OK, I found the problem. It's my fault. I broke it. I'm using a build target to modify the assembly's resources after it was merged (and after the merged .pdb was created). It's only natural that the two don't match. But here's the problem: I have to do that. Several of the Microsoft assemblies contain an XML file resource, all with the same name ( I don't want to risk a crash in my application when one of these merged assemblies tries to get the XML it needs and can't. So I wrote a small console app that extracts the XML from each assembly, merges it into a single XML document (all the root node elements bear the same name), and then adds it to the single merged Setup.exe after ILRepack has done its work. So I'm in a bit of a Catch-21, as you can see. Can ILRepack rebuild that .pdb after I've fixed the resources? |
It means they were already repacked using ILRepack I think? ILRepack definitely has logic to merge these, so you don't need to have your own custom IL rewriting step: I'm not super familiar with this but I think you can delete your custom tool. |
I think you need the new |
Darn! Somebody found it before me 😉 |
Thanks a bunch! 👍 |
Oh, one last thing... Does "Binary was not built with debug information" simply mean that the assembly and its .pdb don't match? Or is it something more complex than that, such as some sort of pointer not being added to the assembly? |
ChatGPT tells us this:
Would you agree? |
I just built a console app with DebugType none, and the output of pdb on it was:
This means C# used deterministic compilation (modern default), instead of generating a random timestamp. Then I switched the DebugType to full:
Now the binary includes a debug directory entry with the information about the pdb: Guid, Age (normally 1), path to the pdb at the moment of compilation and the stamp. It also finds the .pdb next to the .exe and says that the pdb matches (has the same Guid and age), and prints that it's an old-style (Native) Pdb (C/C++ MSF 7.00 is just the file format). When the binary was built without debug information it means that the debug directory entry is missing. It's not just the pdb is missing or mismatching. If you now delete the .dll from disk and re-run, you get:
It still has the record but now it can't find the Pdb so it won't attempt to match it or print the pdb format. If you now switch to DebugType portable, you will get:
For portable Pdbs it is also able to tell you what the Guid and stamp are. Finally you can switch to DebugType embedded, and you will get:
|
So from the ChatGpt output the second bullet is correct. |
I owe you a milkshake. |
And the fact that when you ran pdb on your assembly it printed nothing (just the file path) means that the rewritten assembly was neither reproducible nor contained a debug directory entry with the pdb info :) |
I'm using a PowerShell script to merge
$(TargetDir)\*.dll
with$(TargetDir)\Setup.exe
into a subfolder$(TargetDir)\Merged\Setup.exe
.The merge is successful, and
Setup.exe
runs, but I'm getting some JIT errors that don't occur during a debug run and I need to... well... debug them.But when I attach to the process, Visual Studio's Modules window reports that the "Binary was not built with debug information." So I can't load the symbols.
I'm doing this in
Debug
configuration, and a .PDB is being generated. But it seems the assembly itself is missing something.Is there a way to get ILRepack to include debug information during the merge?
The text was updated successfully, but these errors were encountered: