The .NET Framework is a superset of .NET Core.

Although .NET Core has less functionality today, once .NET Core 2.0 is released in late summer 2017, with support for .NET Standard 2.0, .NET Core will have comparable functionality to .NET Framework. Going forward, Microsoft has said that new features will be added to .NET Core first, and then ported back to .NET Framework.

The .NET Framework's BCL and the .NET Core's CoreFX are libraries of prebuilt code that are divided into assemblies and namespaces that make it easier to manage the tens of thousands of types available. It is important to understand the difference between an assembly and a namespace.

If an assembly is compiled as a class library (it provides types for other assemblies to use), then it has the file extension .dll (dynamic link library) and it cannot be executed standalone, except by the dotnet run command.

If an assembly is compiled as an application, then it has the file extension .exe (executable) and can be executed standalone.

Any assembly (both applications and class libraries) can reference one or more class library assemblies as dependencies, but you cannot have circular references, so assembly B cannot reference assembly A if assembly A already references assembly B. Visual Studio will warn you if you attempt to add a dependency reference that would cause a circular reference.

Every application created for .NET Core has a dependency reference to the Microsoft .NET Core App platform. This special platform contains thousands of types in NuGet packages that almost all applications would need, such as the int and string variables.

Using Visual Studio 2017, if you open one of your previous projects, and navigate to View | Object Browser, or press Ctrl + W, J, then you will see that your solution has dependencies on assemblies such as System.Collections that you will use later in this chapter, and on System.Console, used in all the coding exercises so far, as shown in the following screenshot:

Object Browser can be used to learn about the assemblies and namespaces that .NET Core uses to logically and physically group types together.

When you click on an assembly in Object Browser, you can see the version of .NET Standard that the assembly was first released with. For example, System.Console.dll was introduced in .NET Standard 1.3, as shown in the following screenshot:

In the following screenshot, you can see that System.IO.dll was released as part of .NET Standard 1.5:

Later in this chapter, you will learn about generic collections, like List<T>, that are part of the System.Collections.dll assembly, as shown in the following screenshot:

To understand how Visual Studio 2017 and Visual Studio Code store their dependencies, right-click any project in Solution Explorer and choose Unload Project.

The project will now be marked as (unavailable). Right-click the project and choose Edit <projectname>.csproj:

This action will open the project file and reveal the XML inside, as shown in the following markup:

    <Project Sdk="Microsoft.NET.Sdk"> 
 
      <PropertyGroup> 
        <OutputType>Exe</OutputType> 
        <TargetFramework>netcoreapp1.1</TargetFramework> 
      </PropertyGroup> 
 
    </Project> 

Close the file.

In Visual Studio 2017, right-click the project, and choose Reload Project.

In Visual Studio 2017, press Ctrl + Shift + N or navigate to File | New | Project....

In the New Project dialog, in the Installed | Templates list, select Visual C#. In the list at the center, select Console App (.NET Core), type the name Ch04_Assemblies, change the location to C:Code, type the solution name Chapter04, and then click on OK.

In Visual Studio Code, use the Integrated Terminal to create a folder named Chapter04 with a subfolder named Ch04_Assemblies. Use dotnet new console to create a console application and restore packages.

Inside the Main method, type the following code:

    var doc = new XDocument(); 

The XDocument type is not recognized because we have not told the compiler what the namespace of the type is. Although this project already has a reference to the assembly that contains the type, we also need to either prefix the type name with its namespace or to import the namespace. We can get Visual Studio to fix this problem for us.

Click inside the XDocument class name. Visual Studio 2017 and Visual Studio Code both display a light bulb showing that it recognizes the type and can automatically fix the problem for you.

Click on the light bulb, or in Visual Studio 2017 press Ctrl + . (dot), or in Visual Studio Code press Cmd + . (dot).

Visual Studio 2017 shows a nicer explanation of your choices, and a preview of its suggested changes, as shown in the following screenshot:

Visual Studio Code has no explanations, but it does have the same choices, as shown in the following screenshot:

Choose using System.Xml.Linq; from the menu. This will import the namespace by adding a using statement to the top of the file.

Once a namespace is imported at the top of a code file, then all the types within the namespace are available for use in that code file by just typing their name.

One of the common questions I get from new C# programmers is, "What is the difference between string with a lowercase and String with an uppercase?"

The short answer is easy: none.

The long answer is that all C# type keywords are aliases for a .NET type in a class library assembly.

When you use the keyword string, the compiler turns it into a System.String type. When you use the type int, the compiler turns it into a System.Int32 type. You can even see this if you hover your mouse over an int type, as follows:

The following table shows the 16 C# type keywords and their actual .NET types: