To prevent name collisions, shared assemblies are given a name based on private key cryptography. (Private assemblies are simply given the same name as their main filename.) This name is known as a strong name; it is guaranteed to be unique and must be quoted by applications that reference a shared assembly.
Problems associated with the risk of overwriting an assembly are addressed by specifying version information in the assembly manifest and by allowing side-by-side installations.
NuGet Packages
In the early days, assemblies were reusable units with applications. That use is still possible (and necessary with some assemblies) when you’re adding a reference to an assembly for using the public types and methods from your own code. However, using libraries can mean a lot more than just adding a reference and using it. Using libraries can also mean some configuration changes, or scripts that can be used to take advantage of some features. This is one of the reasons to package assemblies within NuGet packages.
A NuGet package is a zip file that contains the assembly (or multiple assemblies) as well as configuration information and PowerShell scripts.
Another reason for using NuGet packages is that they can be found easily; they’re available not only from Microsoft but also from third parties. NuGet packages are easily accessible on the NuGet server at http://www.nuget.org.
From the references within a Visual Studio project, you can open the NuGet Package Manager (see Figure 1.2. There you can search for packages and add them to the application. This tool enables you to search for packages that are not yet released (include prerelease option) and define the NuGet server where the packages should be searched.
NOTE When you use third-party packages from the NuGet server, you’re always at risk if a package is available at a later time. You also need to check about the support availability of the package. Always check for project links with information about the package before using it. With the package source, you can select Microsoft and .NET to only get packages supported by Microsoft. Third-party packages are also included in the Microsoft and .NET section, but they are third-party packages that are supported by Microsoft.
You can also use your own NuGet server with your development team. You can define to only allow packages from your own server to be used by the development team.
Because .NET Core is so modular, all applications – other than the simplest ones – need additional NuGet packages. To make it easier for you to find the package, with every sample application that’s built with .NET Core this book shows a table that lists packages and namespaces that need to be added.
NOTE More information about the NuGet Package Manager is covered in Chapter 17, “Visual Studio 2015.”
Common Language Runtime
The Universal Windows Platform makes use of Native .NET to compile IL to native code. With all other scenarios, with both applications using the .NET Framework 4.6 and applications using .NET Core 1.0, a Common Language Runtime (CLR) is needed. However,NET Core uses the CoreCLR whereas the .NET Framework uses the CLR. So, what’s done by a CLR?
Before an application can be executed by the CLR, any source code that you develop (in C# or some other language) needs to be compiled. Compilation occurs in two steps in .NET:
1. Compilation of source code to Microsoft Intermediate Language (IL)
2. Compilation of IL to platform-specific native code by the CLR
The IL code is available within a .NET assembly. During runtime, a Just-In-Time (JIT) compiler compiles IL code and creates the platform-specific native code.
The new CLR and the CoreCLR include a new JIT compiler named RyuJIT. The new JIT compiler is not only faster than the previous one; it also has better support for the Edit & Continue feature while debugging with Visual Studio. The Edit & Continue feature enables you to edit the code while debugging, and you can continue the debug session without the need to stop and restart the process.
The runtime also includes a type system with a type loader that is responsible for loading types from assemblies. Security infrastructure with the type system verifies whether certain type system structures are permitted – for example, with inheritance.
After creating instances of types, the instances also need to be destroyed and memory needs to be recycled. Another feature of the runtime is the garbage collector. The garbage collector cleans up memory from the managed heap that isn’t referenced anymore. Chapter 5, “Managed and Unmanaged Resources,” explains how this is done and when it happens.
The runtime is also responsible for threading. Creating a managed thread from C# is not necessarily a thread from the underlying operating system. Threads are virtualized and managed by the runtime.
NOTE How threads can be created and managed from C# is covered in Chapter 21, “Tasks and Parallel Programming,” and in Chapter 22, “Task Synchronization.”
.NET Native
A new feature of .NET 2015 is to compile a managed program to native code, .NET Native. With Windows apps this generates optimized code that can have a startup time that’s up to 60 percent faster and uses 15 to 20 percent less memory.
.NET Native started with compiling UWP apps to native code for apps deployed to the Windows Store.NET Native will also be available with other .NET Core applications. However, this feature did not make it into version 1 of .NET Core and will be available with a future version. You can compile .NET Core applications running on both Windows and Linux to native code. Of course, you need different native images on each of these platforms. Behind the scenes,NET Native shares the C++ optimizer for generating the native code.
Windows Runtime
Starting with Windows 8, the Windows operating system offers another framework: the Windows Runtime. This runtime is used by the Windows Universal Platform and was version 1 with Windows 8, version 2 with Windows 8.1, and version 3 with Windows 10.
Unlike the .NET Framework, this framework was created using native code. When it’s used with .NET applications, the types and methods contained just look like .NET. With the help of language projection, the Windows Runtime can be used with the JavaScript, C++, and .NET languages, and it looks like it’s native to the programming environment. Methods are not only behaving differently in regard to case sensitivity; the methods and types can also have different names depending on where they are used.
The Windows Runtime offers an object hierarchy organized in namespaces that start with Windows. Looking at these classes, there’s not a lot with duplicate functionality to the .NET Framework; instead, extra functionality is offered that is available for apps running on the Universal Windows Platform.
Let’s get into coding and create a Hello, World application. Since the 1970s, when Brian Kernighan and Dennis Ritchie wrote the book The C Programming Language, it’s been a tradition to start learning programming languages using a Hello, World application. Interestingly, the syntax for Hello, World changed with C# 6; it’s the first time this simple program has looked different since the invention of C#.
The first samples will be created without the help of Visual Studio so you can see what happens behind the scenes by creating the application with command-line tools and a simple text editor (such as Notepad). Later, you’ll switch to using Visual Studio because it makes programming life