Although you can disable PDB files generation altogether, it’s good idea to have these. Debugging without PDB files later is so much harder, like if debugging isn’t hard enough already. One thing that might be bothering you, is the source files location that is stored in PDB files. You might want to change these paths – build servers often use random directory names or you might want to simply hide that the project directory on your hard drive has some weird name. 😃
For such scenario
PathMap variable is available in
csproj, where you can specify mapping from original path to new path.
Building some application and opening the PDB file in i.e. Notepad, easily shows the paths are there. And these paths will be in exception’s stack trace for example. As expected.
Let’s modify the
csproj file by adding these lines (I created the
AppOutputBase variable for better readability).
Building the application again, now the paths are changed to
X:\test. That also means, when the exception is thrown and i.e. logged, the exception will have new paths in stack trace.
Unhandled Exception: System.InvalidOperationException: Operation is not valid due to the current state of the object. at ConsoleApp1.Program.Main(String args) in X:\test\Program.cs:line 9
As a bonus the path to the PDB file in the DLL has a new path as well. In my test
The parameter from
csproj is internally passed to Roslyn via command line parameter
/pathmap:k1=v1,k2=v2, so it’s not some kind of dark magic. Also, as you can see multiple values can be passed, if you need to.
The scenarios, and certainly others have more, I sketched at the beginning are not unsolvable, although with
PathMap it’s so much easier.