Closed bolthar closed 10 years ago
Hi! Happy to help. First some questions to understand the environment:
Try this: compile your app, copy your PDBs to D:\symbols, then run EXE directly (not through VS).
If you can share your sample project, I can try and recreate the issue. Basically if the source info is not being printed it means it is not finding matching PDBs.
Hi! Thanks a lot for the insta-reply! :)
I've tried to clean, rebuild, copy the animationTest.pdb symbols file to the D:\symbols dir, and then running the .exe outside VS - same result. Here (https://github.com/bolthar/animationtest) is the sample project - animations have nothing to do about it :)
Thanks a lot again!
Hey, thanks a lot for the sample project. I think I see where the problem is, and it is not with your code. A COM GUID in ProductionStackTrace.Analyze.SymbolLoader.Load()
method used to create DiaSource instance is wrong. This is eye-opening, because I wrote and tested this on VS 2013, which means the COM GUID changed between VS 2012 and VS 2013 release of DIA SDK.
Now I am in the office with VS 2012 on my machine, and I can replicate your issue. I need to fix this and make a new release, because this is clearly wrong.
I will do it in the evening (EST) if you can wait.
I can absolutely wait :) thanks a lot, you've been incredibly helpful! Can I help you somehow?
Fixed it and deployed new 1.0.16 version to NuGet. You can update the NuGet package through Visual Studio and get the fixed version. It should work for you and display the line number information.
Basically the issue was that DIA SDK has been changing its the COM class GUID with each VS release it seems. I never tested on lower VS versions after building it on a machine with VS 2013 on it. The fix is simple - try all the historical GUIDs in order until one works. That means supporting it from VS2008 till VS2013.
Enjoy! Let me know if you have any other questions.
P.S. Please confirm that it works for you now.
Updated and tested, works like a charm :+1: thanks a lot!
Excellent! You are welcome :)
Same experience here with VS 2015, could it be we need an update for 2015 too?
I've tried to use the Analyze.Library nuget package to extract line number infos from the exception report but couldn't - I get the instruction causing the exception but no line numbers.
Here's a sample of what I am doing - D:\symbols\ contains the latest symbols (which I copy-pasted from the debug/ folder)
Here's the output:
And here's the exception report:
I'm most likely doing something stupid here :) but I've spent quite some time going through the examples and I really have no idea where to go next - sorry for disturbing you directly.