The first version of the .NET Framework was released more than 10 years ago. Over the years, the framework and the ecosystem have evolved drastically. Today, the .NET Framework is available for development on microcontrollers, smartphones, PCs, servers, and so on. Next to being platform independent, the .NET Framework is also language agnostic. Developers can use C#, VB.NET, F#, Python, C++, or even mix programming languages.

Because the .NET Framework now supports a magnitude of platforms, there is no longer a single .NET Framework and different variants exist. Each variant is supporting a slightly different subset of the BCL (Base Class Library).

Over the years, various frameworks have appeared for the .NET Framework, keeping it up with the latest industry trends: WCF, SignalR, ASP.NET MVC & Web API, WF, WPF, Entity Framework, etc.

It is not possible anymore to cover the entire framework even in a single book, so this Refcard will teach you the important basics you need to know, making it applicable for whatever kind of project you are working on, whether it’s ASP.NET, WCF, Windows Phone, Xamarin, Azure, etc.

The .NET Framework has a massive set of types in it, but some are so important that C# and VB have built-in keywords for them, as listed in table 1.

Table 1. Common types and their language-specific aliases

Apart from Object and String, all the types above are value types. When choosing between the three floating point types (Single, Double and Decimal):

• For financial calculations (i.e. when dealing with money), use Decimal
• For scientific calculations (i.e. when dealing with physical quantities with theoretically infinite precision, such as weights), use Single or Double

The Decimal type is better suited for quantities which occur in absolutely accurate amounts which can be expressed as decimals: 0.1, for example, can be expressed exactly as a decimal but not as a double. For more information, read http://pobox.com/~skeet/csharp/decimal.html and http://pobox.com/~skeet/csharp/floatingpoint.html.

One common task which always has me reaching for MSDN is working out how to format numbers, dates and times as strings. There are two ways of formatting in .NET: you can call ToString directly on the item you wish to format, passing in just a format string or you can use composite formatting with a call to String.Format to format more than one item at a time, or mix data and other text. In either case you can usually specify an IFormatProvider (such as CultureInfo) to help with internationalization. Many other methods in the .NET Framework also work with composite format strings, such as Console.WriteLine and StringBuilder.AppendFormat.

Composite format strings consist of normal text and format items containing an index and optionally an alignment and a format string. Figure 1 shows a sample of using composite format string, with each element labeled.

Figure 1. The anatomy of a call to String.Format

When the alignment isn't specified you omit the comma; when the format string isn't specified you omit the colon. Every format item must have an index as this says which of the following arguments to format. Arguments can be used any number of times, and in any order. In general, the alignment is used to specify a minimum width , if this is negative, the result is padded with spaces to the right; if it's positive, the result is padded with spaces to the left. The effect of the format string depends on the type of item being formatted. To include a brace as normal text in a composite format string (instead of it indicating the beginning or end of a format item), just double it. For example, the result of String.Format("{{0}}") is "{0}".

Numeric Format Strings

Numbers can be formatted in two ways: with standard or custom format strings. The standard ones allow some flexibility in terms of the precision and style, but the custom ones can be used for very specific formats.

Standard Numeric Format Strings

Standard numeric format strings all take the form of a single letter (the format specifier) and then optionally one or two digits (the precision). For example, a format string of N5 has N as the format specifier and 5 as the precision. The exact meaning of the precision depends on the format specifier, as described in table 2. If no precision is specified a suitable default is used based on the current IFormatProvider.

Table 2. Standard numeric format strings

Custom Numeric Format Strings

To format numbers in a custom fashion, you provide a pattern to the formatter, consisting of format specifiers as shown in table 3.

Table 3. Custom numeric format specifiers

Table 4 shows examples of custom numeric format strings, when formatted with a US English format provider.

Table 4. Sample custom numeric format strings and their results

Date and Time Format Strings

Dates and times tend to have more cultural sensitivity than numbers,the ordering of years, months and days in dates varies between cultures, as do the names of months and so forth. As with numbers, .NET allows both standard and custom format strings for dates and times.

Standard Date and Time Format Strings

Standard date and time format strings are always a single character. Any format string which is longer than that (including whitespace) is interpreted as a custom format string. The roundtrip (o or O), RFC1123 (r or R), sortable (s) and universal sortable (u) format specifiers are culturally invariant,in other words, they will produce the same output whichever IFormatProvider is used. Table 5 lists all of the standard date and time format specifiers.

Table 5. Standard date and time format specifiers

Custom Date and Time Format Strings

As with numbers, custom date and time format strings form patterns which are used to build up the result. Many of the format specifiers act differently depending on the number of times they're repeated. For example, "d" is used to indicate the day,for a date falling on a Friday and the 5th day of the month, "d" (in a custom format string) would produce "5", "dd" would produce "05", "ddd" would produce "Fri" and "dddd" would produce "Friday" (in US English,other cultures will vary). Table 6 shows each of the custom date and time format specifiers, describing how their meanings change depending on repetition.

d 1-31
dd 01-31
ddd Abbreviated day name (e.g. Fri)
dddd Full day name (e.g. Friday)

f Tenths of a second
ff Hundredths of a second (etc)
The specified precision is always used, with
insignificant zeroes included if necessary

h 1-12
hh 01-12

H 0-23
HH 00-23

m 0-59
mm 00-59

M 1-12
MM 01-12
MMM Abbreviated month name (e.g. Jan)
MMMM Full day name (e.g. January)

s 0-59
ss 00-59

t First character only (e.g. "A" or "P")
tt Full designator (e.g. "AM" or "PM")

y 0-99 (least significant two digits are used)
yy 00-99 (least significant two digits are used)
yyy 000-9999 (three or four digits as necessary)
yyyy 0000-9999
yyyyy 00000-99999

z -12 to +13, single or double digit
zz -12 to +13, always double digit (e.g. +05)
zzz -12:00 to +13:00, hours and minutes

Table 6. Custom date and time format specifiers

Typically only years within the range 1-9999 can be represented, but there are some exceptions due to cultural variations. See http://msdn.microsoft.com/en-us/library/8kb3ddd4.aspx for more details on this and all of the formatting topics.

Table 7 shows examples of custom date and time format strings, when formatted with a US English format provider. (The date and time in question is the same one used to demonstrate the standard format strings.)

Table 7. Sample custom date and time format strings and their results

The support in .NET for dates and times has changed significantly over time. It’s never simple to do this properly (particularly taking time zones, internationalization, leap years, and other idiosyncrasies into account) but the support has definitely improved.

DateTime and TimeZone have been in the .NET Framework since version 1.0. DateTime simply stores the number of ticks since midnight on January 1st, 1 A.D.—where a tick is 100ns. This structure was improved in .NET 2.0 to allow more sensible time zone handling, but it’s still not entirely satisfactory. It’s useful when you don’t care about time zones, but newer alternatives have been introduced. TimeZone is sadly restricted to retrieving the time zone of the local machine.

.NET 2.0SP1 (which is part of .NET 3.0SP1 and .NET 3.5) introduced DateTimeOffset which is effectively a DateTime with an additional Offset property representing the difference between the local time and UTC. This unambiguously identifies an instant in time. However, it’s not inherently aware of time zones—if you add six months, the result will have the same Offset even if the “logical” answer would be different due to Daylight Savings Time.

.NET 3.5 introduced TimeZoneInfo, which is a much more powerful class for representing time zones than TimeZone—the latter is now effectively deprecated. TimeZoneInfo allows you access to all the time zones that the system knows about, as well as creating your own. It also contains historical data (depending on your operating system) instead of assuming that every year has the same rules for any particular time zone.

Tips

• If you're using .NET 2.0SP1 or higher, you should consider DateTimeOffset to be the "default" date and time type. Some databases are easier to work with using DateTime, however.
• It is usually a good idea to use a UTC representation for as much of the time as possible, unless you really need to preserve an original time zone. Convert to local dates and times for display purposes.
• If you need to preserve the original time zone instead of just the offset at a single point in time, keep the relevant TimeZoneInfo.
• There are situations where the time zone is irrelevant, primarily when either just the date or just the time is important. Identify these situations early and make sure you don't apply time zone offsets.
• In almost all commonly used formats:

  10:00:00.000+05:00 means "the local time is 10am;
  in UTC it's 5am"
  10:00:00.000-05:00 means "the local time is 10am;
  in UTC it's 3pm"

• DateTimeOffset.Offset is positive if the local time is later than UTC, and negative if the local time is earlier than UTC. In other words, Local = UTC + Offset

In addition to the types described above, the Calendar and DateTimeFormatInfo classes in the System.Globalization namespace are important when parsing or formatting dates and times. However, their involvement is usually reasonably well hidden from developers.

Internationalization (commonly abbreviated to i18n) is another really thorny topic. Guy Smith-Ferrier's book, .NET Internationalization (Addison-Wesley Professional, 2006) is probably the definitive guide. However, before you even consider what resources, localized strings, and so forth, you will display to your user, you need to make sure you can accurately move textual data around,which means you need to know about encodings.

Whenever you use a string in .NET, it uses Unicode for its internal representation. Unicode is a standard way of converting characters ("a", "b", "c", etc.) into numbers (97, 98, 99 respectively, in this case). Each number is a 16 bit unsigned integer,in other words it's in the range 0-65535.. You need to be careful how you read your text to start with, and how you output it. This almost always involves converting between the textual representation (your string) and a binary representation (plain bytes),either in memory or to disk, or across a network. This is where different encodings represent characters differently.

The System.Text.Encoding class is at the heart of .NET's encoding functionality. Various classes are derived from it, but you rarely need to access them directly. Instead, properties of the Encoding class provide instances for various common encodings. Others (such as ones using Windows code pages) are obtained by calling the relevant Encoding constructor. Table 8 describes the encodings you're most likely to come across.

Table 8. Common text encodings

Writing good multi-threaded code is complex. It is relatively simple to understand the basics of threads and parallel code, but in practice keeping track of what’s going on can be extremely tricky. For most developers and in most applications it’s recommended to avoid using threads directly. It’s much better to use one of the higher levels of abstractions for asynchronous operations Microsoft has introduced over the years into .NET.

The Task Parallel Library (TPL) has been introduced in .NET 4.0 and is now the recommended asynchronous programming model. The TPL uses tasks as abstraction for the parallelism. Each task represents an asynchronous operation. They provide a higher level of abstraction than threads. The TPL provides a rich set of APIs for waiting, cancellation, continuation, robust exception handling, etc.

The TPL is responsible for determining and adjusting the number of threads required for maximum efficiency to execute all the scheduled tasks.

The TPL supports Data Parallelism, Task Parallelism, and Dataflow components. Data Parallelism is for scenarios where the operation is performed concurrently on elements within a collection or array using the familiar for and foreach constructs. Task Parallelism includes the familiar TAP methods and represent asynchronous operations on a Task as an abstraction. The Dataflow Library contains components that allow for concurrent applications to be built which need to communicate with one another asynchronously or process data as it becomes available.

Microsoft has updated the existing frameworks such as WCF, ASP. NET MVC to support the TPL.

In .NET 4.5, Microsoft has added the async and await keywords to the C# programming language to further simplify working with the TPL. Methods marked with the async keyword will run asynchronously. Code within these methods will wait on the results of other async methods by using the await keyword before a method call.

If you want to use async/await in a .NET 4.0, Silverlight 4 or Windows Phone 7.5 application, it is possible because Microsoft has back-ported the necessary support. But you will need to add the NuGet package Microsoft.Bcl.Async to your project. In Windows 8, all operations that potentially may require longer then 50ms are asynchronous by default and rely on the TPL, which makes it practically impossible to develop a Windows 8 application without understanding how async/await functions.

Writing an Async Method

Writing an async method is not complex. The method must be marked with the async keyword and the return type must be void, Task, or Task<TResult>. The name of an async method should end with “Async”, although this is by convention and not mandatory.

// Mark the method as asynchronous
private async Task<int> CalculateDZonePageSizeAsync()
{
var client = new HttpClient();
var task = await client.GetStringAsync(“http:...”);
// Do some synchronous stuff while // the HTTP request is ongoing DoSomeStuff();
// Wait on the result of the HTTP Request
var content = await task;
// Return the result, the caller could // already continue executing because // the method is asynchronous
return content.Length;
}

The .NET Framework now runs on various platforms. Unfortunately these different platforms often use different subsets of the Base Class Libraries (BCL) and therefore they are using a different .NET Core Library Profile. Each platform can only use libraries targeting its library profile, making it so that third party frameworks would require separate class library projects for each platform.

Microsoft introduced the Portable Class Library specification to resolve this issue. Portable Class Libraries are assemblies that work on multiple platforms (with different .NET core library profiles). Portable Class Libraries are supported in .NET 4.0+ and Xamarin. A lot of popular Microsoft and third party frameworks are now PCLs (HttpCLient, Json.NET, OxyPlot, MVVM Light, etc.).

Portable Class Libraries are a specific project type in Visual Studio. When you create such a project, Visual Studio will display a dialog to select the targeted platforms. The choice of the platforms will impact the supported features.