I have been fortunate enough to be allowed to speak at Indy.Code() which really means I’m grateful to get the chance to listen to all the other speakers. If you live anywhere around the Midwest, or can travel to Indianapolis, I highly recommend you come and watch the talks. It’s going to be an amazing event with some unbelievably great speakers. A fun time will be had by all. (Unless you hate fun, then you probably won’t like it so much. For everyone else, it’ll be pretty great!)

C# 7 Additions – Tuples

In C# 7 Microsoft has introduced an updated Tuple type. It has a streamlined syntax compared to it’s predecessor making it fall it look more like F#. Instead of declaring it like previous versions, the new Tuple type looks like:

Likewise to declare it as a return type, the syntax is similar to declaring it:

The first thing to note about the new type is that it is not included automatically in a new project. If you immediately use it, you’ll see the following error.

As of VS 15 preview 4 (not to be confused with VS 2015), you must include the System.ValueTuple Nuget package to take advantage of it.

This raises the question about how the new Tuple type and the previous one included since .NET 4 are related? They’re not. They are treated as two different types and are not compatible with each other.  System.Tuple is a reference type and System. ValueTuple is a value type.

So what are advantages over the previous version? The syntax simpler, and there are several other advantages.

Named Properties

In the System.Tuple version, properties of the return object were referenced as Item1, Item2 etc. This gets confusing when there are multiples of the same type in the Tuple as you have to know what position had which value type.

Now it’s possible to explicitly name the item types to reduce confusion.

The Item properties (Item1, Item2, etc.) have also been included allowing methods to be updated to the new type without breaking code based on it’s predecessor.

It’s also possible to explicitly name the values when creating the object:


It is now possible to name and assign variable values upon creating (or returning) a tuple. Although not necessary, it reduces the amount of code necessary to pull values out of the type.

It’s not certain if C# will get wildcards like F# to automatically discard values which aren’t needed. If they are allowed then it’s possible to only create a variable for the name like so:

Updating Values

System.Tuple is immutable.  Once created it’s not possible to update any of the values.  This restriction has been removed in the new version.  From a purely functional perspective this could be considered a step backwards, but in C# many people find this approach more forgiving and beneficial.

Like all value types, when it is passed into a method, a copy of the tuple is created, so modifying it in the in the method does not affect the original.

However if you compare two different tuples and they have the same values, the Equals method compares the values in each and if they are all equal, it considers them equal.

Integrations with Other Languages

Unfortunately, C#’s new tuple type doesn’t automatically allow it to translate tuples from F#.

F# can’t desconstruct the values like it can with it’s native tuples, and to return it, you have to explicitly instantiate the object type and add the values.

Either way, the translation to F# isn’t horrible as it acts like any other object passed to it by C#.

Adding New Web Applications

Using PowerShell to create new web applications with the IIS PowerShell Snap-In is incredibly easy. Just use New-WebApplication and specify

  • Site : Site to put it under
  • Physical Path : The directory path to the folder where the application will reside
  • Application Pool : The application pool running the web application
  • Name : The name of the application (what appears in the URL)

The physical path, application pool and site must be in place before running the cmdlet. It won’t create them automatically and will fail the install if they aren’t present. Conveniently, there are cmdlets to handle creating these as well:

Creating a new directory:

Creating an application pool:

Ne App Pool PowerShell

App Pool IIS

Creating a new site:

powershell created site

IIS Site

PowerShell doesn’t let you customize much during the default install (Restart schedules, application pool user, etc.), but it is easy to modify them after creation. Use the Set-ItemProperty (Alternatively, you can use Get-ItemProperty to look at the configuration values in IIS).

Unless you specify the Force parameter, old web applications won’t be overwritten by new ones. In order to test them before making the update specify the conditional using Test-Path:

Removing a web application is just as easy as creating one too. Just provide the name of the web application and the site it runs under: