Author: Dan McCrady

Why .NET loves Linux

This is an update to the post I made a while ago titled “Why .Net Doesn’t need to be Expensive“.  A lot has changed since I made that post.  For example: Visual Studio Code wasn’t released, .NET Core was called vNext, and .NET hadn’t gone through it’s open-source transformation.  These introductions to the .NET ecosystem have changed the way .NET developers are working day-to-day and the path to deploying .NET on Linux is quickly becoming a mandatory requirement for IT shops.

Microsoft has been on the Linux love train for quite some time now, and we are slowly starting to see the fruits of this transformation.  Just recently the Linux Subsystem on Windows was added to Windows 10 without the need to turn on developer mode.  Developers now have a native Linux bash that can be enabled through the Windows store.  The new .NET core project templates in Visual Studio include Docker support with just the click of a checkbox.  Azure allows you to host .NET Core projects in Linux, and has moved to allow container orchestration using technologies like Azure Container Storage, and soon to come Azure AKS (its managed Kubernetes).  This change is also reaching out to the open source community.  Most large projects have either ported their program to use .NET standard or are in the process of converting it.


Why so much Love?

Plain and simple: moving custom code to the cloud means moving to Linux.  All cloud technologies that are coming out have Linux as a common player.  AWS, GCP, OCP, Azure, and even smaller players like Digital Ocean all provide Linux as the OS.  If an IT organization can’t migrate their .NET custom code to Linux they are dramatically limiting the choices they have to get to the cloud.  If you aren’t going with Linux you only have two real choices:

1)  Find a Windows Server VM in the cloud and deploy to IIS.  

Technically yes, you are moving to the cloud, but are you really gaining any benefits?  Your operations team still needs to monitor, maintain, and patch this VM just as if it was in your private data centre.  You also are quickly locking yourself to the provider since making an export of the VM to move to another provider will be difficult and require down time as you make that transition.

2)  Use Azure PaaS Offerings like Web App Services.  

Azure is still your friend here.  They will take your web application code that is slightly modified to be cloud ready and host it for you.  The Web App Services offering is really good stuff.  It comes with free auto-scaling, monitoring, and guaranteed availability.  They even take care of patching and maintaining the infrastructure.  The downside here is that until you have migrated that application to Linux you are tied to Azure.  No other cloud provider is looking at a way to host non-core .NET web sites.  So if Azure changes the pricing model, you will need to change with it.


What does Linux get you?

Linux buys you true portability of your applications. The most common way to get to true application portability is to write your applications as a 12 factor application, while using Docker to wrap your application and prepare it for deployment.  If you follow this procedure, then pretty much any platform is open for you to deploy your applications.  Microsoft is currently working to create Windows Server Docker containers like microsoft/nanoserver, but the licensing and deployment constraints are still unclear.  It appears that you need to deploy these images only on a licensed Windows Server 2016 system.  This restriction makes your application tightly coupled to Windows systems and reduces your deployment options significantly.


More investment for .NET Developers

A little while ago I was talking to a group about how the shift to Linux will be a big shift for .NET developers. Normally Microsoft would have a major release and developers could focus for a year or so to wrap their heads around it.  When the TPL was released, Async Await was the big player. Bloggers would write endless articles on how leverage this feature to introduce multi-threading into applications.  This update was all that .NET developers needed to focus on.  The next few years are changing a lot more than Async Await.  A new Operating System in Linux, arguably a new framework with .NET Core, Docker containers, container orchestrators like Kubernetes, all while building strong Dev Ops capabilities.  The future is bright for .NET but the time required to learn all the advantages is long.  I plan to keep our developers moving in this direction, since it is the brightest path forward for custom software development in general, including the .NET ecosystem.


  • Dan
  • McCrady

Dynamic Plugin Loading Using MEF

The Managed Extensibility Framework (MEF) is a library that enables software to discover and load libraries at runtime without hard-coded references. Microsoft included MEF in .NET framework version 4.0 and since then it has been commonly used for dependency resolution and inversion of control patterns.

Orbital Bus makes communication possible between different parties by sharing contract and schemas. A receiver has a contract library that has all the information needed for a dispatcher to make proper synchronous and asynchronous calls all the way to an end consumer. The dispatcher downloads a receiver’s contract library and then uses it to construct calls with the right data schemas. It became very clear to us during development that a crucial requirement was that the dispatcher to be able handle any downloaded contract library DLL and process it without code changes. This is where MEF comes into play. It lets us inject libraries, in this case the receiver’s contract libraries, at the start-up stage.

Once we chose to use MEF as our integration tool, we were able to start the Code Generation Project. This project is a convenient CLI tool that efficiently generates the contract libraries and plugins which are loaded by the receiver. These libraries are made available for download to any dispatcher on the mesh network. One challenge we encountered downloading multiple contract libraries for the dispatcher was how to distinguish between these contract libraries. What if two contracts have similar operation names? How can the dispatcher tell what is the right operation to select from its composition container? We were able to solve this challenge by making sure that each contract library generated has a unique ServiceId that would be exported as metadata within the contract library. This setting enables the dispatcher to filter out various operations based on their ServiceId:

    namespace ConsumerContractLibrary
        [ExportMetadata("ServiceId", "ConsumerLibrary")]
        public class AddCustomerOperation : IOperationDescription {}

When the receiver starts up, it will pull the plugins from its Plugins folder and load the plugin.dll and adapters into MEF’s CompositionContainer, a component used to manage the composition of parts. Those dependencies will be injected into the receiver as it loads. In addition to handling messages destined for the consumer, the receiver also serves as file server that waits for the dispatcher to download the contract library when needed.

    public PluginLoader(IConfigurationService config)
        this.config = config;
        var container = this.BuildContainer(); // load the plugin DLLs and create composition container
        var details = this.RegisterPlugins(container);
        this.BootStrapSubscriberDetails(details); //Creates needed dependencies and bootstraps the given details.

After a dispatcher downloads the available contract library specifications into a composition container, it will filter out and return all the exported values in the container corresponding the given ServiceId.

    public static IEnumerable<T> GetExportedValues<T>(this CompositionContainer container,
            Func<IDictionary<string, object>, bool> predicate)
        var exportedValues = new List<T>();

        foreach (var part in container.Catalog.Parts)
            foreach (var ExportDef in part.ExportDefinitions)
                if (ExportDef.ContractName == typeof(T).FullName)
                    if (predicate(ExportDef.Metadata))

        return exportedValues;

Where the predicate clause is actively the filter we need for ServiceId:

    metadata => metadata.ContainsKeyWithValue(METADATAKEY, serviceId)

After filtering the process, the dispatcher has all the contract library operations that are supported by the receiver.

MEF proved invaluable in solving the problem of runtime library integrations and to enable the plugin architecture. This implementation allows Orbital Bus the flexibility for developers to customize or update their contract libraries, service configurations, and translations without affecting other services on the bus. As our work continues, we plan on looking closer at the issue of versioning in the dispatcher to keep its cache in sync with the receiver’s contract libraries, making Orbital Bus an even more agile messaging solution.

  • Dan
  • McCrady

Why .NET Doesn’t Have to be Expensive

.NET is a proven and mature framework that has great benefits, however it is often overlooked when companies are deciding on a language and framework. Many developers remember the Microsoft of old where you were immediately stuck with proprietary frameworks and Microsoft-only products that have high initial costs and outrageous scaling overhead. Fortunately for the industry, Microsoft is taking a sharp turn away from proprietary restrictions and is moving towards open source.

Let’s examine CheapMumble, a project which has been successfully deployed using .NET with no licensing costs. I’ll take a look at the frameworks, software, and hosting that has been used to make his project successful. I’ll also explore other options and the future of .NET in the open source world.

The CheapMumble Project

To understand what CheapMumble does, you first need to understand what mumble is. From the Mumble wiki: “Mumble is an open source, low-latency, high quality voice chat software primarily intended for use while gaming.” CheapMumble is simply a cheap hosting solution for mumble servers.

Take a look at the software stack used to create CheapMumble.

Front End

Razor (Open Source)

The beloved view-rendering engine of MVC.Net has been open sourced and has been freely available for some time.

Application Tier

.NET Framework 4.5

The same framework you read about or are familiar with, including Async Await, Linq, and all other features.

Mono (Open Source)

The team was able to use the framework by choosing the ever growing project Mono. At the time this article is written, Mono just recently released version 3.6.0. If you want to know about compatibility take a look here.

Nancyfx (Open Source)

Nancy is the web framework chosen to drive CheapMumble. You may have never heard of it, however it’s a full featured web framework ready to be used in any of your next web projects. The great thing about Nancy is the firm dedication of support for the Mono libraries. Take a look at their blog to learn more and see what they are up to.

Entity Framework (Open Source)

Don’t compromise on your data access. Use the best ORM out there (and yes I’ll fight you on that). Entity Framework has been open sourced for a long time and has great support under the Mono framework. Linq your hearts out on your next project.


MySQL (Open Source)

Entity Framework allows you to connect to any relational database you please, including MySQL, using the .NET Connector. Setup is easy and you will forget about your database while using code first features and strong object relational models.

Software during development can be a substantial cost if you’re not careful. Especially if you consider the cost of Visual Studio Ultimate MSDN subscriptions. Visual Studio is the best development IDE out there, however do you really need all its features? Let’s take a look at some cheaper alternatives.

Visual Studio Express

Free Visual Studio! What could go wrong? I’d love to tell you this is the solution to all your problems. It isn’t. They have, however, added a lot to the express editions over the years. Ability for multi-project solutions, unit testing, NuGet, code analysis. Trying to find the limitations online was not easy, and I didn’t find a reliable source. I would recommend giving it a shot. See what happens. It could very well be all your team needs.

Xamarin / MonoDevelop

MonoDevelop evolved into Xamarin whether on Windows or Mac. Don’t get scared by the price tag. The only price for Xamarin is when you want to compile source code to work with Android or iOS in a closed-source application. This means that all web applications can be developed free of use on Xamarin.

Sublime Text

Wait, really? Though sublime isn’t a full, feature-rich IDE, it is still a very strong candidate for a lot of developers. Recently on the Nancyfx blog they went through a tutorial on setting up Sublime to work with ASP.Net development.

With these technologies, the CheapMumble team was able to develop and deploy their software on whatever platform they saw fit. The best part was that no licensing cost was required.

The future of open source on the .NET framework is bright. Everything in this post works today, and tomorrow there will be even more. Recently, Microsoft unveiled ASP.Net vNext with a large amount of the software being open source. A great rundown of features was given from Scott Hanselman in his post Introducing ASP.NET vNext. The most exciting part is at the end:

ASP.NET vNext (and Rosyln) runs on Mono, on both Mac and Linux today. While Mono isn’t a project from Microsoft, we’ll collaborate with the Mono team, plus Mono will be added to our test matrix. It’s our aspiration that it “just work”.

The future for ASP.NET development is clear: Open Source and CHEAP!

  • Dan
  • McCrady

Fakes and Shims Generic Methods

Working with Microsoft’s Fakes and Shims is really a treat. I love how easy they are to setup and how I can be sure that I can test anything I need.


Lately I have been trying to test Generic Methods of an Interface. Doesn’t seem like a challenge, as nothing else in the framework is, however I quickly found out it wasn’t as simple as I thought.

Take this interface as an example:

Pubic interface ISampleInterface
T GetMySample<T>();

When you add the Fakes and Shims Assembly, a class will be generated to allow you to apply functions to each of the interface members. However, you will notice the expected member is missing. Instead, you will get something that looks like the following:



The issue is because of the Generic type in the interfaces member definition. The stubs don’t know what method type to create for you. It could try and generate a method for every implementation of T, but that seems to be a bit much.


Instead, they give you a way of defining the type after the creation of the stub. You will see a new method on the stub called GetMySampleOf1. This is the method you will use to a give a definition to the generic method. Implementation of the stub will look like the following:


You can see that I have implemented the interface for 4 different data types. String, Integer, Boolean, and DateTime. This makes it really easy to implement interface members with generic type arguments.

  • Dan
  • McCrady

Automating Builds with TFS Build Definitions

My latest project utilized automated builds to speed up the deployment life cycle. We are running in an agile process and wanted to leverage continuous integration to help the product owners see new features as soon as possible. What follows is a quick walkthrough of the steps/tasks to get a basic build definition setup using TFS and Visual Studio.

Before we get started we need to ensure we have installed some prerequisites. Make sure you have the following:

  1. TFS installed with a Team Project and your project source code checked in.
  2. Build Controller installed with a Build Agent. More information on this can be found here.
  3. Ensure all software required for build is installed on the same machine as the Build Agent, including Visual Studio.
  4. Visual Studio must also be installed on your local development environment.
  5. A network share location to place the code drops (i.e. built code).
  6. A domain is not required but is highly recommended for secure access to network locations.

The example that follows is using TFS 2012 and Visual Studio 2012. However, this process will most likely apply to future versions (I have seen no differences if using either TFS 2013 preview or Visual Studio 2013).

To get started I first need to create a new build definition. This will be the basis for how a build is completed. In order to create a new build definition, I open Visual Studio, navigate to Team Explorer, and then to the Builds section.

In the figure below, I don’t have any build definitions for this project. However I can change this by selecting the “New Build Definition” selection from the Builds menu.


Figure 1 – Team Explorer – Builds Tab

A new menu will appear, this is where we will need to configure our build definition. First, in the General tab, give your build definition a name and an optional description. I’m going to call mine Blog Build Definition CI, and give a definition of “Sample build definition for my blog post”. A “Queue Processing” option must be selected as well. We are going for a continuous integration set-up, so select “Enabled”.


Figure 2 – New Build Definition – General Tab

Next we need to select the trigger for the build definition. This can be found in the Trigger tab. Here we want to select the best option for a continuous integration setup. Depending on your team or situation, you may opt to use “Rolling builds” or “Gated Check-in” but “Continuous Integration” is likely adequate for most environments.


Figure 3 – New Build Definition – Trigger Tab

Then we move onto Source Settings. Source Settings can be a little bit tricky but is straight forward once you gain an understanding of what is being asked. Source Control Folder is used to select what source the build will be acting on. You can see that I selected my “BlogBuildDefinitionProject” folder as my source. Build Agent Folder can be a bit confusing. During the build, the controller is going to grab the source code files from TFS and send them to the build agent. The Build Agent Folder refers to the location on the Build Agent’s server that the files will be sent to. “$(SourceDir)” is a variable used by TFS as a starting point for source drops. The article List of Variables Like $(SourceDir) gives a good explanation of what the variable is:

$(SourceDir) – Expands to $(BuildDir)\Sources by default

The directory “Sources” is not hard-coded and may be changed by modifying the TfsBuildService.exe.config file on the build agent. If you open that file there will be an application setting called “SourcesSubDirectory”. If you need a shorter path you may change this key to something like “s” instead of “Sources”. If you made this change then the $(SourceDir) variable would expand to $(BuildDir)\s

For the purposes of this example I only have one solution I’m building, so keeping the default is fine. However, if you want to build multiple solutions, each location will need its own source directory. You should keep all the source locations pre-pended with “$(SourceDir)” and append them with “/project1″ or more likely the name of your solution.


Figure 4 – New Build Definition – Source Settings

Build Defaults is next, and is a fairly simple screen. We need to select the Build Controller we are going to use. I defined my controller very quickly (see #2 in the list of prerequisites at top). You can see it is named “TeamFoundation” and has no description. Most likely you will only have one controller. Under “Staging Location” you will only have two options unless you are creating a build definition for Team Foundation Service where a third option will be presented. That third option is out scope of this article so we will focus on the two that are given for full featured Team Foundation Server Installations. The first selection is used when your build process for whatever reason doesn’t need to copy files to a drop location. The second one is the standard option and will require you to put in the network address of the network share you created earlier (see #5 in list of prerequisites at top). Remember that the Build Agent that was configured for use with TFS will need to have full access to this folder.


Figure 5 – New Build Definition – Source Settings

The Process section is the meat of your build definition. This is where you can dictate the steps and set up a “Build Template”. There is a lot of information that could be explained here, especially when talking about creating build templates. Custom build processes are something I want to cover further in a future post but will be skipped over for now. The default template that is created whenever a new Team Project is created is more than suitable for a basic continuous integration deployment. The default build process template is pre-selected for you, however, you can select “New…” in order to start the creation of your own. The most important part is to select the Items to Build.

For this example (see screen shot below) I selected the solution of my “BlogBuildDefinitionProject”. The defaults for Automated Tests are normally adequate enough to get tests run before your code is built on the server, however, you can also define a string that will be used to find your test projects. It’s important to realize that if using the default, any .dll file with the word “test” in the file name will be searched for test classes and methods and these tests will then be run. Furthermore, if your test project names don’t already contain the word “test”, you will need to either alter this string to something that is common between your test projects’ names, or change the names of your test projects.


Figure 6 – New Build Definition – Process

Retention Policy really isn’t very important. It’s just a definition as to how long certain types of builds should be kept. Depending on how the build is triggered you can keep those files for a specified amount of time. Normally the defaults are sufficient for any project you have on the go.


Figure 7 – New Build Definition – Retention Policy

Make sure you save, and upon saving successfully you will see in your Team Explorer Builds tab that you now have a build definition present.


Figure 8 – Team Explorer – Builds with Definition

Next time you check in your code you will see a build under “My Builds”. Give it a few minutes and you will get a log of the events that transpired.


Figure 9 – Team Explorer – Builds New Build

Building up the perfect deployment solution can take time, however when it’s done you will be able to create new builds in seconds. It really is great and has saved many hours trying to get products to launch.

If you have any questions, or want to chat more about this, contact us today – we’d love to hear from you!

  • Dan
  • McCrady