Язык программирования C#9 и платформа .NET5

 {
   namespace MyShapes
  {
  // Класс Circle
  public class Circle
  {
  /* Интересные методы... */
  }
  }
 }

Второй (и более распространенный) способ предусматривает использование "точечной записи" в определении пространства имен, как показано ниже:

 namespace CustomNamespaces.MyShapes
 {
// Класс Circle
  public class Circle
  {
  /* Интересные методы... */
  }
 }

Пространства имен не обязаны содержать какие-то типы непосредственно, что позволяет применять их для обеспечения дополнительного уровня области действия.

Учитывая, что теперь пространство My3DShapes вложено внутрь корневого пространства имен CustomNamespaces, вам придется обновить все существующие директивы using и псевдонимы типов (при условии, что вы модифицировали все примеры классов с целью их вложения внутрь корневого пространства имен):

 using The3DHexagon = CustomNamespaces.My3DShapes.Hexagon;
 using CustomNamespaces.MyShapes;

На заметку! На практике принято группировать файлы в пространстве имен по каталогам. Вообще говоря, расположение файла в рамках структуры каталогов никак не влияет на пространства имен. Однако такой подход делает структуру пространств имен более ясной (и конкретной) для других разработчиков. По этой причине многие разработчики и инструменты анализа кода ожидают соответствия пространств имен структуре каталогов.

Изменение стандартного пространства имен в Visual Studio

Как упоминалось ранее, при создании нового проекта C# с использованием Visual Studio (либо интерфейса .NET Core CLI) название корневого пространства имен приложения будет совпадать с именем проекта. Когда затем в Visual Studio к проекту добавляются новые файлы кода с применением пункта меню Project?Add New Item (Проекта?Добавить новый элемент), типы будут автоматически помещаться внутрь корневого пространства имен. Если вы хотите изменить название корневого пространства имен, тогда откройте окно свойств проекта, перейдите в нем на вкладку Application (Приложение) и введите желаемое имя в поле Default namespace (Стандартное пространство имен), как показано на рис. 16.1.

На заметку! В окне свойств проекта Visual Studio корневое пространство имен по-прежнему представлено как стандартное (default). Далее вы увидите, почему в книге оно называется корневым (root) пространством имен.

Конфигурировать корневое пространство имен можно также путем редактирования файла проекта (*.csproj). Чтобы открыть файл проекта .NET Core, дважды щелкните на его имени в окне Solution Explorer или щелкните на нем правой кнопкой мыши и выберите в контекстном меню пункт Edit project file (Редактировать файл проекта). После открытия файла обновите главный узел PropertyGroup, добавив узел RootNamespace:

 <Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
  <OutputType>Exe</OutputType>
  <TargetFramework>net5.0</TargetFramework>
   <RootNamespace>CustomNamespaces2</RootNamespace>
  </PropertyGroup>
 </Project>

Теперь, когда вы ознакомились с некоторыми деталями упаковки специальных типов в четко организованные пространства имен, давайте кратко рассмотрим преимущества и формат сборки .NET Core. Затем мы углубимся в подробности создания, развертывания и конфигурирования специальных библиотек классов.

Роль сборок .NET Core

Приложения .NET Core конструируются путем соединения в одно целое любого количества сборок. Выражаясь просто, сборка представляет собой самоописательный двоичный файл, который поддерживает версии и обслуживается средой .NET Core Runtime. Невзирая на то, что сборки .NET Core имеют такие же файловые расширения (*.ехе или *.dll), как и старые двоичные файлы Windows, в их внутренностях мало общего. Таким образом, первым делом давайте выясним, какие преимущества предлагает формат сборки.

Сборки содействуют многократному использованию кода

При построении проектов консольных приложений в предшествующих главах могло показаться, что вся функциональность приложений содержалась внутри конструируемых исполняемых сборок. В действительности примеры приложений задействовали многочисленные типы из всегда доступных библиотек базовых классов .NET Core.

Возможно, вы уже знаете, что библиотека кода (также называемая библиотекой классов) — это файл *.dll, который содержит типы, предназначенные для применения внешними приложениями. При построении исполняемых сборок вы без сомнения будете использовать много системных и специальных библиотек кода по мере создания приложений. Однако имейте в виду, что библиотека кода необязательно должна получать файловое расширение *.dll. Вполне допускается (хотя нечасто), чтобы исполняемая сборка работала с типами, определенными внутри внешнего исполняемого файла. В таком случае ссылаемый файл *.ехе также может считаться библиотекой кода.

Независимо от того, как упакована библиотека кода, платформа .NET Core позволяет многократно применять типы в независимой от языка манере. Например, вы могли бы создать библиотеку кода на C# и повторно использовать ее при написании кода на другом языке программирования .NET Core. Между языками есть возможность не только выделять память под экземпляры типов, но также и наследовать от самих типов. Базовый класс, определенный в С#, может быть расширен классом, написанным на Visual Basic. Интерфейсы, определенные в F#, могут быть реализованы структурами, определенными в С#, и т.д. Важно понимать, что за счет разбиения единственного монолитного исполняемого файла на несколько сборок .NET Core достигается возможность многократного использования кода в форме, нейтральной к языку.

Сборки устанавливают границы типов

Вспомните, что полностью заданное имя типа получается за счет предварения имени этого типа (Console) названием пространства имен, где он определен (System). Тем не менее, выражаясь строго, удостоверение типа дополнительно устанавливается сборкой, в которой он находится. Например, если есть две уникально именованных сборки (MyCars.dll и YourCars.dll), которые определяют пространство имен (CarLibrary), содержащее класс по имени SportsCar, то в мире .NET Core такие типы SportsCar будут рассматриваться как уникальные.

Сборки являются единицами, поддерживающими версии

Сборкам .NET Core назначается состоящий из четырех частей числовой номер версии в форме <старший номер>.<младший номер>.<номер сборки>.<номер редакции>. (Если номер версии явно не указан, то сборке автоматически назначается версия 1.0.0.0 из-за стандартных настроек проекта в .NET Core.) Этот номер позволяет множеству версий той же самой сборки свободно сосуществовать на одной машине.