Investigating unexpected MSBuild behavior

Recently I took latest changes from git, merged dev to my current branch and decided to run few integration tests. You know, just to be sure.

What do I see? well… this.

Could not load file or assembly ‘Microsoft.Data.Edm, Version=, Culture=neutral, PublicKeyToken=... or one of its dependencies.

That doesn’t sound right, though it’s typically easy to fix.

The first reaction is to consolidate NuGet packages in my Solution. All the installed packages have same version 5.7.0 though.

Package.config sample

Well, that happens when a merge conflict was poorly resolved. Perhaps one of the project files has a reference to an old version.

Full-text search shows that each .csproj file has correct path in the <Reference> tag.

Curiouser and curiouser!

dotPeek confirmed that the Microsoft.Data.Edm.dll version in the \bin folder is indeed incorrect. That’s odd because I don’t have an old version anywhere close to my solution. So where does it come from?

Reading raw MSBuild logs is some kind of an art, so this is where MSBuildStructuredLog comes to the rescue.

Make sure to add it to your toolbelt! This is a very handy tool for MSBuild logs analysis.

Let’s run a verbose build and look at the log. The log is very detailed, however, I think that DoubleWrites section a good starting point.

And here we go: Microsoft.Data.Edm is initially taken from local packages folder and after that suddenly overwritten by the wrong version from my .NETFramework folder.

MSBuild log

Still not clear why.

Luckily we can search through the logs. We’re interested in resolve messages here:

Resolved file path is "C:\Program Files (x86)\Microsoft WCF Data Services\


This is our “Ahaaa” moment! As you can see on a screenshot above while building project 1 (see the red number, eh?) ResolveAssemblyReferences target picks up a wrong version of that DLL which is required by project 2.

Project 1 has a reference to project 2, and indeed has no references to Microsoft.Data.Edm dll.

VS Project References

And now it’s somewhat clear what’s going on. On the screenshot below we can see a part of the build log, where unimportant log entries were omitted. First occurrences of project 1 and project 2 are marked on the screenshot.

MSbuild log. Overview

It seems that MSBuild failed to resolve a path to Microsoft.Data.Edm while preparing project 2, and that’s why an old version was used for project 1. However, project 2 has all the references configured correctly. Once the incorrect DLL version was resolved it’s beeing used for all remain projects.

I’m not sure if that’s an expected behavior. To be honest I’m a bit confused here. At least as a temporary solution I can add Edm package to project 1. That will fix my problem for now.

Write code for the reviewer, not for the compiler


I’ve been doing code reviews on a daily basis for several years for now. This activity is very different from what I do as a developer.

Most of the time I try to understand, debug, fix or update existing code. Less often developers write new code from scratch. I think it’s safe to say that we all know how to work with a code written by another human.

One might want to say that if we know how to work with other people’s code, we can be good at reading and understanding it during the code review process.

Unfortunately, there is a difference. When we work with a code we have it opened in our editor or IDE. It doesn’t matter if it’s a modern heavy IDE or a lightweight editor. What’s important is that this is a tool which we are familiar with.

We know how to get extra information about any line code on the screen. In my case, it’s a Visual Studio with ReSharper and several more extensions. I have color coded info, I have tooltips and I can navigate through the code.

However, when reviewing a Pull Request on GitHub I have just a basic syntax highlighting in the editor.

Pull Request sample


Modern programming languages allow a developer to skip some symbols and take some shortcuts. It’s different for every language, I’ll use C# as an example in this post.

Let’s look at this snippet:

public void ProcessSomething(Guid accountId)
  AccountBalance accountBalance = 
        .GetAccountBalanceAsAtDate<Guid>(accountId: accountId, date: this.DateUtils.Yesterday);

Here we have a short method implementation. C# keywords are in blue-ish color, method names are in magenta, the rest is gray.

Even if you don’t know C# you can read and understand what’s going on there.

If you do know C# you’d notice that this code is rather redundant. However, this is pretty much how compiler sees your code. Ok, almost :)

Let me read this code. I’ll try to read all the information which I see here.

This method takes an account id (GUID). First it calls the GetAccountBalanceAsAtDate generic method with Guid generic parameter. This method is an instance method of field balanceCalculator. This is a current class instance field.
There are two parameters passed to that method. The first one is an account id, the parameter name is accountId. The second parameter name is date, and we pass the value of the property called Yesterday of the current class instance property called DateUtils.

The result is assigned to the local variable accountBalance of AccountBalance type. After that the result is passed to the instance method CalculateFees.

That’s a lot of information, right? We know types, parameter names, we know that methods and properties are not static and so on.

We still don’t know what type Yesterday is, but the rest is clear. We have plenty of information about the logic of the method as well as about types and even some details about GetAccountBalanceAsAtDate method signature.

Getting simpler

When I look at this code in my IDE I see that some code is marked as redundant (grayed out):

Same Code in IDE

What if I apply suggested “Remove redundant code” refactorings? We’d loose some information about this method. I’m going to be careful here.

Argument names

Explicit argument names here are probably the least important information. Even more, it’s a bit misleading. Are the arguments optional or not? We don’t know that. (Well, I do know, and they are not optional).

Let’s remove them:

Code in IDE, argument names omitted

I’m going to repeat our exercise one more time:

This method takes an account id (GUID). First it calls the GetAccountBalanceAsAtDate generic method with Guid generic parameter. This method is an instance method of field balanceCalculator. This is a current class instance field.
There are two parameters passed to that method. The first one is an account id, and as a second parameter we pass the value of the property called Yesterday of the current class instance property called DateUtils.

The result is assigned to the local variable accountBalance of AccountBalance type. After that the result is passed to the instance method CalculateFees.

Hm, looks like we didn’t lose much information, right?

Explicit variable type

When reviewing this snippet we don’t know much about AccountBalance type. Is it a struct or a class? What kind of data does it contain?

In fact, we can just omit the type declaration here.

Code in IDE, use var instead of Explicit type

So far so good. We don’t know the type, but we do know that the type is correct. We were able to pass it to CalculateFees method, and our code compiles.

Generic parameter type

What kind of information could the reviewer gather from the explicit generic parameter type specification?

Honestly, I don’t know. Perhaps we can figure out that the method is generic. Well, good to know, but as long as the compiler can build the code, it doesn’t matter for the reviewer.

After all the reviewer is not trying to catch compilation errors, eh?

Code in IDE, implicit generic parameter type

this qualifier

This is a very painful moment.

There is a StyleCope rule SA1101: PrefixLocalCallsWithThis which originally aimed against underscore prefixes for instance variables.

First of, all we should understand, that the compiler does know that CalculateFees() is an instance method of the current class. It does know where DateUtils comes from.

Honestly, how often do you need to know if balanceCalculator is an instance variable? That might be important when you editing the code. Not very often, but I can buy this argument.

But is that important during the code review? I’d say that it’s not. Id doesn’t matter for this method. The method is short enough so we can see that balanceCalculator is not declared inside the method. If the method was longer, it would not be important anyway. What’s important is that the balanceCalculator was used to calculate the balance.

Nobody would argue that the code outside of the editor contains less information about its structure. The absence of this knowledge is not that bad, though.

For example, When reviewing the code outside of the editor no one can tell what’s going on here:


Each *.Car could be either a property of current class instance property or a static property of another class or an enum value. this. qualifier will help us with the first option, but that’s it.

In your IDE you’ll spend a second to find out, right? I’ll use color codes:

Code in IDE, no redundant code

You can hover or navigate to it. Doesn’t really matter.

When you read this code as a plain text you can only tell that the method Foo is doing something with the car. You have lost some information, and you only have a semantics of the code here.

And this is just fine. You can focus on what the code does, not on how it does. The “how” part is checked by the compiler.

It requires some courage, but I’m going to remove all this. prefixes.

Final look

Code in IDE, no redundant code

So, what do we have here? As we learned, as a reviewer we need to focus on the logic, and we shouldn’t try to chase any errors which can be caught by the compiler.

Let’s read it one more time:

The method takes and account Id as an argument, calls GetAccountBalanceAsAtDate method of the balanceCalculator. accounId is passed as a first parameter, the second parameter is a value Yesterday of DateUtils. The result of that method call is used as a parameter for CalculateFees method.

Now scroll up and compare with the first attempt. Much shorter, right?

Ok, the reviewer has no information about types, about the nature of methods and properties. They do not know what DayUtils is. It might be an enum, or a static class or anything else.

The only information that reviewer has is the logic of the method. And now they can focus on it because that’s what is important here after all. The logic, not the AST structure.


Please, let the compiler to its job, and help the reviewer focus on what does matter here.

Feel free to comment on this if you agree or disagree.

Dev environment 2016. Windows.


I’ve changed a job last month and had to build up my dev environment from scratch again. While doing that I decided to write down some thoughts about it.

I guess it might be interesting to look back at some point and see how does it evolve.


At my previous employer, we were very into Virtual Machines. We had different base VMs which every developer can download.

That’s extremely handy when a new hire has nothing to do, but to install just a couple of tools that are not standard, and enter some credentials.

You remember those dialogs:

— I can’t build the project. Packages are missing…

— Oh, yep, you need to add this private NuGet feed.

— I can’t run the project locally.

— Yeah, I think you need so put these lines into your hosts file.

Well, now it’s all gone.

It’s not only limited to this scenario. You want to experiment with a new unstable version of the framework (yes, .NET Core RC-final-almost-stable, I’m talking about you) and you don’t want to mess up with your dev machine?

Just fire a new VM up.

Got a neat idea for a hackathon, but you think that JDK is not what you need on your computer? Giving a tech demo on the local meetup?

A VM comes to the rescue.

Got a new computer? Just copy the VM over and you’re up to speed in 20 minutes.

Back to the topic

So, what do I have on my base VM?


I’m a .NET web developer, so nothing special here:

  • .NET framework 4.5.2 and 4.6
  • Node.js (npm, gulp)

IDE and editors


File Managers and command line shell


Source control


GitKraken is quite heavy and not super fast as most of the electron.js based tools are, but I find it’s history tree view very readable. The merge tool is not bad at all.

I do most of the git related operations in git bash, though.

Debugging and profiling


  • DotPeek. A free .NET decompiler.
  • DotMemory .NET memory profiler.
  • WinDbg.
  • Fiddler. A free web debugging proxy.
  • REST and Http clients. I use two, can’t decide which one I prefer over an other.
  • LINQPad A .NET programmer’s playground.


  • Slack
  • Skype

Other tools

Web tools and services

Besides all the tools above which I have installed locally there are web services I use on a pretty much daily basis.

  • An easy to use HTTP request inspector.
  • AppVeyor. A free CI/CD service for my open source projects.
  • A super awesome regular expressions builder and debugger.
  • Toggl. A time tracker.

Batch install

Most of the tools could be installed from Chocolatey gallery.

choco install dotnet4.5.2 linqpad -y

I prefer to have all the tools grouped into .config files:

<!-- commandline-tools.config -->
<?xml version="1.0" encoding="utf-8"?>
  <package id="git" />
  <package id="far" />
  <package id="nuget.commandline" />
  <package id="conemu" />

and they could be installed all together.


A call to action

Are there any tools around which are worth to try?

Please share in comments. I’m always keen on trying new things.

Thoughts on C# 7 Local Functions

Frankly when I first saw that C# 7 will come with new local functions I thought that that’s just a nice and a compact way of defining local helpers. In fact, it’s much more interesting and useful feature. Today I’m going to talk about it in more details.

Let’s start with a brief overview of the current situation.

Current options

Private methods

The first option that existed in C# 1 is having a private method.

class Bar
    public void Foo(int[] numbers)
        foreach(var i in numbers)
    private string AsPrintable(int i) =>  $"I have {i} here";

That’s a clean and simple solution. It has few issues, though.

AsPrintable might have no sense outside of Foo method, but it’s accessible for every other method inside the class. It will be taken into account by IntelliSense.

Private method discoverable via IntelliSense

Func and Action

We can try to hide our helper inside the scope of Foo method by converting it to Func<int, string>:

 class Bar
     public void Foo(int[] numbers)
         Func<int, string> asPrintable = i => $"I have {i} here"; 
         foreach (var i in numbers)

Any disadvantages? Yep, a lot.

The call is unnecessary expensive: it will produce a couple of allocations.

There is no elegant way to define recursive lambda:

Lambda can not be recursive

We have to use an ugly trick:

Lambda can not be recursive

And the last, but not least is the fact that lambdas are very limited. You cannot use
out, ref,params and optional parameters. They cannot be generic.

There is a bright side, though, a lambda can capture variables from enclosing method aka closure.

Local functions

Local functions can be defined in the body of any method, constructor or property’s getter, and setter.

Since it will be transformed by compiler to regular private static method:

Local function decompiled

there will be no overhead of calling it and it can have all the properties which regular method declaration can have: it can be asynchronous, it can be generic, it can be dynamic.

Ok, there is a difference. Local functions can not be static. And local functions can capture variables from enclosing block:

class Bar
    public void Foo(int[] numbers)
        var length = numbers.Length;
        string Length() => $"length is {length}";

Useful bits

As Bill Wagner wrote local function is a perfect solution for iterators and asynchronous methods when it comes to parameters validation.

The following code will throw an exception right away and not in a lazy manner.

public IEnumerable<T> AsEnumerable<T>(params T[] items)
    if (items == null) throw new ArgumentException(nameof(items));

    IEnumerable<T2> Enumerate<T2>(T2[] array)
        foreach(var item in array)
            yield return item;

    return Enumerate(items);

Other observations:

Local functions support Caller Info Attributes

 public static void SlimShady()
     void Hi([CallerMemberName] string name = null)
         Console.WriteLine($"Hi! My name is {name}");


Fun fact. You can declare a local function with the same name as an existing private method and local function will hide it. Same as for lambdas, though.

Local function has priority over private method


It’s hard to imagine modern development without continuous intergation and unit-tests.

At work I hardly pay attention on the process, it just works: I push code to GitHub, later on TeamCity picks up changes and starts the build, and few minutes after I receive Slack or email notification about the result. However for my personal projects things are different. I’m using free plan on AppVeyor. It works pretty well except the fact that your build might stay in the queue for a while.

Last week I found a nice application called CatLight. That’s a tiny tool wich shows you build notifications in a tray. Ok, not that tiny as it’s built on electron and .NET :) Works for both Windows and OSX.

Setup is very straightforward: provide your AppVeyor API key


Select all the projects you want to be notified about


Select all the events you want to be aware of


Trigger the build


and wait for the green light.