C# and Windows Runtime

C# 5.0 also interoperates with Windows Runtime (WinRT) libraries. WinRT is an

execution interface and runtime environment for accessing libraries in a languageneutral
and object-oriented fashion. It ships with Windows 8 and is (in part) an
enhanced version of Microsoft’s Component Object Model or COM (see Chapter 25).
Windows 8 ships with a set of unmanaged WinRT libraries which serve as a framework
for touch-enabled Metro-style applications delivered through Microsoft’s
application store. (The term WinRT also refers to these libraries.) Being WinRT, the
libraries can easily be consumed not only from C# and VB, but C++ and JavaScript.
Some WinRT libraries can also be consumed in normal nontablet
applications. However, taking a dependency on WinRT
gives your application a minimum OS requirement of Windows
8. (And into the future, taking a dependency on the next version
of WinRT would give your program a minimum OS requirement
of Windows 9.)
The WinRT libraries support the new Metro user interface (for writing immersive
touch-first applications), mobile device-specific features (sensors, text messaging
and so on), and a range of core functionality that overlaps with parts of the .NET
Framework. Because of this overlap, Visual Studio includes a reference profile (a set
of .NET reference assemblies) for Metro projects that hides the portions of the .NET
Framework that overlap with WinRT. This profile also hides large portions of
the .NET Framework considered unnecessary for tablet apps (such as accessing a
database). Microsoft’s application store, which controls the distribution of software
to consumer devices, rejects any program that attempts to access a hidden type.
A reference assembly exists purely to compile against and may
have a restricted set of types and members. This allows developers
to install the full .NET Framework on their machines
while coding certain projects as though they had only a subset.
The actual functionality comes at runtime from assemblies in
the Global Assembly Cache (see Chapter 18) which may superset
the reference assemblies.
Hiding most of the .NET Framework eases the learning curve for developers new to
the Microsoft platform, although there are two more important goals:
• It sandboxes applications (restricts functionality to reduce the impact of malware).
For instance, arbitrary file access is forbidden, and there the ability to
start or communicate with other programs on the computer is extremely
restricted.
• It allows low-powered Metro-only tablets to ship with a reduced .NET Framework
(Metro profile), lowering the OS footprint.
C# and Windows Runtime

Framework Overview
Almost all the capabilities of the .NET Framework are exposed via a vast set of
managed types. These types are organized into hierarchical namespaces and packaged
into a set of assemblies, which together with the CLR comprise the .NET
platform.
Some of the .NET types are used directly by the CLR and are essential for the managed
hosting environment. These types reside in an assembly called mscorlib.dll and
include C#’s built-in types, as well as the basic collection classes, types for stream
processing, serialization, reflection, threading, and native interoperability (“mscorlib”
is an abbreviation for Multi-language Standard Common Object Runtime
Library”).
At a level above this are additional types that “flesh out” the CLR-level functionality,
providing features such as XML, networking, and LINQ. These reside in System.
dll, System.Xml.dll, and System.Core.dll, and together with mscorlib they provide
a rich programming environment upon which the rest of the Framework is built.
This “core framework” largely defines the scope of the rest of this book.
The remainder of the .NET Framework consists of applied APIs, most of which cover
three areas of functionality:
• User interface technologies
• Backend technologies
• Distributed system technologies
Table 5-1 shows the history of compatibility between each version of C#, the CLR,
and the .NET Framework. C# 5.0 targets CLR 4.5 which is unusual because it’s a
patched version of CLR 4.0. This means that applications targeting CLR 4.0 will
actually run on CLR 4.5 after you install the latter; hence Microsoft has taken
extreme care to ensure backward compatibility.

LINQ to XML
The .NET Framework provides a number of APIs for working with XML data. From
Framework 3.5, the primary choice for general-purpose XML document processing
is LINQ to XML. LINQ to XML comprises a lightweight LINQ-friendly XML document
object model, plus a set of supplementary query operators. LINQ to XML is
supported fully in the Metro profile.
In this chapter, we concentrate entirely on LINQ to XML. In Chapter 11, we cover
the more specialized XML types and APIs, including the forward-only reader/writer,
the types for working with schemas, stylesheets and XPaths, and the legacy
XmlDocument-based DOM.
The LINQ to XML DOM is extremely well designed and highly
performant. Even without LINQ, the LINQ to XML DOM is
valuable as a lightweight façade over the low-level XmlReader and
XmlWriter classes.
All LINQ to XML types are defined in the System.Xml.Linq namespace.
Architectural Overview
This section starts with a very brief introduction to the concept of a DOM, and then
explains the rationale behind LINQ to XML’s DOM.
What Is a DOM?
Consider the following XML file:
<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<customer id="123" status="archived">
<firstname>Joe</firstname>
<lastname>Bloggs</lastname>
</customer>

Disposal and Garbage Collection

Some objects require explicit teardown code to release resources such as open files,
locks, operating system handles, and unmanaged objects. In .NET parlance, this is
called disposal, and it is supported through the IDisposable interface. The managed
memory occupied by unused objects must also be reclaimed at some point; this
function is known as garbage collection and is performed by the CLR.
Disposal differs from garbage collection in that disposal is usually explicitly instigated;
garbage collection is totally automatic. In other words, the programmer takes
care of such things as releasing file handles, locks, and operating system resources
while the CLR takes care of releasing memory.
This chapter discusses both disposal and garbage collection, also describing C#
finalizers and the pattern by which they can provide a backup for disposal. Lastly,
we discuss the intricacies of the garbage collector and other memory management
options.
IDisposable, Dispose, and Close
The .NET Framework defines a special interface for types requiring a tear-down
method:
public interface IDisposable
{
void Dispose();
}
C#’s using statement provides a syntactic shortcut for calling Dispose on objects
that implement IDisposable, using a try/finally block. For example:
using (FileStream fs = new FileStream ("myFile.txt", FileMode.Open))
{
// ... Write to the file ...
}