For various reasons all our components are deployed in the GAC, both in the client (winforms) and server (hosted by a WCF windows service) machines. We use VIsual Studio 2013 / .Net 4.5.1
We were not deploying or storing PDBs anywhere which I know is a mistake. We are now looking into correcting this, so to improve our exception traceability and debugging purposes we are:
Generating PDBs with pdbonly and optimize true in our msbuild process, and storing them safely, not sure yet if we will use a symbol server or we will just store it with the binaries.
Deploying the DLLs AND the pdbs to production in the GAC (C:\Windows\Microsoft.NET\assembly\GAC_32...), this is to get line numbers in stack traces. Not sure if this is worthy as the optimizations usually change the line numbers anyway. If anyone has any comments about this then great, but at the moment we have very long methods and not having a clue about the line number consumes time :-)
We also deploy some powershell scripts to generate INI files to disable/enable optimization if required as described here. So the plan is that if our client finds an error then we can turn optimization off and get correct line numbers if needed.
In addition to this using ProcDump we instruct our clients to generate a minidump whenever they get an exception difficult to reproduce in development with procdump -e 1 XXXX
My question:
I know copying the PDBs and the INI files in the same folders where the DLLs are (in the GAC) doesn't look right. So... where can we put these then? I havent been able to find any solutions so the PDBs and INI files are picked up in production.
I have posted this in a MS forum as well, if anyone answers I will add cross references... but I have been searching for a few hours and haven't found any information...!
After consulting people at Microsoft it looks like we were doing the right thing, i.e. Putting the pdb and ini files in the gac folders is correct.
Also FYI the pdb is loaded (I.e. Performance penalty) whenever the exception.stacktrace is used.
Hope it helps!
Source: http://blogs.msdn.com/b/visualstudioalm/archive/2015/08/14/debugging-optimized-code.aspx (See comments at the bottom of the article)