PDB files for production app and the "Optimize code" flag

Question

When should I include PDB files for a production release? Should I use the Optimize code flag and how would that affect the information I get from an exception?

If there is a noticeable performance benefit I would want to use the optimizations but if not I'd rather have accurate debugging info. What is typically done for a production app?

See comparison of options in http://blog.vuscode.com/malovicn/archive/2007/08/05/releasing-the-build.aspx — Michael Freidgeim, Apr 24 '13 at 21:35

Duncan Smart · Accepted Answer · 2011-11-29T15:30:43.513

When you want to see source filenames and line numbers in your stacktraces, generate PDBs using the pdb-only option. Optimization is separate from PDB generation, i.e. you can optimize and generate PDBs without a performance hit.

From the C# Language Reference

If you use /debug:full, be aware that there is some impact on the speed and size of JIT optimized code and a small impact on code quality with /debug:full. We recommend /debug:pdbonly or no PDB for generating release code.

score 16 · Answer 2 · edited Apr 22 '23 at 06:59

16

To answer your first question, you only need to include PDBs for a production release if you need line numbers for your exception reports.

To answer your second question, using the "Optimise" flag with PDBs means that any stack "collapse" will be reflected in the stack trace. I'm not sure whether the actual line number reported can be wrong - this needs more investigation.

To answer your third question, you can have the best of both worlds with a rather neat trick. The major differences between the default debug build and default release build are that when doing a default release build, optimization is turned on and debug symbols are not emitted. So, in four steps:

Change your release config to emit debug symbols. This has virtually no effect on the performance of your app, and is very useful if (when?) you need to debug a release build of your app.
Compile using your new release build config, i.e. with debug symbols and with optimization. Note that 99% of code optimization is done by the JIT compiler, not the language compiler.
Create a text file in your app's folder called xxxx.exe.ini (or dll or whatever), where xxxx is the name of your executable. This text file should initially look like:
```
 [.NET Framework Debugging Control]
 GenerateTrackingInfo=0
 AllowOptimize=1
```
With these settings, your app runs at full speed. When you want to debug your app by turning on debug tracking and possibly turning off (CIL) code optimization, just use the following settings:
```
 [.NET Framework Debugging Control]
 GenerateTrackingInfo=1
 AllowOptimize=0 
```

EDIT According to cateye's comment, this can also work in a hosted environment such as ASP.NET.

edited Apr 22 '23 at 06:59

Koedlt

4,286
8
15
33

answered Sep 18 '08 at 19:55

HTTP 410

17,300
12
76
127

>To answer your second question, using the "Optimise" flag with PDBs >means that those line numbers might be off by a few lines. Are you sure this is true? – Karsten Jun 18 '09 at 16:33
No, I'm not sure. I've corrected my answer to reflect a difference that I am sure about (stack collapse). I need to investigate the line difference theory in more detail. – HTTP 410 Aug 19 '09 at 09:05
You should attribute your source - Scott Hanselman http://www.hanselman.com/blog/DebugVsReleaseTheBestOfBothWorlds.aspx – Cristian Diaconescu Feb 23 '11 at 13:41
11

@Cristi, the source of Scott's blog entry is somebody called Mark Pearce. That's me :-) – HTTP 410 Feb 25 '11 at 10:58
RoadWarrior you mentioned a way to debug release version by using the [.NET Framework Debugging Control] ini file. But also said "This doesn't work in a hosted environment, e.g. ASP.NET." **Is there any way** able to debug release version dll in a hosted env't, like ASP.NET? It'd be really useful and powerful. Thanks. – cateyes Jun 26 '13 at 23:23
1

This post [ASP.NET MVC SOURCE DEBUGGING THE EASY WAY](http://martin.bz/blog/asp-net-mvc-source-debugging-the-easy-way) can provide a clue to my above question, i.e., just place the .ini file into the asp.net temp folder in which the dll sits. – cateyes Jun 27 '13 at 04:29

score 3 · Answer 3 · edited Jul 14 '14 at 10:58

3

There is no need to include them in your distribution, but you should definitely be building them and keeping them. Otherwise debugging a crash dump is practically impossible.

I would also turn on optimizations. Whilst it does make debugging more difficult the performance gains are usually very non-trivial depending on the nature of the application. We easily see over 10x performance on release vs debug builds for some algorithms.

edited Jul 14 '14 at 10:58

Sid M

4,354
4
30
50

answered Sep 03 '08 at 15:03

Rob Walker

46,588
15
99
136

Copy PDBs into production is a good idea ( at least for web sites). See http://stackoverflow.com/questions/933883/are-there-any-security-issues-leaving-the-pdb-debug-files-on-the-live-servers BTW, if you include PDBs with your deployments, you don't need to keep them in some separate place like a symbol server – Michael Freidgeim Apr 27 '13 at 21:02

PDB files for production app and the "Optimize code" flag

3 Answers3

Linked