using Programming;

A Blog about some of the intrinsics related to programming and how one can get the best out of various languages.

Demonstrating Insecurity of Managed Windows Program Memory

Is Memory in a Managed Windows Program Secure?

Recently I was on one of the (many) Stack Exchange sites answering a question a user posted, like usual. This question was a bit different though: the asker was concerned about the best way to make sure people couldn't read the password the user entered out of memory.

Unfortunately, this is not a task that can really be solved on consumer devices. Anyone with enough knowledge (and it's not really a lot) can do it. I'm going to demonstrate how to today with a simple Visual Studio programme.

Essentially, what I'm going to do is 'connect' to a fake SQL server (nothing about it will really exist) and then demonstrate how one can (with a copy of Visual Studio) extract the entire Connection String of that SQL connection out. It's actually quite trivial and with enough practice can be done in seconds.

Of course there are other ways to do this, it can be done programatically, there are other bits of software for it, etc. I'm just going to demonstrate how any developer can do it with the tools (s)he has at their disposal.

Creating our test projects

So the first step is to create a test project we can use to 'attack'. We're going to consider this an attacker/victim scenario, since that's what one of the real world applications is.

Our code is going to be pretty simple:

using Evbpc.Framework.Utilities.Prompting;
using System;
using System.Data.SqlClient;

namespace VictimApplication
{
    class Program
    {
        static void Main(string[] args)
        {
            var consolePrompt = new ConsolePrompt(null);

            var connectionString = new SqlConnectionStringBuilder();
            connectionString.DataSource = consolePrompt.Prompt<string>("Enter the SQL server hostname/ip", PromptOptions.Required);
            connectionString.UserID = consolePrompt.Prompt<string>("Enter the SQL server user id", PromptOptions.Required);
            connectionString.Password = consolePrompt.Prompt<string>("Enter the SQL server password", PromptOptions.Required);
            connectionString.InitialCatalog = consolePrompt.Prompt<string>("Enter the SQL server database", PromptOptions.Required);

            using (var sqlConnection = new SqlConnection(connectionString.ToString()))
            {
                try
                {
                    Console.WriteLine("Connecting...");
                    sqlConnection.Open();

                    using (var command = new SqlCommand("SELECT 15", sqlConnection))
                    {
                        Console.WriteLine($"Command output: {command.ExecuteScalar()}");
                    }
                }
                catch
                {
                    Console.WriteLine("Could not establish a connection to the server.");
                }
            }

            Console.WriteLine("Press enter to exit.");
            Console.ReadLine();
        }
    }
}

Do note this uses my ConsolePrompt from GitHub.

So we have our victim application, now we'll go ahead and attack it.

Attaching Visual Studio to a running application

You're probably expecting a title like 'attacking an application with Visual Studio' but that's not as descriptive as what we're doing. Yes, this is how you attack it, but attack sounds nefarious. We're not doing anything nefarious, we're just attaching a debugger to a running application.

So we're going to open a new instance of Visual Studio, and not open or create a project. Just open the instance.

Screenshot 1 - Fresh Visual Studio Instance

So, we've opened Visual Studio (I'm using 2015 but this should work on 2010+). The next thing we'll do is launch our application.

Screenshot 2 - Launch Application Outside Debugger

Right, so we have the application running outside the debugger. No other instances of Visual Studio need to be open, nothing else needs to be running, just that application and our fresh instance. The next step is to attach the debugger to a process.

This is under Debug -> Attach to Process. You should see a new window open, and we want to find our 'Victim Application' (VictimApplication.exe).

Screenshot 3 - Attach to Process

We'll go ahead and attach it. Our screen should change to look like we're in a regular debug session, even though we didn't launch the program through Visual Studio.

Screenshot 4 - Debug Session is Green err Blue

Now we still have our other window open with our running application in it. All we have to do next is start checking it out and see what we can inspect.

This next part isn't required, but it should help you familiarize yourself with what we're going to do. Let's hit the 'Break All' button (CTRL + ALT + Break with default shortcuts).

Screenshot 5 - Break mode

As of this moment the program is paused. Since it's a console application, you can still type into it, but your typing will not be processed by the program at this point.

Screenshot 6 - Text not handled by program

Next we'll hit 'Show Diagnostic Tools' and then select the 'Memory Usage' tab. Once we have done that, we'll hit 'Take Snapshot'.

Screenshot 7 - Taking our first memory snapshot

So now we're at the point we can start inspecting objects in our program. The first thing we'll want to do is click the blue 429 (your number may vary) link to the list of objects.

We'll then sort them by name since we're not concerned about the count, we just want to look through them.

I'm going to inspect our ConsolePrompt as an example, which in this case is listed as Evbpc.Framework.Utilities.Prompting.ConsolePrompt. When you find an object you want to inspect, hover over it and you should see an icon that looks like a square grid with a circular shape on the top-left corner, click that and a new page should open.

Screenshot 8 - Selecting an object to inspect

We'll then see a new page with all the instances of that object listed. If you hover over the Value, you should get a tool-tip that has a breakdown of the object itself, which you can explore just like normal. We'll see that the Logger is in fact null like we wanted.

Screenshot 9 - Exploring our object

Now that we've played with our explorer, we can go ahead and close that breakdown and continue with our program. We'll hit 'Continue' and resume execution. If you typed a server host into the console, you'll see as soon as we hit continue that the program continues to the next step. We'll fill out all our requirements and then break our program again when it starts connecting, and take another memory snapshot.

Screenshot 10 - Connecting to our server

We see that the new snapshot has 3,825 objects allocated, and the difference is an increase of 3,396. Our graph shows that we allocated a lot more memory (relatively speaking) and we can now go ahead and inspect our snapshot to try to find our password. We'll be looking for a string type with a value of pass.

We know it'll be part of the SqlConnection, so we'll sort that by name and then go down to SqlConnection and explore it like before.

Screenshot 11 - Find our SqlConnection

Upon exploring it we'll just a different method of extracting our string. Click 'Referenced Objects' at the bottom of our window, and hover over the middle String object. (Mine is 0x2FB0BD8)

Screenshot 12 - Extracting our Connection String

And there we have it. We have successfully extracted our password from a separate Visual Studio instance while the original application was running completely separately.

Debug Symbols and why they are important

Of course, our demonstration was made slightly easier by the inclusion of the .pdb files (debug symbols), usually you won't have access to these for the running application, so you'll have to look a little harder sometimes to find what you're looking for.

If you don't know what Debug Symbols are, Wikipedia has a nice description. Essentially, the pdb file (stands for 'Program Database') is the symbol map for .NET programs. It contains each generated instruction header and what the generated name of it was.

Finding our String without SqlConnection

The last thing we'll do is find our string value without exploring the SqlConnection object. We're only going to look with the Diff list, and run from there.

So, we'll restart our application, then attach the debugger, then enter our host and user, then take a memory snapshot like we did earlier.

Screenshot 13 - Round 2 First Snapshot

Then we'll hit 'Continue', enter our password, and take another snapshot.

Screenshot 14 - Round 2 Second Snapshot

The next step is to disable 'Just My Code' in the filter. If we don't do this it becomes much more difficult to locate what we changed.

Screenshot 15 - Round 2 Disable Just My Code

So we see that it created one string, by the Count Diff. being +1 on the String type, this helps us narrow down what we're looking for. If click once into it, and view our 'Paths to Root', it helps us discover that we have +1 in String [Local Variable]. So we're in the right place.

Screenshot 16 - Round 2 String Local Variable

We'll inspect the String like before (Square icon with Round outset) and we'll see that by default it sorts the list by `'Inclusive Size (Bytes)', we'll sort it by 'Instance'. Theorhetically our password should be the last instance listed. If we scroll to the bottom of the list we see that, indeed, it is.

We also see that our user id is right above it.

Screenshot 17 - Round 2 Find our Password


And there we have it! We learned how to inspect objects in our program when it was launched outside Visual Studio by attaching a debug instance of Visual Studio to it.

Optimizing for Tail-Call Recursion in F#

Rewriting for Tail-Call Recursion in F#

While this post is written in F# and specifically for it (referencing ILASM), the principles and practices here can be applied to any function (or non-functional) language that uses tail-call recursion and provides optimizations for it.

Recently I was working on a project, and I had to extend the F# List type to make things a bit simpler. I wrote a method takeThrough that allowed me to provide a predicate, and much like takeWhile, it would return elements until the predicate returned false, then it would return one more element. This was important for the code I was writing, I needed to return everything up to and including the first element that caused the predicate to return false.

So, I wrote this method called takeThrough:

let takeThrough(predicate)(source) =
    let rec loop sourceTemp =
        let head = sourceTemp |> List.head
        if head |> predicate = true then
            head :: (sourceTemp |> List.tail |> loop)
        else
            [head]
    loop source

The problem with this method is that it cannot be optimized for tail-call recursion in it's current state.

What is Tail-Call Recursion?

In order to understand why we're talking about optimizing for tail-call recursion here, we have to first undestand what is tail-call recursion?

In functional languages such as F# things like loops are discouraged, and in some of them even unavailable completely. So, in order to avoid them we have to rewrite our methods for recursion of some form (usually).

If we were to take this same example in C# it might look something like:

IEnumerable<T> TakeThrough<T>(IEnumerable<T> source, Predicate<T> predicate)
{
    var continueLoop = true;

    foreach (var item in source)
    {
        if (predicate(item))
        {
            yield return item;
            continueLoop = true;
        }
        else
        {
            yield return item;
            continueLoop = false;
        }

        if (!continueLoop)
        {
            break;
        }
    }
}

(This may not be the most optimal manner to write this method in, but it guarantees success.)

So we're just looping through each item here and returning it as we go. With F# we don't want to use such a construct, as we want to avoid loops. So we go to recursion, in C# the F# code we wrote above might look more like:

IEnumerable<T> TakeThrough<T>(IEnumerable<T> source, Predicate<T> predicate)
{
    return _loop(source, predicate);
}

IEnumerable<T> _loop<T>(IEnumerable<T> sourceTemp, Predicate<T> predicate)
{
    var head = sourceTemp.First();

    if (predicate(head))
    {
        var result = new List<T>();
        result.Add(head);
        result.AddRange(_loop(sourceTemp.Skip(1), predicate));
        return result;
    }
    else
    {
        return new List<T> { head };
    }
}

It's almost verbatim identical to the F# version. What we can see being a problem here is a StackOverflowException being through if source is large enough and predicate would return late enough. This is what we're hoping to avoid with Tail-Call recursion.

Remember: in order for a method to be optimized for tail-call recursion, the recursive call has to be the last thing the method does.

Now you might look at that method and say "well the last thing that happens is everything is piped to loop." Not quite true. We don't realize that head :: is the very last thing the method has to do.

This is an important note because loop is called, then that value is given to the concatenation operator.

The if/else is ugly too

Of course the other problem is the if/else construct, but that can be fixed with a match head |> predicate with and then match to each boolean value (true and false).

Right, so that's simple. Easy fix:

match head |> predicate with
| true -> head :: (sourceTemp |> List.tail |> loop)
| false -> [head]

Great. We solved the easy idiomatic issue, but how in the world do we make it tail-call recursive?

Visualizing our tail-call recursion

The first thing we have to do is determine how can we write the structure of this method so that the loop call is the last thing to happen? Ignore what it does for now. We just want to know what it would have to look like. We need a visual.

let takeThrough predicate list =
    let rec loop ... =
        ...
        loop ...
    loop ...

So we know what it should look like-ish. That's a very good start. Now we have to figure out how we can get it to that state.

So we know that our method needs to match each item with a predicate, and then return a List of all the elements that matched and the next element. So we need to accumulate a list of elements.

Notice I bolded accumulate. We need a variable in our loop that is an accumulator in this case.

Now we know our visual needs to change:

let takeThrough predicate list =
    let rec loop acc ... =
        ...
        loop newAcc ...
    loop [] ...

This looks about right. Our acc will be a List since that's what we're building out of, and we're going to pipe the newAcc to the list each time we iterate, and then pipe an empty list to our loop before we get started.

Creating our tail-call recursion

So now that we've visualized it, we can start to write the final pieces of it.

We'll start at the final line: loop [] .... What do we know about this call? We know that we only have two parameters in the method, and one variable (well, constant, but it's a function so it will look like a variable). And that's all we need. So we'll pass our initial list to our loop because it's the only we have to pass.

let takeThrough predicate list =
    let rec loop acc ... =
        ...
        loop newAcc ...
    loop [] list

Now our definition for loop has to change:

let takeThrough predicate list =
    let rec loop acc listTemp =
        ...
        loop newAcc newListTemp
    loop [] list

Alright, great progress. We just have to apply our operations now. In our case, the newAcc will be the appended list, and the listTemp will be stripped of the first item. Let's get the logic for head in there and work from that.

let takeThrough predicate list =
    let rec loop acc listTemp =
        let head = listTemp |> List.head
        match head |> predicate with
        | true -> ... loop newAcc newList
        | false -> ...
    loop [] list

Perfect! We're almost done, getting newAcc and newList are both easy: newAcc is just List.append acc [head], and newList is just listTemp |> List.tail.

let takeThrough predicate list =
    let rec loop acc listTemp =
        let head = listTemp |> List.head
        match head |> predicate with
        | true -> loop (List.append acc [head]) (sourceTemp |> List.tail)
        | false -> ...
    loop [] list

The last issue is our false condition: what do we do here?

Simple: we just kill the batman return what the newAcc would have been.

let takeThrough predicate list =
    let rec loop acc listTemp =
        let head = listTemp |> List.head
        match head |> predicate with
        | true -> loop (List.append acc [head]) (sourceTemp |> List.tail)
        | false -> List.append acc [head]
   loop [] list

And we've achieved our goal of tail-call recursion. The very last thing in loop is a call to itself. (Remember that in this case, match is the last condition, then one of two things happens: we call loop or we return the new stuff.)

Verifying with ILDASM

If we look at the IL for this method, we'll see the following:

.method assembly static class [FSharp.Core]Microsoft.FSharp.Collections.FSharpList`1<!!T> 
        loop@4<T>(class [FSharp.Core]Microsoft.FSharp.Core.FSharpFunc`2<!!T,bool> predicate,
                  class [FSharp.Core]Microsoft.FSharp.Collections.FSharpList`1<!!T> acc,
                  class [FSharp.Core]Microsoft.FSharp.Collections.FSharpList`1<!!T> sourceTemp) cil managed
{
  // Code size       69 (0x45)
  .maxstack  6
  .locals init ([0] !!T head)
  IL_0000:  nop
  IL_0001:  ldarg.2
  IL_0002:  call       !!0 [FSharp.Core]Microsoft.FSharp.Collections.ListModule::Head<!!0>(class [FSharp.Core]Microsoft.FSharp.Collections.FSharpList`1<!!0>)
  IL_0007:  stloc.0
  IL_0008:  ldarg.0
  IL_0009:  ldloc.0
  IL_000a:  callvirt   instance !1 class [FSharp.Core]Microsoft.FSharp.Core.FSharpFunc`2<!!T,bool>::Invoke(!0)
  IL_000f:  brfalse.s  IL_0031
  IL_0011:  ldarg.0
  IL_0012:  ldarg.1
  IL_0013:  ldloc.0
  IL_0014:  call       class [FSharp.Core]Microsoft.FSharp.Collections.FSharpList`1<!0> class [FSharp.Core]Microsoft.FSharp.Collections.FSharpList`1<!!T>::get_Empty()
  IL_0019:  call       class [FSharp.Core]Microsoft.FSharp.Collections.FSharpList`1<!0> class [FSharp.Core]Microsoft.FSharp.Collections.FSharpList`1<!!T>::Cons(!0,
                                                                                                                                                                class [FSharp.Core]Microsoft.FSharp.Collections.FSharpList`1<!0>)
  IL_001e:  call       class [FSharp.Core]Microsoft.FSharp.Collections.FSharpList`1<!!0> [FSharp.Core]Microsoft.FSharp.Core.Operators::op_Append<!!0>(class [FSharp.Core]Microsoft.FSharp.Collections.FSharpList`1<!!0>,
                                                                                                                                                      class [FSharp.Core]Microsoft.FSharp.Collections.FSharpList`1<!!0>)
  IL_0023:  ldarg.2
  IL_0024:  call       class [FSharp.Core]Microsoft.FSharp.Collections.FSharpList`1<!!0> [FSharp.Core]Microsoft.FSharp.Collections.ListModule::Tail<!!0>(class [FSharp.Core]Microsoft.FSharp.Collections.FSharpList`1<!!0>)
  IL_0029:  starg.s    sourceTemp
  IL_002b:  starg.s    acc
  IL_002d:  starg.s    predicate
  IL_002f:  br.s       IL_0000
  IL_0031:  ldarg.1
  IL_0032:  ldloc.0
  IL_0033:  call       class [FSharp.Core]Microsoft.FSharp.Collections.FSharpList`1<!0> class [FSharp.Core]Microsoft.FSharp.Collections.FSharpList`1<!!T>::get_Empty()
  IL_0038:  call       class [FSharp.Core]Microsoft.FSharp.Collections.FSharpList`1<!0> class [FSharp.Core]Microsoft.FSharp.Collections.FSharpList`1<!!T>::Cons(!0,
                                                                                                                                                                class [FSharp.Core]Microsoft.FSharp.Collections.FSharpList`1<!0>)
  IL_003d:  tail.
  IL_003f:  call       class [FSharp.Core]Microsoft.FSharp.Collections.FSharpList`1<!!0> [FSharp.Core]Microsoft.FSharp.Core.Operators::op_Append<!!0>(class [FSharp.Core]Microsoft.FSharp.Collections.FSharpList`1<!!0>,
                                                                                                                                                      class [FSharp.Core]Microsoft.FSharp.Collections.FSharpList`1<!!0>)
  IL_0044:  ret
} // end of method List::loop@4

We're only concerned with our recursion:

IL_0000:  nop
...
IL_000f:  brfalse.s  IL_0031
...
IL_002f:  br.s       IL_0000
IL_0031:  ldarg.1
...
IL_003d:  tail.

Just as we hoped, it's simply returning to the beginning of the method instead of calling it again.

Functionally replacing if in F#

Eliminating if from F#

Recently I was asked by a colleague if there were a better way to write a specific method this colleague was using. It was a simple method which called a couple other methods and returned a value from them. Essentially, if two conditions met specific criteria, call one of four other methods. Oh, and it was in F#.

Naturally, as C-style programmers it's easy for us to use if or switch to do what we want, but for some reason when we look at functional languages we cannot seem to reason how we should replace these two constructs with match. It must be trivial, right? We must be missing some silly detail. That's not entirely true. We're not missing anything trivial, we're just not being creative enough.

Functional languages like F# bear the advantage of being very verbose about what's going on. They're also great at implicitly typing things, and making a function read as a mathematical expression. I bolded that for a reason: if we begin to look at our code as a mathematical expression instead of code, we will hopefully see what we're missing.

Let's look at a much reduced sample of the code we were working with:

type ThingType = 
    Left = 0
    | Right = 1

member private this.methodLeftOne =
    true

member private this.methodRightOne =
    false

member private this.methodLeftTwo =
    false

member private this.methodRightTwo =
    true

member this.MatchAndIf var thingType =
    match var with
    | 1 -> if thingType = ThingType.Left then this.methodLeftOne else this.methodRightOne
    | 2 -> if thingType = ThingType.Left then this.methodLeftTwo else this.methodRightTwo
    | _ -> false

My colleague was calling the MatchAndIf function which was to return a boolean value from the two parameters. The code in the other four methods was a bit more complex, but I've simplified it here so we can see how things will turn out.

So, we're looking at a pretty simple bit of code: if var and thingType are 1 and ThingType.Left respectively, return methodLeftOne, if they're 1 and any other ThingType value, return this.methodRightOne, etc. Pretty easy to follow.

We have a slight inconsistency here, however. If thingType is set to a non-valid value, then unexpected (well, unintended) things can happen. This is not so ideal. To fix it with this code would be a mess, now we would have if ... then ... else if ... then ... else .... Sure, that does what we want, but it's really ugly for F#.

Nested match

So, the first thing we might think of to rewrite it is to use a nested match. Alright, easy enough, replace the inner if with a match.

member this.NestedMatch var thingType =
    match var with
    | 1 ->
        match thingType with
        | ThingType.Left -> this.methodLeftOne
        | _ -> this.methodRightOne
    | 2 ->
        match thingType with
        | ThingType.Left -> this.methodLeftTwo
        | _ -> this.methodRightTwo
    | _ -> false

This is obviously more F#-like. It gives us a lot more peace-of-mind, right? But we didn't fix the issue above, so let's do that.

member this.NestedMatchFixed var thingType =
    match var with
    | 1 ->
        match thingType with
        | ThingType.Left -> this.methodLeftOne
        | ThingType.Right -> this.methodRightOne
        | _ -> false
    | 2 ->
        match thingType with
        | ThingType.Left -> this.methodLeftTwo
        | ThingType.Right -> this.methodRightTwo
        | _ -> false
    | _ -> false

Wait a minute, why do we need three default (_) cases? Ah, right, because if 1 or 2 are matched, they won't fall through to the default case, and F# will get very upset if we omit it and implicitly return false. (That's not always a bad thing.)

Tuple match

Well, we might think to ourselves "I can just match on a Tuple instead." Indeed that's true, let's see how that looks.

member this.TupleMatch var thingType =
    match (var, thingType) with
    | (1, ThingType.Left) -> this.methodLeftOne
    | (1, ThingType.Right) -> this.methodRightOne
    | (2, ThingType.Left) -> this.methodLeftTwo
    | (2, ThingType.Right) -> this.methodRightTwo
    | _ -> false

Alright, that's not bad. We've gotten a lot closer to our goal. But now we have things knowing about things they shouldn't. The TupleMatch method does too many things inside it. It's looking for a var of 1 or 2 and a ThingType.

Finally Isolating Everything

The only other thing we can do to fix this (which I can tell you is the best option based on the context of what code I had) is to check thingType in our Match method, and pipe var to our methodLeft or methodRight method (whichever is appropriate).

member private this.methodLeft var =
    match var with
    | 1 -> true
    | _ -> false

member private this.methodRight var =
    match var with
    | 2 -> true
    | _ -> false

member this.FinalMatch var thingType =
    match thingType with
    | ThingType.Left -> var |> this.methodLeft
    | ThingType.Right -> var |> this.methodRight
    | _ -> false

Now each method is only responsible for checking and reporting the parts it cares about. We complied with SRP and we kept it entirely functional. Each method is responsible for looking at only the code it cares about, it's not worried about what the next method down the chain is doing.

C# Expression-Bodied Members

Using Expression-Bodied Members in C#6.0

So it's been a while since I've written a blog post (far too long if you ask me). I'll not go into too much detail, but I've been busy doing some life things. I recently changed jobs, moved, and started working on a great deal of other projects that just consume all my time, and I haven't had time to share any of my thoughts recently.

With that said, I do have something I wish to talk about at the moment, and that is a new feature found in C#6.0: Expression-Bodied Members.

This feature, in my opinion, is one of the more useful features of the recent language update. It opens a great deal of doors and has shortened a lot of my code substantially, which is always good. (For some reason, we strive to keep the number of characters/lines on our source code to a minimum.) It offers us the ability to take certain methods and properties, which would have otherwise taken up a fair amount of space, and shrink them down to a much more manageable level.

However, before we talk about this feature, we need to talk about all the parts of it. So let's begin with the most important part of an expression-bodied member: the expression.

What is an expression?

We're going to take a definition from webopedia (see http://www.webopedia.com/TERM/E/expression.html) which should sum it up fairly well:

In programming, an expression is any legal combination of symbols that represents a value.

This is a pretty basic definition, but should work to serve our needs quite well. When we use the term expression we mean a fairly simple set of instructions that return a value. Do note: I bolded "return a value" for a reason. If the set of instructions do not return a value, then they are not an expression, and cannot make up an expression-bodied member. (We'll see this isn't entirely true shortly.)

A few examples of what we mean by expressions when discussing them in C#:

2 + 5
x * 4
"EBrown"
name ?? "No Name"
person.ToString()

The last one might surprise you - yes, calling .ToString() on something is an expression, as .ToString() returns a value. The second-to-last might surprise you as well, but it's pretty simple: if name is null, then the expression evaluates to "No Name".

Do note: expressions don't have to return a non-null value. The person.ToString() call above could potentially return a null value, and that's perfectly OK. It's still an expression. The value itself has no bearing on the definition of the term, only whether or not something actually returns a valid value. This is an important concept to bear in mind, as not all of our expressions have non-null values.

So what do expressions usually look like in C#?

Any series of tokens that follow a return token, up to the first subsequent semicolon (;) are an expression. So for all of our examples above, they might look like:

return 2 + 5;
return x * 4;
return "EBrown";
return name ?? "No Name";
return person.ToString();

Mind you, expressions don't have to follow a return statement. Consider that 2+5 is still an expression in the following example:

var myString = "Some string " + (2 + 5).ToString() + " with numbers in it.";

But we also have several other expressions:

2 + 5
(2 + 5).ToString()
"Some string " + (2 + 5).ToString() + " with numbers in it."

All three of these are expressions, in their own right. All three of them also contain other expressions. This is an important concept to understand, in the expression 2 + 5, there are actually two other expressions: 2 and 5. These are both expressions as well.

What does an expression-bodied member look like, in C#?

There are two types of expression-bodied members in C#:

  • Expression-bodied readonly properties;
  • Expression-bodied methods;

Both types of expression-bodied members in C# look something like the following:

member => expression;

It's very simple, you provide a member, the "lambda" sign (=>), and an expression. You can also provide the standard member modifiers in the member itself as well. (Access modifiers, attributes, etc.) It's a regular member, it just uses a different body syntax. You should note that there are no braces in play, it's just a member and expression.

An example of a C# expression-bodied member:

public override string ToString() => $"Name: {Name}";

Note that there is no return statement. An expression-bodied member always returns a value. (Except in the case of void methods.) That is why we just talked about expressions to such detail. We need something to return. Something to give back.

What about void methods?

You can still use an expression-bodied member in a void method, it simply has to have a void return type, or be a disposable call. The following code is completely valid C#6.0:

public void MethodA() { }
public void MethodB() => MethodA(); // `MethodA()` is `void`, and `MethodB()` is `void`
public string MethodC() { return "MethodC"; }
public void MethodD() => MethodC(); // The result of `MethodC()` is disposable

The following is invalid:

public void MethodA() { }
public string MethodB() => MethodA(); // The expression returns a `void` type, but a `string` is expected
public void MethodC() => "MethodC"; // The expression returns a `void` type, but the value is not disposable

An expression-bodied member with a return type can mentally be rewritten as:

member { return expression; }

An expression-bodied member with a void return type can mentally be rewritten as:

member { expression; }

How do I use expression-bodied members?

It's pretty simple to use an expression-bodied member. You have two options: an expression-bodied readonly property, and an expression-bodied method. Both of these are trivial to use, the only difference is a minor issue in syntax.

Just like a normal readonly property, and expression-bodied readonly property only has a get-method within it. The difference is syntax. As we may recall, a normal readonly property may look something like:

public double TotalPrice { get { return Quantity * Price; } }

To convert this to an expression-bodied member, we simply replace the getter with an expression of the previous syntax:

public double TotalPrice => Quantity * Price;

This is a property bodied by an expression. You'll note that there are no parameters passed, so as far as other code is concerned it's treated just like a normal property, that only has a getter.

The only difference between a method and a property being bodied by an expression is that a method has the requisite parenthesis in the definition.

public override string ToString() { return $"Price: {Price}, Quantity: {Quantity}"; }

As a method, could be rewritten as:

public override string ToString() => $"Price: {Price}, Quantity: {Quantity}";

As you can see, in both cases we omitted the return altogether. Properties and methods that specify a non-void return type implicitly return whatever the result of the expression is.

A real life example of the benefits of expression-bodied members

For this I'm going to use a partial copy of a class I wrote for a C# library I'm working on. (I'm omitting all the comments and attributes, for brevity.)

This is (most of) a Rectangle class I wrote in a drawing library (for a clone of Windows Forms for XNA). This first version is the version without expression bodied members at all. You can find the most recent version at: https://github.com/EBrown8534/Framework/blob/master/Evbpc.Framework/Drawing/Rectangle.cs

public struct Rectangle
{
    public Rectangle(Point location, Size size)
    {
        Location = location;
        Size = size;
    }

    public int Bottom { get { return Location.Y + Size.Height; } }
    public bool IsEmpty { get { return this == Empty; } }
    public int Left { get { return Location.X; } }
    public Point Location { get; }
    public int Right { get { return Location.X + Size.Width; } }
    public Size Size { get; }
    public int Top { get { return Location.X; } }

    public override bool Equals(object obj) { return obj is Rectangle && (Rectangle)obj == this; }
    public override int GetHashCode() { return base.GetHashCode(); }

    public override string ToString()
    {
        return $"({Location.X},{Location.Y},{Size.Width},{Size.Height})";
    }

    public static bool operator ==(Rectangle left, Rectangle right)
    {
        return left.Location == right.Location && left.Size == right.Size;
    }

    public static bool operator !=(Rectangle left, Rectangle right)
    {
        return left.Location != right.Location || left.Size != right.Size;
    }

    public static readonly Rectangle Empty = new Rectangle(0, 0, 0, 0);
}

Pretty simple, right? I'm not going to discuss any of the other C#6.0 features that I've used, just know that there are some.

Now, let's see what this looks like if we replace all the smaller methods with expressions.

public struct Rectangle
{
    public Rectangle(Point location, Size size)
    {
        Location = location;
        Size = size;
    }

    public int Bottom => Location.Y + Size.Height;
    public bool IsEmpty => this == Empty;
    public int Left => Location.X;
    public Point Location { get; }
    public int Right => Location.X + Size.Width;
    public Size Size { get; }
    public int Top => Location.Y;

    public override bool Equals(object obj) => obj is Rectangle && (Rectangle)obj == this;
    public override int GetHashCode() => base.GetHashCode();
    public override string ToString() => $"({Location.X},{Location.Y},{Size.Width},{Size.Height})";
    public static bool operator ==(Rectangle left, Rectangle right) => left.Location == right.Location && left.Size == right.Size;
    public static bool operator !=(Rectangle left, Rectangle right) => left.Location != right.Location || left.Size != right.Size;

    public static readonly Rectangle Empty = new Rectangle(0, 0, 0, 0);
}

A little cleaner, yes? The horizontal space of our code has been significantly reduced for most of the methods and properties. A lot of that clutter is now gone.

Limitations of Expresison-Bodied Members

One of the major limitations of expression-bodied members is exception throwing. Exceptions cannot be thrown directly from an expression-bodied member. You can still do things that would throw exceptions, but you cannot actually throw anything. This is due to the fact that throw ... is a statement, rather than an expression.

See this Stack Overflow question and answer for more information on this limitation.

DO's and DON'Ts of Expression-Bodied Members

Here are a few of the general do's and don'ts I use when determining if I can use an expression-bodied member:

  • DO use expression-bodied members on non-auto-implemented readonly properties

    • This helps reduce clutter in code and makes the intention much more explicit. It allows future programmers to see that the property was meant to be explicitly readonly, and that a set clause should never appear for it.


  • DON'T use expression-bodied members on static readonly fields (Empty, etc.)

    • Any static readonly fields should be simple values, which should never change. By rewriting them as expression-bodied members, these simple fields are now properties, and as such slightly more overhead is attributed to them. (Especially in the case of Empty fields.)


  • DO use expression-bodied members on methods with simple return statements

    • Methods that have a single return statement written as expression-bodied methods allow the programmer to be completely explicit about the intention of the method.


  • DON'T use expression-bodied members when the expression contains multiple ternary or null-coalescing operators

    • Expression-bodied members may be used when one of either (or one of both) is found, but should not be used if more than one of either of these is found. This creates confusion and makes debugging the method much more difficult.

And the last one, which you may or may not want to adopt (I have):

  • DON'T use expression-bodied members on void methods, period

    • In the case of void methods, an expression-bodied method is misleading. It tends to hint at the idea that something should be returned (as expressions should always return a value) when in fact nothing is to be returned, by design. It creates confusion among developers.