Essential C# 5.0

Essential C# 5.0 is a well-organized, “no-fluff” guide to the latest versions of C# for programmers at all levels of C# experience.

Fully updated to reflect new features and programming patterns introduced with C# 5.0 and .NET 4.5, this guide shows you how to write C# code that is simple, powerful, robust, secure, and maintainable. Microsoft MVP Mark Michaelis and C# principal developer Eric Lippert provide comprehensive coverage of the entire language, offering a complete foundation for effective software development.

The authors illustrate key constructs with succinct, downloadable code examples. Graphical mind maps at the beginning of each chapter outline the material that is covered and how individual topics interrelate. This edition also includes C# Coding Guidelines that call attention to today’s best practices for writing C# code. Separate indexes of C# versions 3.0, 4.0, and 5.0 make it easy to find answers specific to whatever version of C# you are using.

Throughout, topics intended for beginners and advanced readers are clearly marked. If you’re new to C#, this guide will help you start writing significant code quickly. If you’re an experienced C# developer, you’ll gain insight into today’s most complex programming challenges and techniques as you master key C# 5.0 innovations such as async/await pattern. No matter how advanced your skills become, you’ll come to rely on this indispensable reference.


Coverage includes:

  • Mastering C# data types, operators, control flow, methods, and parameters
  • Making the most of C# object-oriented constructs, including classes, inheritance, interfaces, and more
  • Building reliable, effective exception handling into your code
  • Using generics, delegates, Lambda expressions, and events to reduce code complexity
  • Learning dynamic programming with reflection and attributes
  • Querying virtually any type of data using LINQ with Query Expressions
  • Creating custom collections that operate against business objects
  • Understanding the Common Language Infrastructure and C# in the context of the .NET 4.5 development platform
  • Taking advantage of declarative programming, embedded metadata, reflection, and attributes
  • Thoroughly mastering multithreading and synchronization, including the new async/await paradigm
  • Discussion of WinRT and programming in C# for Windows 8
  • Using P/Invoke, pointers, and direct memory manipulation to interoperate with code in other languages
  • Understanding how C# programs relate to the underlying runtime

Errata Document

Sample Chapters

“NOTE: this content is taken from the previous edition of Essential C# 3.5, not 4.0.”

Code Listing Source Code

The code is available on GitHub – feel free to make pull requests.


The sample code doesn’t contain every code listing within the book. If there are particular samples missing that you would like to have please email and let me know.

Special thanks to Kody Brown who did a ton of work reviewing, testing, and posting the code for this edition.


About the Authors

MARK MICHAELIS founded IntelliTect and serves as its chief technical architect and trainer. Since 1996, he has been a Microsoft MVP for C#, Visual Studio Team System, and the Windows SDK; in 2007, he was recognized as a Microsoft Regional Director. Michaelis serves on several Microsoft software design review teams, including C#, Connected Systems, Office/SharePoint, and Visual Studio. He speaks at developer conferences and has written many articles and books.

ERIC LIPPERT is a principal developer on the C# compiler team at Microsoft, and a member of the C# language design team. He has worked on the design and implementation of several Microsoft languages, and on Visual Studio Tools for Office.

Comments are closed.

Contact Us
Phone: (509) 315-3400


I absolutely love code reviews. My team uses a very informal asynchronous method for doing code reviews. When changes are made, a code review request is sent to the other members of the team. As people have time, they will look over the code review requests and provide feedback. Pretty painless; the way a code review should be. The purpose of code reviews is to improve quality of both the code and the developers. With that in mind, I would like to present some pointers for doing code reviews. Leave your ego at the door. Everyone has something they can learn. Code reviews are not a time for senior developers to make sure junior developer’s work is up to par. Rather, it is an opportunity for developers to learn from each other. In the past, my code has been improved by developers with far less experience reviewing my work. Ask questions on anything you cannot explain. When reviewing code, keep in mind that you may be the next developer that has to work with it. A code review request is an opportunity to ask the original author about their changes while the code is still fresh in their mind. Always make sure you can explain what the new code is doing, and when practical, why it is doing it. Always pose a question in the code review on anything you cannot explain. Review your own changes before submitting them. The saying, “write your code like it will be maintained by a psychopath that has your home address” contains quite a bit of truth. Don’t waste your team’s time by sending out a code review before you have reviewed it yourself (you should do this before checking in the code too). A little proofreading goes a long way. Keep the code review as small and as focused as possible. Try not to mix refactoring and bug fixes together. Be ruthless to the code but kind to the developer. Though it may be tempting, avoid commenting on code that was not affected by the changes in the code review. Only critique things affected by the changes you are reviewing. Typically, I consider any method that was modified and any code that is directly invoked or directly invokes a modified method to be open for critique. This is not a hard and fast rule; it may come down to a judgment call. As a general rule, the reviewer is always right. The burden lies on the author to either make the reviewer’s suggested change, or defend their original work. The goal is to improve the quality of code. Thinking critically about your code and defending your work will ultimately make you a better developer. The reviewers are likely people you work with on a daily basis. Take this opportunity to try and foster a good working relationship. Pay attention to detail; the little things matter. Don’t waste your time clicking through a code review if you do not have the time to focus on it. Marking a code review as “Looks good” when it’s not, will not improve quality and will give a false sense of quality. All developers should follow the same coding standard (your team does have one right?). Anything that does not match your coding standard should be caught and addressed during a code review. This will help avoid disputes over developer’s personal preferences. Though not comprehensive, here are some questions to ask when doing a code review:
  • Can you explain all of the changes?
  • Does the code meet coding standards?
  • Are relevant work items (bugs/user stories/tasks/etc.) properly referenced?
  • Are things named appropriately?
  • Is the code in the right location?
  • Is the code well structured?
  • Is the code tested?
  • Are exception cases properly handled?
    To all of the developers who have critiqued my code over the years, thank you.  
- , ,
CONTACT US: (509) 315-3400 | | Jobs | Site Map