Two programming languages that
support Windows 8 style applications — C# and Visual Basic — run over
the .NET Framework. Windows 8 has been released with a new version of
.NET Framework — version 4.5. The development architecture picture
would not be complete without understanding what’s new in this version,
and how .NET Framework cooperates with Windows Runtime.
The Installation Model of .NET Framework 4.5
Since 2002 (when .NET 1.0 was
released), there have been several ways for a new .NET Framework
release to cooperate with previous releases, as shown in Figure 1.
Although the first three versions (1.0, 1.1, and 2.0) were shipped with
different CLR versions that could run side-by-side on the same
computer, subsequent versions followed a different path.
When .NET Framework 3.0 was released in 2006, it
did not install its own CLR. It was simply an addition to version 2.0
and used its runtime core. The same thing happened with .NET 3.5 in
2007. It was an addition to .NET 3.0, and still used the CLR released
with .NET 2.0.
In 2010, .NET 4.0 was released, again with its
own CLR, encapsulating the enhanced forms of Base Class Libraries
coming from .NET 3.5. Theoretically, in 2010, you could install four
CLR versions side-by-side on your computer: CLR 1.0, CLR 1.1, CLR 2.0,
and CLR 4.0. The newest .NET Framework, version 4.5, added more salt to
the installation models used before. Instead of adding a new CLR
side-by-side or new Base Class Libraries on top of the CLR 4.0 runtime,
.NET 4.5 is an in-place update (that is, an update that not only adds
new files, but overwrites existing ones) that changes both the CLR 4.0
runtime (it upgrades it to CLR 4.5) and also extends the prior Base
Class Libraries.
NOTE An in-place operating
system update or .NET CLR update is always a big risk from a
compatibility point of view. With the .NET Framework 4.5 release,
Microsoft undertook this risk, and spent much effort to cope with
potential incompatibility issues. Microsoft set up a compatibility lab,
reviewed all bug fixes and new features, and ran old tests unchanged.
Window Runtime Integration
The .NET CLR has always had integration
features with other legacy technologies, such as COM and P/Invoke
(Platform Invoke to access the Win32 API). With .NET Framework 4.5, the
CLR natively integrates with Windows Runtime. C# and Visual Basic
programmers now can use Windows Runtime types with the same ease, as if
those were .NET types.
Windows Runtime types are native types. They
actually use a new and modern version of COM that does not require
object registration, and so their operations cannot be called directly
from managed code. However, the .NET CLR and the language compilers
arrange everything behind the scenes, and you do not need to deal with
the details of calling the native Windows Runtime object from your
managed code.
Both the desktop application and Windows 8 style
application development stacks contain a .NET Runtime box. You may
think this means that two different .NET Frameworks exist, one for the
desktop applications and one for Windows 8 style applications.
Fortunately, there is only one.
The Base Class Library available to Windows 8
style applications (Windows Runtime applications) is restricted to
services that are considered “safe” for a Windows 8 application to use.
When you try to build your existing .NET source code, some parts would
not compile, because those might be using some .NET Base Class Library
functions that are not found in Windows Runtime, or are not thought
“safe” in Windows 8 apps.
NOTE Generally, all operations are taken into account as “safe” that do not jeopardize UI responsiveness.
Asynchrony Support
As you have learned, asynchronous
programming is a key technique to provide UI responsiveness, and
Windows Runtime was designed with asynchrony in mind. The results of
the Windows Runtime design process inspired the .NET Framework team,
and they added asynchrony support to many components of the framework.
The .NET Base Class Libraries contain hundreds of changes and
improvements, including the following most significant ones:
- The key interfaces of the Base Class Library (for example, file I/O operations) support asynchrony.
- Data access procedures in ADO.NET (the foundational data access
technology in .NET), and network communication components in Windows
Communication Foundation (WCF), also handle asynchronous constructs as
first-class operations.
- ASP.NET supports asynchronous pipelines when processing requests
and creating responses. ASP.NET MVC 4 provides asynchronous controllers.
- The Task Parallel Library — introduced in .NET Framework 4.0 — was
designed with asynchronous programming in mind. In .NET Framework 4.5,
its thread-management was improved with new types managing
synchronization and various timeout scenarios.
Although the asynchronous programming patterns
provide better UI responsiveness and improved throughput, it is quite
difficult to apply them, and they are pretty error-prone. With .NET
Framework 4.5, the C# and Visual Basic compilers provide two new
keywords (async and await in C#, Async and Await in Visual Basic) that take over all complexity related to these patterns.
