XSD.exe and DebuggerStepThrough

Did you ever try to step into properties of classes generated by XSD.EXE when debugging? It doesn't work, does it? Not even on methods that you might have extended the XSD.EXE's partial classes with!

It is a common practice to generate partial classes from XSD schemas using XSD.EXE, and then extend some of them in another source file.

This all works nice and clean, but XSD.EXE is nasty and decorates all the classes it creates with the DebuggerStepThrough attribute.

That makes the debugger treat not only those parts of the classes that were created by XSD.EXE as 'nondebuggable'; you can't step into you own code (those methods in the class part authored by you), either!

Now, here are three ways to fix this:

• run a search&replace and get rid of all the DebuggerStepThrough attributes
  
• in Visual Studio, go to Tools/Options..., unfold the tree on the left-hand side of the dialog that will appear down to Debugging/General, and then uncheck the box next to 'Enable Just My Code'
  (Note that you will still have to set a breakpoint in the code marked as DebuggerStepThrough, otherwise the debugger will skip over it anyway)
  
• stop using XSD.EXE :) (thanks to Marcin for this acute observation)
  

Well - the choice is yours :)

[see: Disable DebuggerStepThroughAttribute in code generated by xsd.exe?]

 

Interview Questions: Constructors in C#

A good interview-type question: constructors in C#.

Here's a good one for an interview (whether you're the interviewer or the interviewee):

When declaring a constructor in the subclass, should I explicitly call the base class's constructor?
And if I don't - will the base class's constructor get called anyway?

That's basically what a discussion between my friend Marcin and me got down to...

If you've ever used Resharper (don't tell me you haven't!), you might have noticed that when you go:

class SubClass : BaseClass
{
   public SubClass() : base()
   {
      // some code here
   } 
}

it will gray out base(), because it is redundant.

And it's true - because if the base constructor wasn't called, the object might not get fully initialized - and that would in a sense break the Liskov's Substitution Principle...

Actually - you do not have to "agree" for the base parameterless constructor to be invoked. You can choose a different one instead:

public SubClass() : base(5)
{
   // some code here
} 

However - if you look at this summary C# Constructors:

There must always be a "chain" of constructors which runs constructors all the way up the class hierarchy. Every class in the hierarchy will have a constructor invoked, although some of those constructors may not explicitly appear in the code.

All clear now, eh? ;)