So question is – when we would see any of this?

Accordingly to Blair Wheadon,  Product Manager in the Volume Business Unit at SAP, our cries may be answered relatively soon.

Post is a nice summary and I hope features discussed would be in the final product.

Few highlights I pick for myself and with comments:

• Crystal Reports Basic will no longer be included in Visual Studio 2010
  Finally! Every time I have to set-up Visual Studio environment, I have to make sure I do not bring CR Basic along since I have a full version instead.
  Do not worry “Crystal Reports for Visual Studio 2010 will be provided by SAP as a free download, no registration required“.
  We are committed to have a beta version at the time that Visual Studio 2010 goes GA. A production release will be no later than Q3 2010
• There are slight changes in Licensing… as usual, read it through.
• 64-bit run-time support.
  Good! Platform independent code for .Net applications.
• New WPF Viewer
  Even better! No more .Net 2.0 assemblies (I hope)
• New XLSX export to take advantage of the big grid for data-only Excel exports
  Finally! 64K page limit is inconvenient, to say the least.

You can read about other more or less important improvements in Blair’s post, but these are answers for questions I was looking for.

What is Assert or Assertion?

By its definition Assert:

• state categorically
• affirm: to declare or affirm solemnly and formally as true
• insist: assert to be true
• In Computing (wiki): “an assert is a predicate (i.e., a true–false statement) placed in a program to indicate that the developer thinks that the predicate is always true at that place”

In general, using assert in the code proven to be useful in many situations because it “checks for a condition and outputs the call stack if the condition is false” and it could help to debug some strange situations in the code.

Assert is your friend

This method is for programmers to use. But what happen often when something is convenient, it started to be used excessively. Why it is happening?

Let’s look at the declaration of Assert in C# (3.x). There are two versions of the Assert(): Debug.Assert() and Trace.Assert(), both in System.Diagnostics namespace.

// Checks for a condition and outputs the call stack
// if the condition is false

[ConditionalAttribute("TRACE")]
public static void Assert(bool condition)

[ConditionalAttribute("TRACE")]
public static void Assert(bool condition, string message)

[ConditionalAttribute("DEBUG")]
public static void Assert(bool condition)

[ConditionalAttribute("DEBUG")]
public static void Assert(bool condition, string message)

As we can see from above code, Assert is to be used for Testing and Debugging and therefore should not be used as a way to present any information to the end-user.

Helping yourself

As useful as it seems, even then Assert infrastructure may not be used to full extend. In the sample declarations above we can see that logic can be invoked with and without providing any additional information.
Imagine how useful is a message “Project raised an Assert in line X” compare to “Project raised an Assert with the Message in line X”.
First option gives you idea where something failed, where second actually tells you what went wrongand where. Let’s use power of the tool-set and provide ourselves with useful information.

Assert is NOT for an end-user

I was asked recently (this seems to be a ongoing discussion) – “Why a programmer should not be using asserts as a regular approach in code conditions validation even when it comes to a production code?”

By default, Assert would show a message box with some information and the current Call Stack. This information, while being helpful to the developer, would not tell much to the user.

With custom TraceListener introduced, message can be hidden from the user and information could be stored, but it is not how it should be used by definition.

If information is expected to be presented to the user in any form, it could be achieved in a form not an exceptional, intended for debugging, situation, but by using regular methods: message box, application log, Windows event log, etc.
Even in the case of component development it is desired to use exceptions (raise/throw) to “bubble” proper message to the error handling layer.

The throw statement is used to signal the occurrence of an anomalous situation (exception) during the program execution.

Assert is a conditional logic

Last, final and probably major concern here is that in Release environment Debug and even Trace functionality would be disabled and therefore, any code/logic which depend on Assert() would be suppressed and all the nice validations became worthless (see declaration above)… and Access Violation errors starting pop up unexpectedly.