Question

We have a bunch of .NET assertions throughout our code, which we never see fail. If for some reason an assertion did fail, we would rather terminate the process and generate a crash dump than corrupt our users’ data.

We have all the architecture set up to create a memory dump upon an unhandled exception, so we would like our Assertions to behave that way in a release build. Is there a way of doing this neatly, or do we just need to replace all our Assert calls with some other function that asserts and then throws?

Answer 1

One option is to use Trace.Assert instead of Debug.Assert.

From the Remarks section of the MSDN page:

Use the Trace.Assert method if you want to do assertions in release builds. The Debug.Assert method works only in debug builds.

EDIT: In response to the comment:

The reason for the existence of Trace.Assert is to give the same functionality as Debug.Assert but in production builds. You should be able to use the same infrastructure that you use for crash dumps on Debug.Assert, but you’ll have to reference Trace instead of Debug. From the MSDN article Assertions in Managed Code:

For example, you could override the TraceListener.Fail method to write to an event log instead of displaying the Assertion Failed dialog box.

In your case, you could probably reuse the same TraceListener that you are (probably – I don’t know unless you say so) using today to generate a crash dump. The only difference is that you’d add it to Trace.Listeners instead of Debug.Listeners.