C# Puzzlers (Video Training)

How well do you know C#?  Put your knowledge to the test with Bill Wagner’s C# Puzzlers video LiveLesson!

Bill Wagner’s C# Puzzlers exposes common misconceptions that can occur when developers are unclear about how language features interact or lack understanding about how a single features works.  Using the fun “Puzzler” format, Bill demonstrates these misconceptions via screencasts using small code samples.  He gives you an opportunity to  figure it out first, and then explores different ways to modify the code until its behavior is correct.

This collection of Puzzlers is divided into seven sections. Each section delves into the rules that govern the aspects of the C# language that developers find most confusing: 

I.             Generics

II.            Method Resolution

III.           Named and Optional Parameters

IV.          LINQ

V.            Value and Reference Semantics

VI.          Dynamic Programming in C#

Table of Contents

The introductory Puzzler introduces the format using a puzzle, and discusses some of the nuances of object construction.

Generics are still one of the most important aspects of the .NET environment and the C# language. So many of the features we use every day are built upon generics in one way or another. Generics are still a complicated feature. You must create code whose types are not known until runtime. The compiler must generate IL with minimal information about the actual types that will be represented by the type parameters.  The JIT must convert that IL into executable code and plug in the real types for the type parameters. Finally, the meta data carried along must include information that enables reflection and other advanced techniques to work correctly.

 What information gets conveyed, and what information cannot get used when a real type is substituted for a type parameter?

What happens when you create overloads for generic methods?

How do generics and arrays differ with respect to variance?

How does the compile choose between different candidate generic methods?

The rules that govern method resolution in C# are necessarily complex. The features the community has asked for and the team has implemented have only added more complexity to those rules with each new release of the C# language. If you want to be a strong C# developer, you need to have at least a working knowledge of these rules.

What happens when derived classes create overloads of base class methods?

How does the compiler resolve overloaded methods when you use null parameters?

What if the overloaded parameter types are unrelated?

What if one of the methods is generic?

Named and optional parameters sound so simple at first examination. But this feature has significant implications on other features in the language. It also has significant implications on areas as fundamental as how parameters are passed to called methods.

When is a default constructor not a default constructor?

Which is the better match?

When do parameters get evaluated? Why does it matter?

LINQ introduced totally new ways of constructing and organizing programs. There were new rules related to how you wrote algorithms.  Those rules still cause developers confusion in some cases.

When are LINQ queries evaluated?

How does LINQ process expressions and method calls?

Reference types and value types behave differently in many important ways. They also behave the same in many other ways. It can be difficult to keep those differences in mind as you get too accustomed to the similarities.

When does copying values hurt?

What happens when value types receive event notifications?

Dynamic extensions move many of the common tasks that were performed by the compiler to runtime libraries. The interplay between static and dynamic typing creates new complications in C# programs.  This section discusses some of the most common ways where static and dynamic types interact in ways that can be surprising.

How do dynamic types interact with extension methods?

Under what conditions can anonymous types be treated dynamically?

Why would you pick different ways to implement dynamic types?