How can we avoid showing the literal path in the exception's stack trace?

Question

When our in-house developed application (C#, ASP.NET) is throwing an exception, it displays a stack trace that contains path information like C:\users\DEVELOPER_FULL_NAME\path\some-module.cs. So it shows the full name of the developer who compiled it.

The developers are telling me, this is unavoidable. I find this hard to believe. I am no professional C# programmer, but working in IT, I have been programming (from Pascal to Assembler to C), so I think that my understanding should be fair enough.

So, how do you hide developer related personal information from the stack trace? Compile with a anonymous user on a dedicated machine? Is there a possibility to strip this information using a compile time switch or anything like that?

Answer 1

Couple of pointers.

You should never expose stacktrace to users. Thats a security risk. You should also never expose exception messages to users, only for custom exceptions that you know can not contain sensitive information is ok to expose.

You should never build your release candidate on a developer machine. You should use a build agent for this. The best solution is to look at using build agents, for example Azure devops support this and is a pollished and well working continuous integration suit. edit: There is also another reason for not building on your machine. On your machine you can have stuff in the GAC that makes the project build just fine on your machine but will not run on the target host.

Finally you should build the release candidate in release mode. Both for performance reasons and security.

Answer 2

From this blog:

<PropertyGroup>
  <PathMap>$([System.IO.Path]::GetFullPath('$(MSBuildThisFileDirectory)'))=./</PathMap>
</PropertyGroup>

So instead of this:

Unhandled exception. System.Exception:
at MyProject.Program.Main(String[] args) in /home/username/dev/MyProject/Program.cs

It will show this:

Unhandled exception. System.Exception:
at MyProject.Program.Main(String[] args) in ./MyProject/Program.cs

Answer 3

The build property or rather msbuild parameter is /pathmap or <PathMap>. It will rewrite all traces to your source locations.

Unfortunately i wasnt able to find the perfect documentation for this, but you can find a couple of blog posts using it.

e.G.: https://blog.paranoidcoding.com/2016/04/05/deterministic-builds-in-roslyn.html

Also: you can avoid the whole problem by using a build server, as suggested in the other comments. The "whole" solutions is probably to do both.

Answer 4

One simple solution is to clone (check out) the project to a folder outside of C:\users, provided the developers have access to such folders. For example, instead of:

C:\users\DEVELOPER_FULL_NAME\path

simply create a new folder (C:\dev) and clone here:

C:\dev\path

Of course, as others have pointed out, you're still exposing exception messages and stack traces to users, but at least developers' names are no longer being exposed.

Answer 5

When our in-house developed application (C#, ASP.NET) is throwing an exception, it displays a stack trace ...

And therein lies your fundamental problem - poor programming in the client application that does not correctly catch Exceptions and display Error Messages. Note the difference.

Exceptions contain a lot of information and they are not, generally, intended for User consumption. Indeed, to a User, they're downright scary! Exceptions are meant to tell Developers where their code [got] broke. They don't [often] include [the far more useful] why the code [got] broke, but at least "where" offers a place to start diagnosis.

Error Messages, on the other hand, are crafted for Users.
It tells them that something went wrong and, if possible, what they can do to put it right.
Users do not care that the Discombobulator's Frognosticate method threw a WeShouldNeverGetToThisLineException. They care that by changing something on the screen and clicking "OK" again, the application will do what they want! Don't scare them by throwing a screen-load of unintelligible junk at them.

Now there is a School of Thought that says that Exceptions can do both jobs.
Exceptions have a Message property and, some would argue, that this Message can be [safely] shown to the User. The important bit is that only the Message should be shown to the User, which brings me back to that improper handling of Exceptions - showing the whole thing, stack trace and all, is just plain wrong.