 В прошлой части было показано как с помощью NuGet можно легко добавлять, обновлять и удалять библиотеки в проекте. Теперь посмотрим как одна маленькая настройка может дать очень интересные возможности в работе с этим инструментом. |
Настройки NuGet
Давайте откроем Visual Studio 2010 и посмотрим на настройки NuGet. Для этого можно или выбрать пункт меню "Tools > Library Package Manager > Package Manager Settings" или воспользоваться кнопкой "Package Manager Settings", расположенной в окне консоли NuGet. Как можно заметить, в появившемся диалоге есть две страницы с настройками.
General
И первая из них называется General. На ней расположена кнопка отчистки списка последних использованных библиотек (Clear Recent Packages List). Того самого, что выводится в консоли командой "Get-Package -Recent" или в диалоге "Add Library Package Reference" на странице "Recent Packages".
Кроме того на этой же странице доступны кнопки управления локальным кэшем установочных пакетов. Они позволяют его очистить (Clear Package Cache) или открыть в Explorer (Browse …).
Стоит отметить, что сам кэш появился в NuGet 1.3. Он создается для каждого пользователя компьютера и позволяет избежать повторных загрузок одних и те файлов с источников данных.
Package Sources
Гораздо интереснее страница "Package Sources", которая позволят указать источники для получения установочных пакетов. Они могут быть трех видов:
- RSS-поток;
- веб-сервис, поддерживающий OData;
- папка на диске или в сети.
Посмотрим как создать последний вариант из приведенного списка.
Создание локального репозитория
Давайте создадим в любом месте на диске папку. Пусть она называется "NuGet repository". Теперь добавим путь к ней в качестве источника под именем "Local NuGet repository".
Скопируем в созданную папку установочные пакеты библиотек. Для этого откроем в Проводнике папку с демонстрационным проектом, который был создан в прошлой части. Если его нет, то просто создадим новое консольное приложение и добавим туда несколько библиотек. Например, те же самые что и в прошлой части Castle.Core, Castle.DynamicProxy, log4net, NLog, RazorEngine или любые другие.
В прошлой части было упомянуто, что все установочные пакеты загружаются в папку "packages". Откроем её и во вложенных папках найдем все файлы с именами библиотек и расширением ".nupkg". Скопируем их в локальный репозиторий "Local NuGet repository". Таким образом, для примера, там окажутся следующие файлы:
- Castle.Core.1.2.0.nupkg
- Castle.DynamicProxy.2.2.0.nupkg
- log4net.1.2.10.nupkg
- NLog.1.0.0.505.nupkg
- NLog.2.0.0.0.nupkg
- RazorEngine.2.1.nupkg
Обратите внимание на то, что размещены две версии NLog. Поскольку имя файла состоит из уникального имени библиотеки и номер её версии, то ничего не мешает это сделать.
Теперь вернемся в Visual Studio и откроем "Package Manager Console". В списке "Package Source" теперь можно выбирать из трех вариантов: все источники, официальный репозиторий NuGet и добавленный "Local NuGet repository". Выберем последний в качестве текущего. Введем команду для просмотра списка доступных установочных пакетов: "Get-Package -ListAvailable". В результате будет выведен перечень библиотек из локального репозитория.
Давайте рассмотрим схемы использования этой возможности:
- Контроль за устанавливаемыми компонентами. Например, локально могут размещаться только библиотеки, разрешенные к использованию в проектах компании (например, соответствующие её лицензионной политике).
- В некоторых случаях может пригодиться локальный кэш компонентов.
- Локально могут быть размещены компоненты, отсутствующие в официальном репозитории NuGet.
Последний случай хорошо подходит даже для индивидуальных разработчиков. Ведь у многих есть свои наработки, хранящиеся в виде библиотек. В этом случае очень удобно разместить их в локальном репозитории и подключать или обновлять в остальных проектах, используя NuGet.
Аналогично можно сказать и про организации. Собранные и проверенные отделом тестирования версии библиотек размещаются для использования разработчиками. Возможно только в этом случае, вместо варианта с папкой, подойдет решение в виде сервера с RSS-потоком или OData-сервисом.
Поэтому в следующей части разберемся, как самостоятельно создать сборку для NuGet.