Creating an IOC Container for ASP.NET Core

I recently added support for ASP.NET Core to my Tact.NET IOC Container, and I thought that I would share some of the interesting requirements I discovered while doing so. I had originally expected the default ASP.NET Core container would follow the same rules as the official Microsoft Unity container, but that turned out not to be the case!

1) Register is first in win.

The Unity container was last in win, and it would completely disregard the original registration. With ASP.NET Core you need to preserve the original registration and then treat all subsequent registrations as addition registrations that will only be resolved when ResolveAll is invoked, similar to keyed registrations in Unity. Which brings us to our next difference...

public class RegisterIsFirstInWinTests

{

    [Fact]

    public void Unity()

    {

        var log = new EmptyLog();

        using (var container = new TactContainer(log))

        {

            container.RegisterSingleton<IExample, ExampleA>();

            container.RegisterSingleton<IExample, ExampleB>();

            var example = container.Resolve<IExample>();

            Assert.IsType<ExampleB>(example);

        }

    }

    [Fact]

    public void AspNetCore()

    {

        var log = new EmptyLog();

        using (var container = new AspNetCoreContainer(log))

        {

            container.RegisterSingleton<IExample, ExampleA>();

            container.RegisterSingleton<IExample, ExampleB>();

            var example = container.Resolve<IExample>();

            Assert.IsType<ExampleA>(example);

        }

    }

    public interface IExample

    {

        string Name { get; }

    }

    public class ExampleA : IExample

    {

        public string Name => nameof(ExampleA);

    }

    public class ExampleB : IExample

    {

        public string Name => nameof(ExampleB);

    }

}

How to make a dotnet CLI Tool

Good news, everyone! It is remarkably easy to make a new dotnet CLI (Command Line Interface) tool! I recently created a CLI tool for one of my new projects, Tact.NET RPC, and in this post I will be referencing that project as my example.

The Basics

Step 1) Create your CLI Console App

All you have to do is...

1. Create a normal .NET Core Console App.
   • NOTE: Currently, the dotnet CLI only supports netcoreapp1.0
2. Rename the assembly to be prefixed with "dotnet-"
3. dotnet pack the project and put the package in your local NuGet package source

...that is it! It is literally that easy to create your CLI tool!

Recommendation: use Microsoft.Extensions.Configuration to parse your command line arguments in a standard way.

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>

    <OutputType>Exe</OutputType>

    <TargetFramework>netcoreapp1.0</TargetFramework>

    <AssemblyName>dotnet-tactrpcgen</AssemblyName>

    <PackageId>Tact.Rpc.Generator</PackageId>

    <Version>1.0.3</Version>

  </PropertyGroup>

  <ItemGroup>

    <PackageReference Include="Microsoft.Extensions.Configuration.CommandLine" Version="1.1.1" />

  </ItemGroup>

</Project>

Step 2) Consume your CLI Tool NuGet Package

Edit your csproj file and add a DotNetCliToolReference element that references your package.

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>

    <TargetFramework>netstandard1.6</TargetFramework>

  </PropertyGroup>

  <ItemGroup>

    <DotNetCliToolReference Include="Tact.Rpc.Generator" Version="1.0.3" />

  </ItemGroup>

</Project>

Now you are able to invoke your console app via the dotnet command line whenever it is executed in the same path as the csproj.

That's it; it really is that easy!

Development Tips

Here is a simple way to automate the creation and consumption of your CLI tool NuGet package during development.

C# String Interpolation Performance

Time for a follow up to my String.Concat vs String.Format Performance post from back in 2014!

I recently found out that string interpolation is not nearly as efficient as I would have thought. I also suspected that it was just doing a string concatenation, but it is actually doing a string format. This leads to a pretty significant performance degradation; the following test runs one million iterations of each.

Number of Args	Interpolation Milliseconds	String.Format Milliseconds	String.Concat Milliseconds	String Add Milliseconds	StringBuilder Milliseconds
2	262	260	19	18	34
3	367	367	25	24	35
4	500	513	31	32	41
5	646	635	67	66	44
6	740	723	79	76	49
7	802	819	86	85	52
8	938	936	97	98	58

So, what's the lesson? Don't use string interpolation in high performance areas (such as your logger)!

Enjoy,
Tom

WebSocket Support for .NET Core

Full WebSocket support is coming with .NET Standard 2.0, which has now been delayed until Q3. In the meantime, there are still a few options to work with...

• Third Party
  • Client - WebSocket4Net - Beta
  • Server - Fleck - Pending PR
• Microsoft
  • Client - System.Net.WebSockets.Client - v4.3.0
  • Server - Microsoft.AspNetCore.WebSockets.Server - v0.1.0

If you want to use Microsoft.AspNetCore.WebSockets.Server, I have added a middle ware wrapper that feel a lot more like Fleck:

• Tact.AspNetCore.WebSockets.Server

public void Configure(IApplicationBuilder app)

{

    app.UseWebSockets();

    app.UseWebSocketHandler("test", connection =>

    {

        // Register your listeners here

        connection.OnMessage = m =>

        {

            if (m == "hi")

                connection.SendAsync("bye");

        };

    });

}

Enjoy,
Tom

Run .NET Core xUnit tests from ReSharper in VS2015

Visual Studio 2017 is literally only a few days away from release; so it might be a little late, but I finally figured out how to run .NET Core xUnit tests from ReSharper in VS2015! Good News: If you can't upgrade to VS2017 right away, then at least you can still run your unit tests!

Just make sure that the following is included in your project.json file (with the appropriate runtime):

{

  "testRunner": "xunit",

  "dependencies": {

    "dotnet-test-xunit": "2.2.0-preview2-build1029",

    "xunit": "2.2.0"

  },

  "frameworks": {

    "netcoreapp1.0": {

      "imports": "dnxcore50"

    }

  },

  "runtimes": {

    "win10-x64": {}

  }

}

Enjoy,
Tom

.NET Standard Adoption as of January 2017

Updated 2/16 to include Elasticsearch

As should be obviously from my recently blog posts, I have really been enjoying working with .NET Core. Clearly I am not alone, as a significant number of libraries have been porting over to the .NET Standard.

Below is a list libraries that have added support for the .NET Standard, meaning that they should be able to run cross platform on both Windows and Linux.

While I have not yet had the opportunity to try all of the libraries listed below, I have had great luck with the ones that I have tested, and I am simply ecstatic to see this list growing as fast as it is.

Technology	NuGet Package	.NET Standard Support
Autofac	Autofac	Released for 1.1
Cassandra	DataStax C# Driver for Apache Cassandra	Released for 1.5
Couchbase	Couchbase SDK 2.0	Beta for 1.5
Elasticsearch	Elasticsearch.Net	Released for 1.3
Kafka	Confluent.Kafka	Preview for 1.3
log4net	Apache log4net	Released for 1.3
MongoDB	MongoDB.Driver	Released for 1.4
NLog	NLog	Beta for 1.3
RabbitMQ	RabbitMQ.Client	Released for 1.5
RavenDB	RavenDB Client	Released for 1.3
Redis	StackExchange.Redis	Released for 1.5
Sqlite	Microsoft.EntityFrameworkCore.Sqlite	Released for 1.3
WebSocket Client	WebSocket4Net	Released for 1.3

How have these libraries been working out for you? Is there a better option than what I have listed? Please leave a comment and let me know!

Enjoy,
Tom

.NET JsonContent for HttpClient

.NET already comes with a nice collection of HttpContent serializers, but it lacks a JsonContent type. A common solution is to just serialize their payload to a JSON string and that insert that into an instance of StringContent. However, this means that you need to remember to set your headers, and it is a little bit inefficient because of how it creates multiple strings and buffers for each payload.

I have create a simple implementation of JsonContent that uses Json.NET and pooled memory streams. The result is between 2% and 10% faster, and causes ~50% fewer garbage collections.

Check out the implementation in Tact.NET:

• Source - JsonContent.cs
• Tests - JsonContentTests.cs

Enjoy,
Tom

2016 Retrospective

.NET

It has been a great year for .NET development! A Visual Studio Community is fully featured, .NET Core has arrived, and everything is open source. Regarding .NET Core, I am really enjoying working with it, and I simply cannot wait to get deeper into the Linux world.

Blog

I finally had to downgrade from three posts per month to only two posts per month. Unfortunately writing quality blog posts tasks time, and that was not something that I had in great abundance this year. Fortunately, I do think that the majority of posts this year were very high quality, especially when you look at the most recent ones. I have been working a lot with performance optimization, and have really been enjoying profiling and digging deep into code to see exactly what it is doing and why.

Tact.NET

I am very happy to have launched Tact.NET this year! I have always really enjoyed creating frameworks, so rather than continue to write one off posts on this blog I decide to put all of my extracurricular worth together under one repository. I am really enjoying making Tact, and I have every intention of continuing to grow it.

QQ Cast

Wow, the QQ Cast is back! We took a hiatus for the second half of 2015, but in 2016 we recorded 43 podcasts. Next week is actually going to be our 100th episode, be sure to check it out!

Happy new year,
Tom

Object Pooling and Memory Streams

The theme of this year, which I will talk about in my 2016 retrospective, has been optimization. It's been a fun journey, and I have really enjoyed getting down and dirty with profiling garbage collection, using spin waits, and aggressive inlining.

I want to end this year on a fun note: object pooling.

A great use case for this would be making HTTP requests with serialized objects. When you serialize an object, and then place it in a HttpContent object, you are probable creating several buffers (byte arrays) each time. For example, if you are using Newtonsoft to serialize an object and then adding that to a string content object for your request, then you are probably using more memory than you need. But that is getting ahead of ourselves...

Come back next week for a blog post about efficient JSON Content serialization!

For now, let's focus on building an object pool. Really all that we need is a preallocated array to store unused objects in, and then a super efficient thread safe data structure to pool (get and set) those objects.

How does pooling memory streams help us?

When you create a MemoryStream, it creates a byte array. As that byte array grows, the memory stream resizes it by allocating a new larger array and then copying your bytes into it. This is inefficient not only because it creates new objects and throws the old ones away, but also because it has to do the leg work of copying the content each time it resizes.

How can we reuse memory streams? Just set the length to zero!

Internally this will just set an index and empty the array, but the internal data structures will be preserved for future use. Thus, by putting memory streams into an object pool, we can drastically increase our efficiency.

Here is a demo of using the Tact.NET ObjectPool to pool MemoryStreams...

[Fact]

public void MemoryStreamPoolDemo()

{

    using (var pool = new ObjectPool<MemoryStream>(100, () => new MemoryStream()))

    {

        var memoryStream1 = pool.Acquire();

        memoryStream1.SetLength(0);

        Assert.Equal(0, memoryStream1.Capacity);

        memoryStream1.Write(new byte[] {1, 0, 1, 0, 1}, 0, 5);

        var array1 = memoryStream1.ToArray();

        Assert.Equal(5, array1.Length);

        Assert.Equal(1, array1.First());

        Assert.Equal(1, array1.First());

        pool.Release(memoryStream1);

        var memoryStream2 = pool.Acquire();

        Assert.Same(memoryStream1, memoryStream2);

        memoryStream2.SetLength(0);

        Assert.Equal(256, memoryStream2.Capacity);

        memoryStream2.Write(new byte[] { 0, 1, 0 }, 0, 3);

        var array2 = memoryStream2.ToArray();

        Assert.Equal(3, array2.Length);

        Assert.Equal(0, array2.First());

        Assert.Equal(0, array2.First());

    }

}

Enjoy,
Tom

The Performance Cost of Boxing in .NET

I recently had to do some performance optimizations against a sorted dictionary that yielded some interesting results...

Background: I am used to using Tuples a lot, simply because they are easy to use and normally quite efficient. Please remember that Tuples were changed from structs to classes back in .NET 4.0.

Problem: A struct decreased performance!

I had a SortedDictionary that was using a Tuple as a key, so I thought "hey, I'll just change that tuple to a struct and reduce the memory usage." ...bad news, that made performance WORSE!

Why would using a struct make performance worse? It's actually quite simple and obvious when you think about it: it was causing comparisons to repeatedly box the primitive data structure, thus allocating more memory on the heap and triggering more garbage collections.

Solution: Use a struct with an IComparer.

I then created a custom struct and used that; it was must faster, but it was still causing boxing because of the non-generic IComparable interface. So finally I added a generic IComparer and passed that into my dictionary constructor; my dictionary then ran fast and efficient, causing a total of ZERO garbage collections!

See for yourself:

The Moral of the Story

Try to be aware of what default implementations are doing, and always remember that boxing to object can add up fast. Also, pay attention to the Visual Studio Diagnostics Tools window; it can be very informative!

Here is how many lines of code it took to achieve a 5x performance increase:

private struct MyStruct

{

    public MyStruct(int i, string s) { I = i; S = s; }

    public readonly int I;

    public readonly string S;

}

private class MyStructComparer : IComparer<MyStruct>

{

    public int Compare(MyStruct x, MyStruct y)

    {

        var c = x.I.CompareTo(y.I);

        return c != 0 ? c : StringComparer.Ordinal.Compare(x.S, y.S);

    }

}

Test Program

I have written some detailed comments in the Main function about what each test is doing and how it will affect performance. Let's take a look...

10x faster than Delegate.DynamicInvoke

This is a follow up to my previous blog posts, Optimizing Dynamic Method Invokes in .NET, and Dynamically Invoke Methods Quickly, with InvokeHelpers.EfficientInvoke. Basically, I have re-implemented this for Tact.NET in a way that makes it smaller, faster, and compatible with the .NET Standard.

So, how much faster is this new way of doing things? EfficientInvoker.Invoke is over 10x faster than Delegate.DynamicInvoke, and 10x faster than MethodInfo.Invoke.

Check out the source on GitHub:

• EfficientInvoker.cs
• EfficientInvokerTests.cs

Simple Explanation

Here is an example of a method and a class that we might want to invoke dynamically...

public class Tester

{

    public bool AreEqual(int a, int b)

    {

        return a == b;

    }

}

...and then here is the code that the EfficientInvoker will generate at runtime to call that method:

public static object GeneratedFunction(object target, object[] args)

{

    return (object)((Tester)target).AreEqual((int)args[0], (int)args[1]);

}

See, it's simple!

IOC Container for Tact.NET

Autofac now supports .NET Core, but other IOC frameworks such as Ninject and Unity have yet to port over. While I was looking into IOC frameworks for .NET Core, I had a bad idea...I, for fun, wrote my own Container in Tact.NET!

So, why did I do this? Honestly, it was just a fun academic exercise! I do think that this is a pretty good container, and I intend to use it in some of my personal projects. Would I recommend that YOU use this? Probably not yet, but I would invite you take a look and offer feedback!

Container Design

I have broken the container into two interfaces: IContainer for registration, and IResolver for consumption. There is a abstract class, ContainerBase, that can be inherited to easily create a container that matches other frameworks; for example, I intend to create a IDependencyResolver for ASP.NET.

You may notice that the IContainer does not have any lifetime management methods, that is because ALL of them are implemented as extension methods...

Registrations

To create a new lifetime manager you have to implement the IRegistration interface. There are already implementations for quite a few:

• InstanceRegistration
• PerResolveRegistration
• PerScopeRegistration
• SingletonRegistration
• TransientRegistration

Resolution Handlers

The last part of the container is the IResolutionHandler interface. These resolution handlers are used when an exact registration match is not found during dependency resolution. For example, the EnumerableResolutionHandler will use ResolveAll to get a collection of whatever type is being requested. Another very different example, the ThrowOnFailResolutionHandler will cause an exception to be thrown when no match can be found.

• EnumerableResolutionHandler
• FuncResolutionHandler
• LazyResolutionHandler
• ThrowOnFailResolutionHandler
• UnregisteredResolutionHandler

I think that is a pretty good start, but I am hoping that this will continue to grow with time.

Enjoy,
Tom

Introducing Tact.NET

I have decided to create a project to consolidate all of the utilities that I have authored over the years on this blog...

Tact.NET - A tactful collection of utilities for .NET development.

I believe that this will give me the opportunity to update old code more often, as well as develop new utilities faster. For example, the there is already an ILog interface that optimizes (thank you, Jeremy) the Caller Information Extensions I wrote about about back in May.

Everything that I add to this project will be build for the .NET Standard Library, and should support .NET Core on all platforms. Expect to see NuGet packages soon, and hopefully many more blog posts to come.

Enjoy,
Tom

Host HTTP and WebSockets on the Same Port in ASP.NET

How do you support WebSocket connections on the same port as your HTTP server in .NET? It turns out that this is not that hard, and you even have several choices to do so...

Option 1: TCP Proxy

You could use a TCP proxy port to divide traffic between the two targets. For example, all traffic would come in to port 80, but then HTTP traffic would be routed internally to 8001 and WS traffic to 8002. This is useful because it would allow you to use multiple technologies (in the example on their site, both NancyFX and Fleck) to host your web servers.

• github.com/lifeemotions/websocketproxy

Option 2: SignalR

SignalR is great because of all the backwards compatibility that it supports for both the server and client. However, it is not the most lightweight framework. If you choose to use it, then it will absolutely support both HTTP and WS.

• asp.net/signalr

Option 3: Owin.WebSocket *My Favorite*

Owin supports WebSockets, and that is exactly what SignalR uses to host its WS connections. The awesome Mr. Bryce Godfrey extracted the Owin code from SignalR into a much smaller library called Owin.WebSocket.

The ONLY thing that I did not like about this implementation was that is uses inheritance to define endpoints, whereas I much prefer the ability to use delegates and lambdas. Because of this, I created Owin.WebSocket.Fleck, which allows you to use the Fleck API to map your WebSockets to an Owin context. A pull request is open to merge this into the main repository.

• github.com/bryceg/Owin.WebSocket

Enjoy,
Tom

.NET Asynchronous Parallel Batch Processor

Last year, I wrote about how to handle dynamically sized batches of data in an asynchronous manner. That original implementation used an abstract base class, and only supported a single background processing thread. I recently updated that implementation to support lambdas rather than requiring inheritance, and support a dynamic number of background threads.

...basically, this is a ConcurrentQueue that supports taking a lambda and thread count to asynchronously process enqueued items.

Unit Tests

public class ParallelProcessorTests

{

    [Fact]

    public async Task NoDisposeTimeout()

    {

        var results = new ConcurrentQueue<int>();

        using (var processor = new ParallelProcessor<int>(2, async (i, token) =>

        {

            await Task.Delay(200, token).ConfigureAwait(false);

            results.Enqueue(i);

        }, disposeTimeoutMs: 0))

        {

            processor.Enqueue(1);

            processor.Enqueue(2);

            processor.Enqueue(3);

            processor.Enqueue(4);

            processor.Enqueue(5);

            await Task.Delay(300).ConfigureAwait(false);

        }

        Assert.Equal(2, results.Count);

    }

    [Fact]

    public void MaxParallelizationLimit()

    {

        const int parallelism = 3;

        var results = new ConcurrentQueue<Tuple<int, int>>();

        var active = 0;

        using (var processor = new ParallelProcessor<int>(parallelism, async (i, token) =>

        {

            Interlocked.Increment(ref active);

            await Task.Delay(200, token).ConfigureAwait(false);

            var currentActive = Interlocked.Decrement(ref active) + 1;

            var tuple = Tuple.Create(currentActive, i);

            results.Enqueue(tuple);

        }))

        {

            processor.Enqueue(1);

            processor.Enqueue(2);

            processor.Enqueue(3);

            processor.Enqueue(4);

            processor.Enqueue(5);

        }

        Assert.Equal(5, results.Count);

        var maxParallelism = results.Max(t => t.Item1);

        Assert.Equal(parallelism, maxParallelism);

    }

    [Fact]

    public void BatchProcessor()

    {

        var results = new List<Tuple<long, List<int>>>();

        var sw = Stopwatch.StartNew();

        using (var processor = new BatchParallelProcessor<int>(1, 2, async (ints, token) =>

        {

            await Task.Delay(100, token).ConfigureAwait(false);

            var tuple = Tuple.Create(sw.ElapsedMilliseconds, ints);

            results.Add(tuple);

        }))

        {

            processor.Enqueue(1);

            processor.Enqueue(2);

            processor.Enqueue(3);

            processor.Enqueue(4);

            processor.Enqueue(5);

        }

        Assert.Equal(3, results.Count);

        Assert.Equal(2, results[0].Item2.Count);

        Assert.Equal(1, results[0].Item2[0]);

        Assert.Equal(2, results[0].Item2[1]);

        Assert.True(results[0].Item1 < results[1].Item1);

        Assert.Equal(2, results[1].Item2.Count);

        Assert.Equal(3, results[1].Item2[0]);

        Assert.Equal(4, results[1].Item2[1]);

        Assert.True(results[1].Item1 < results[2].Item1);

        Assert.Equal(1, results[2].Item2.Count);

        Assert.Equal(5, results[2].Item2[0]);

    }

}

Dynamically Invoke Methods Quickly, with InvokeHelpers.EfficientInvoke

In my previous blog post, I talked about Optimizing Dynamic Method Invokes in .NET. In this post, we will use that information to create a static helper method that is twice as fast as MethodInfo.Invoke.

Basically, we create and cache a delegate in a concurrent dictionary, and then cast both it and it's arguments to dynamics and invoke them directly. The concurrent dictionary introduces overhead, but it still more than twice as fast as calling MethodInfo.Invoke. Please note that this method is highly optimized to reduce the use of hash code look ups, property getters, closure allocations, and if checks.

let's take a look at the code...

InvokeHelpers.EfficientInvoke

public static class InvokeHelpers

{

    private const string TooManyArgsMessage = "Invokes for more than 10 args are not yet implemented";

    private static readonly Type VoidType = typeof(void);

    private static readonly ConcurrentDictionary<Tuple<string, object>, DelegatePair> DelegateMap 

        = new ConcurrentDictionary<Tuple<string, object>, DelegatePair>();

    public static object EfficientInvoke(object obj, string methodName, params object[] args)

    {

        var key = Tuple.Create(methodName, obj);

        var delPair = DelegateMap.GetOrAdd(key, CreateDelegate);

        if (delPair.HasReturnValue)

        {

            switch (delPair.ArgumentCount)

            {

                case 0: return delPair.Delegate();

                case 1: return delPair.Delegate((dynamic)args[0]);

                case 2: return delPair.Delegate((dynamic)args[0], (dynamic)args[1]);

                case 3: return delPair.Delegate((dynamic)args[0], (dynamic)args[1], (dynamic)args[2]);

                case 4: return delPair.Delegate((dynamic)args[0], (dynamic)args[1], (dynamic)args[2], (dynamic)args[3]);

                case 5: return delPair.Delegate((dynamic)args[0], (dynamic)args[1], (dynamic)args[2], (dynamic)args[3], (dynamic)args[4]);

                case 6: return delPair.Delegate((dynamic)args[0], (dynamic)args[1], (dynamic)args[2], (dynamic)args[3], (dynamic)args[4], (dynamic)args[5]);

                case 7: return delPair.Delegate((dynamic)args[0], (dynamic)args[1], (dynamic)args[2], (dynamic)args[3], (dynamic)args[4], (dynamic)args[5], (dynamic)args[6]);

                case 8: return delPair.Delegate((dynamic)args[0], (dynamic)args[1], (dynamic)args[2], (dynamic)args[3], (dynamic)args[4], (dynamic)args[5], (dynamic)args[6], (dynamic)args[7]);

                case 9: return delPair.Delegate((dynamic)args[0], (dynamic)args[1], (dynamic)args[2], (dynamic)args[3], (dynamic)args[4], (dynamic)args[5], (dynamic)args[6], (dynamic)args[7], (dynamic)args[8]);

                case 10: return delPair.Delegate((dynamic)args[0], (dynamic)args[1], (dynamic)args[2], (dynamic)args[3], (dynamic)args[4], (dynamic)args[5], (dynamic)args[6], (dynamic)args[7], (dynamic)args[8], (dynamic)args[9]);

                default: throw new NotImplementedException(TooManyArgsMessage);

            }

        }

        switch (delPair.ArgumentCount)

        {

            case 0: delPair.Delegate(); break;

            case 1: delPair.Delegate((dynamic)args[0]); break;

            case 2: delPair.Delegate((dynamic)args[0], (dynamic)args[1]); break;

            case 3: delPair.Delegate((dynamic)args[0], (dynamic)args[1], (dynamic)args[2]); break;

            case 4: delPair.Delegate((dynamic)args[0], (dynamic)args[1], (dynamic)args[2], (dynamic)args[3]); break;

            case 5: delPair.Delegate((dynamic)args[0], (dynamic)args[1], (dynamic)args[2], (dynamic)args[3], (dynamic)args[4]); break;

            case 6: delPair.Delegate((dynamic)args[0], (dynamic)args[1], (dynamic)args[2], (dynamic)args[3], (dynamic)args[4], (dynamic)args[5]); break;

            case 7: delPair.Delegate((dynamic)args[0], (dynamic)args[1], (dynamic)args[2], (dynamic)args[3], (dynamic)args[4], (dynamic)args[5], (dynamic)args[6]); break;

            case 8: delPair.Delegate((dynamic)args[0], (dynamic)args[1], (dynamic)args[2], (dynamic)args[3], (dynamic)args[4], (dynamic)args[5], (dynamic)args[6], (dynamic)args[7]); break;

            case 9: delPair.Delegate((dynamic)args[0], (dynamic)args[1], (dynamic)args[2], (dynamic)args[3], (dynamic)args[4], (dynamic)args[5], (dynamic)args[6], (dynamic)args[7], (dynamic)args[8]); break;

            case 10: delPair.Delegate((dynamic)args[0], (dynamic)args[1], (dynamic)args[2], (dynamic)args[3], (dynamic)args[4], (dynamic)args[5], (dynamic)args[6], (dynamic)args[7], (dynamic)args[8], (dynamic)args[9]); break;

            default: throw new NotImplementedException(TooManyArgsMessage);

        }

        return null;

    }

    private static DelegatePair CreateDelegate(Tuple<string, object> key)

    {

        var method = key.Item2

            .GetType()

            .GetMethod(key.Item1);

        var argTypes = method

            .GetParameters()

            .Select(p => p.ParameterType)

            .Concat(new[] { method.ReturnType })

            .ToArray();

        var newDelType = Expression.GetDelegateType(argTypes);

        var newDel = Delegate.CreateDelegate(newDelType, key.Item2, method);

        return new DelegatePair(newDel, argTypes.Length - 1, method.ReturnType != VoidType);

    }

    private class DelegatePair

    {

        public DelegatePair(dynamic del, int argumentCount, bool hasReturnValue)

        {

            Delegate = del;

            ArgumentCount = argumentCount;

            HasReturnValue = hasReturnValue;

        }

        public readonly dynamic Delegate;

        public readonly int ArgumentCount;

        public readonly bool HasReturnValue;

    }

}

Now let's take a look at some performance tests...

Optimizing Dynamic Method Invokes in .NET

I recently had a lot of fun helping to optimize some RPC code that was using reflection to dynamically invoke methods in a C# application. Below are a list of implementations that we experimented with, and their performance.

1. Directly Invoking the Method
2. Using MethodInfo.Invoke
3. Using Delegate.DynamicInvoke
4. Casting to a Func
5. Casting a Delegate to Dynamic

Spoilers: Here are the results. (The tests for this can be see below.)

Name	First Call (Ticks)	Next Million Calls	Invoke Comparison
Invoke	1	39795	-
MethodInfo.Invoke	12	967523	x24
Delegate.DynamicInvoke	32	1580086	x39
Func Invoke	731	41331	x1
Dynamic Cast	1126896	85495	x2

Conclusion: Invoking a method or delegate directly is always fastest, but when you need to execute code dynamically, then (after the first invoke) the dynamic invoke of a delegate is significantly faster than using reflection.

Let's take a look at the test code...

Can I port my application to .NET Core?

I am very excited about .NET Core, and I am looking forward to porting my projects to it. Generally porting your own code is a straight forward task, but updating all of your dependencies can be quite daunting. Good news: the guys over at Octopus have built an awesome little site that helps you determine the state of your dependencies!

I Can Has .NET Core

Enjoy,
Tom

Make your NuGet Server use NLog

The latest version of NuGet.Server is fast, stable, and super simple to setup. As for most .NET tools, Scott Hanselman already create a great write up about how to use it.

However, I was very disappointed at how unintuitive it was to get wire up a custom logger!

You need to take several steps to make the official NuGet server write to something like NLog:

1. Create a log wrapper.
2. Implement NuGet.Server.Logging.ILogger.
3. Implement NuGet.ILogger...
4. ...which also makes you implement NuGet.IFileConflictResolver!
5. Implement your own NuGet.Server.IServiceResolver
6. When instantiating ServerPackageRepository...
7. ...pass in the ILogger...
8. ...AND set the Logger property!

Still confused? Pull the code here, or take a look below!

Should you open source your software?

Every Tuesday I help host the QQ Cast, where we fabricate answers to geek culture's most superfluous questions. For our 50th Quest, my good friend Matt Stevenson joined us to talk about open source software.

QQ Cast - Quest 50 - Should you open source your software?

• 00:00 - Mic Check and Introductions
• 05:30 - Is "Expand Enhance Extinguish" still alive and well?
• 19:40 - Can we build a sustainable infrastructure without open source software?
• 33:00 - How much structure do we like to see in our frameworks?
• 40:50 - What are some great open source projects?
• 47:15 - Was heartbleed a good thing or a bad thing?
• 54:30 - Does contributing to open source projects help your resume?
• 60:00 - Should you open source your software?
• 70:00 - Wrap up!

Please always remember that all views and opinions expressed on the podcast are representative solely of the person expressing them; not of their friends and family, not of their coworkers, and certainly not of their employers, past, present, or future.

Enjoy,
Tom