You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If we want to get a readable stack trace in the event of a crash, we need a .pdb file to go along with the executable?
Currently, the .pdb file must be in the same directory as the win32 executable.
So far this works great. The pdb file is created next to the exe, and if we crash, we get filnames and line numbers in the report.
However,
We currently have no way to inject this pdb file into assets.zip before the exe is built.
This ruins delivering the exe as a "portable" app. It will create it's assets with no pdb file.
The exe and pdb file are created at the same time, already using assets.zip.. we cannot add a pdb file to assets.zip.
Final Note: The pdb file MUST be inside of the assets.zip file before resources are built into the exe.
Ideas. 1. Always copy the pdb to /assets.. that way when we build again, the previous pdb will exist. (must build twice). This has an issue of using an old .pdb file if code changed.
2. The only other way is to somehow inject the pdb into the executable's resources after build. Yikes.
The text was updated successfully, but these errors were encountered:
If we want to get a readable stack trace in the event of a crash, we need a .pdb file to go along with the executable?
Currently, the .pdb file must be in the same directory as the win32 executable.
So far this works great. The pdb file is created next to the exe, and if we crash, we get filnames and line numbers in the report.
However,
We currently have no way to inject this pdb file into assets.zip before the exe is built.
This ruins delivering the exe as a "portable" app. It will create it's assets with no pdb file.
The exe and pdb file are created at the same time, already using assets.zip.. we cannot add a pdb file to assets.zip.
Ideas.
1. Always copy the pdb to /assets.. that way when we build again, the previous pdb will exist. (must build twice). This has an issue of using an old .pdb file if code changed.
2. The only other way is to somehow inject the pdb into the executable's resources after build. Yikes.
The text was updated successfully, but these errors were encountered: