для других сборок
Как упоминалось ранее, внутренние (internal) классы видимы остальным объектам только в сборке, где они определены. Исключением является ситуация, когда видимость явно предоставляется другому проекту.
Начните с добавления в проект CarLibrary нового класса по имени MyInternalClass со следующим кодом:
namespace CarLibrary
{
internal class MyInternalClass
{
}
}
На заметку! Зачем вообще открывать доступ к внутренним типам? Обычно это делается для модульного и интеграционного тестирования. Разработчики хотят иметь возможность тестировать свой код, но не обязательно открывать к нему доступ за границами сборки.
Использование атрибута assembly
Атрибуты будут более детально раскрыты в главе 17, но пока откройте файл класса Car.cs из проекта CarLibrary и добавьте показанный ниже атрибут и оператор using:
using System.Runtime.CompilerServices;
[assembly:InternalsVisibleTo("CSharpCarClient")]
namespace CarLibrary
{
}
Атрибут InternalsVisibleTo принимает имя проекта, который может видеть класс с установленным атрибутом. Имейте в виду, что другие проекты не в состоянии "запрашивать" такое разрешение; оно должно быть предоставлено проектом, содержащим внутренние типы.
На заметку! В предшествующих версиях .NET использовался файл класса AssemblyInfо.cs, который по-прежнему существует в .NET Core, но генерируется автоматически и не предназначен для потребления разработчиками.
Теперь можете модифицировать проект CSharpCarClient, добавив в метод Main() следующий код:
var internalClassInstance = new MyInternalClass();
Код работает нормально. Затем попробуйте сделать то же самое в методе Main() проекта VisualBasicCarClient:
' Не скомпилируется
' Dim internalClassInstance = New MyInternalClass()
Поскольку библиотека VisualBasicCarClient не предоставила разрешение видеть внутренние типы, предыдущий код не скомпилируется.
Использование файла проекта
Еще один способ добиться того же (и можно утверждать, что он в большей степени соответствует стилю .NET Core) предусматривает применение обновленных возможностей файла проекта .NET Core.
Закомментируйте только что добавленный атрибут и откройте файл проекта CarLibrary. Добавьте в файл проекта узел ItemGroup, как показано ниже:
<ItemGroup>
<AssemblyAttribute
Include="System.Runtime.CompilerServices.InternalsVisibleToAttribute">
<_Parameter1>CSharpCarClient</_Parameter1>
</AssemblyAttribute>
</ItemGroup>
Результат оказывается таким же, как в случае использования атрибута в классе, и считается более удачным решением, потому что другие разработчики будут видеть его прямо в файле проекта, а не искать повсюду в проекте.
NuGet и .NET Core
NuGet — это диспетчер пакетов для .NET и .NET Core. Он является механизмом для совместного использования программного обеспечения в формате, который воспринимается приложениями .NET Core, а также стандартным способом загрузки .NET Core и связанных инфраструктур (ASP.NET Core, EF Core и т.д.). Многие организации помещают в пакеты NuGet свои стандартные сборки, предназначенные для решения сквозных задач (наподобие ведения журнала и построения отчетов об ошибках), с целью потребления в разрабатываемых бизнес-приложениях.
Пакетирование сборок с помощью NuGet
Чтобы увидеть пакетирование в действии, понадобиться поместить библиотеку CarLibrary внутрь пакета и затем ссылаться на пакет из двух клиентских приложений.
Свойства пакета NuGet доступны через окно свойств проекта. Щелкните правой кнопкой мыши на имени проекта CarLibrary и выберите в контекстном меню пункт Properties (Свойства). Перейдя на вкладку Package (Пакет), вы увидите значения, которые вводились ранее для настройки сборки. Для пакета NuGet можно установить дополнительные свойства (скажем, принятие лицензионного соглашения и информацию о проекте, такую как URL и местоположение хранилища).
На заметку! Все значения на вкладке Package пользовательского интерфейса Visual Studio могут быть введены в файле проекта вручную, но вы должны знать ключевые слова. Имеет смысл хотя бы раз воспользоваться Visual Studio для ввода всех значений и затем вручную редактировать файл проекта. Кроме того, все допустимые свойства описаны в документации по .NET Core.
В текущем примере кроме флажка Generate NuGet package on build (Генерировать пакет NuGet при компиляции) никаких дополнительных свойств устанавливать не нужно. Можно также модифицировать файл проекта следующим образом:
<PropertyGroup>
<TargetFramework>net5.0</TargetFramework>
<Copyright>Copyright 2020</Copyright>
<Authors>Phil Japikse</Authors>
<Company>Apress</Company>
<Product>Pro C# 9.0</Product>
<PackageId>CarLibrary</PackageId>
<Description>This is an awesome library for cars.</Description>
<AssemblyVersion>1.0.0.1</AssemblyVersion>
<FileVersion>1.0.0.2</FileVersion>
<Version>1.0.0.3</Version>
<GeneratePackageOnBuild>true</GeneratePackageOnBuild>
</PropertyGroup>
Это приведет к тому, что пакет будет создаваться заново при каждой компиляции проекта. По умолчанию пакет создается в подкаталоге binDebug или binRelease в зависимости от выбранной конфигурации.
Пакеты также можно создавать в командной строке, причем интерфейс CLI предлагает больше параметров, чем среда Visual Studio. Например, чтобы построить пакет и поместить его в каталог по имени Publish, введите показанные далее команды (находясь в каталоге проекта CarLibrary). Первая команда компилирует сборку, а вторая создает пакет NuGet.
dotnet build -c Release
dotnet pack -o .Publish -c Debug
На заметку! Debug является стандартной конфигурацией и потому указывать -с Debug необязательно, но параметр присутствует в команде, чтобы намерение стало совершенно ясным.
Теперь в каталоге Publish находится файл CarLibrary.1.0.0.3.nupkg. Для просмотра его содержимого откройте файл с помощью любой утилиты zip-архивации (такой как 7-Zip). Вы увидите полное содержимое, которое включает сборку и дополнительные метаданные.
Ссылка на пакеты NuGet
Вас может интересовать, откуда поступают пакеты, добавленные в предшествующих примерах. Местоположением пакетов NuGet управляет файл XML по имени NuGet.Config. В среде Windows он находится в каталоге %appdata%NuGet. Это главный файл. Открыв его, вы увидите несколько источников пакетов:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<packageSources>
<add key="nuget.org" value="https://api.nuget.org/v3/index.json"
protocolVersion="3" />
<add key="Microsoft Visual Studio Offline Packages"
value="C:Program Files (x86)
Microsoft SDKsNuGetPackages" />
</packageSources>
</configuration>
Здесь присутствуют два источника пакетов. Первый источник указывает на http://nuget.org/ — крупнейшее в мире хранилище пакетов NuGet. Второй источник находится на вашем локальном диске и применяется средой Visual Studio в качестве кеша пакетов.
Важно отметить, что файлы NuGet.Config по умолчанию являются аддитивными. Чтобы добавить дополнительные источники, не изменяя список источников для всей системы, вы можете создавать дополнительные файлы NuGet.Config. Каждый файл действителен для каталога, в котором он находится, а также для любых имеющихся подкаталогов.
