Менеджер пакетов для .NET

    Менеджеры пакетов в том или ином их проявлении есть практически везде: Gems и Rip для Ruby, Maven для Java и море разливенное для различных дистрибутивов Linux и Unix. И только .NET-разработчики по старинке ползают по сайтам в поисках той или иной версии необходимой библиотеки.

    Будучи одним из таких разработчиков и устав от постоянных поисков требуемых компонентов, я решил, что с этим пора заканчивать. Результатом такого решения стал таки менеджер компонентов для платформы .NET

    Componento


    Встречайте: octalforty Componento (первая альфа доступна здесь для 32-битных ОС или здесь для 64-битных собратьев). Это, по моим сведениям, первая попытка создания менеджера пакетов для .NET.

    Механизм работы, в принципе, не сильно отличается от его аналогов в других средах: есть центральный репозиторий, к которому обращаются клиенты и откуда получают информацию о том, что и откуда загружать. Существенный недостаток заключается в том, что формат пакетов (по сути — zip-архивов) никак не стандартизирован, поэтому по сравнению с тем же Ruby в этом плане везде царит хаос. Но это все наживное (при условии удачного течения дел, разумеется).

    «Поехали!»


    Папку, в которую был разархивирован Componento, лучше всего добавить в PATH — дальше будет проще.

    Представим, что вы в самом начале разработки проекта и начинаете собирать необходимые библиотеки. Предположим, что структура папок проекта похожа на следующую:



    В src — исходный код самого продукта, в lib — сторонние библиотеки, ну а в doc, очевидно, документация.

    Настоящему .NET-разработчику нельзя и шага ступить без юнит-тестов и ORM-средства. Посему, на первом этапе нам потребуются NUnit, NHibernate и Fluent NHibernate. Приступим:

    C:\>cd d:\projects\acme\lib
    
    E:\Projects\Acme\lib>componento list
    


    На такую команду Componento вполне резонно ответит тем, что, мол, «No packages installed». Посмотртим, какие компоненты есть на сервере:

    E:\Projects\Acme\lib>componento list /remote
    
    octalforty Componento 1.0 Alpha 1
    Copyright (c) 2009 octalforty studios
    
    Downloading 4,3 Kb
    autofac (1.4.4.561)
    bltoolkit (3.0)
    ...
    fluent-nhibernate (1.0)
    ...
    nhibernate (1.2.1)
    nhibernate (2.1.0)
    ...
    nunit (2.5.0.9122)
    nunit (2.5.1.9189)
    nunit (2.5.2.9222)
    ...
    urlrewriting.net (2.0)
    zedgraph (5.1.5)
    


    Отлично, как раз то, что нужно. componento install nunit — и самый свежий NUnit окажется в папке lib. Таким же образом устанавливаем nhibernate и fluent-nhibernate. В итоге получается вот что:



    Папка _componento — кэш загруженных файлов, а componento.db — база данных установленных компонентов и их зависимостей.

    Остальные возможности


    Командой componento install nunit /version 2.5.0.9122 можно было бы установить библиотеку NUnit версии 2.5.0.9122, а командой componento uninstall nunit /force /recursive удалить NUnit и все зависимости.

    Кроме того, Componento умеет устанавливать из репозиториев Subversion, папок и Zip-файлов. К примеру, componento install bltoolkit /source svn+http://bl-toolkit.googlecode.com/svn/trunk/ заберет из указанного репозитория все исходники BLToolkit (префикс svn+ в случае, когда доступ к репозиторию осуществляется через HTTP или HTTPS, обязателен). А команда componento install myproject /source d:\projects\myproject.zip «установит» архив myproject.zip.

    И пару слов о зависимостях. Если в корне папке, в которую Componento установит указанный компонент, окажется файл dependencies.txt примерно следующего содержания:

    nhibernate-linfu file:///e:/lib/nhibernate-linfu
    nhibernate-castle file:///e:/lib/nhibernate-castle


    то Componento рекурсивно установит все зависимости, а впоследствии будет проверять конфликты версий и не даст так просто удалить компонент, если на него есть зависимости.

    Минусы и недоработки


    Их много. Во-первых, нет формата пакета как такового. То есть, абсолютно отсутствуют метаданные о компоненте (разве что есть версия и название). Во-вторых, не до конца продумана работа с локальными папками и архивами. В третьих, пока нет возможности публиковать свои компоненты в центральном репозитории (в задумках как веб-интерфейс, так и отдельный API для публикации компонентов). В четвертых, не оформлена поддержка платформ (к примеру, разделение компонентов на оные для Silverlight, .NET 2.0, .NET 3.0 и т.д.). Ну и в целом — это всего лишь первая альфа.

    Вместо заключения


    Я пока не готов выставлять данное творение на суд англоязычной публики; для начала надо получить что-то более существенное. Поесему предложения, пожелания, комментарии и критика приветствуются. Давайте уже построим менеджер пакетов для .NET!

    Similar posts

    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 37

      0
      Apache Maven это не только «менеджер компонентов», но и среда управления жизненным циклом приложений.
        +1
        Я в курсе. Но он же и менеджер пакетов, что имеет непосредственное отношение к теме.
      • UFO just landed and posted this here
          +4
          Не знал. А поподробней?
          0
          У Microsoft есть подобие менеджера пакетов для Web: Microsoft Web Platform
          А, вообще, идея хорошая и восстребованная.
            0
            Byldan, NMaven, Maven.net не смотрели?
              0
              Это все немного не то. Componento не занимается сборкой проектов, а является исключительно менеджером пакетов.
              –3
              Нужен AppStore для .NET (а в перспективе для любых приложений для Windows)
              С похожими условиями — платное размещение; проверка исходников программистами Microsoft; поиск, покупка, оплата кредиткой, установка и удаление приложений в пару кликов.

              Я никогда не покупал столько софта, пока у меня не появился iPhone.
                –1
                Таких апсторов есть тысячи.
                Те же даунлоад.ком, да еще и без левого контроля цензуры.
                  0
                  1. такой аппстор всего один — у Apple
                  Репозитории Linux немного похожи на аппстор, своей централизованностью (весь софт в одной куче), кое-каким удобством установки софта (через стандартный менеджер пакетов). исходники проверяются (опенсорс всё-таки).
                  поиск, установка, удаление — всё есть.
                  денег нет. аудитория ограничена гиками и сисадминами.
                  разработчикам коммерческого прикладного софта там делать практически нечего.

                  2. тысячи файлопомоек и софтоотстойников — это просто какие-то сайты в сети.
                  их минус как раз в том, что их тысячи.
                  они не интегрированы в систему
                  нет единого менеджера софта
                  каждую программу нужно устанавливать по-своему, а удалять — как повезёт.
                  их использовать ничуть не проще, чем популярные варезники — так зачем платить больше? :)

                  вы действительно не видите разницы между AppStore Apple и тысячами апсторов?

                  за четыре года у меня никогда не возникало желания купить софт под мои Winmobile-коммуникаторы — искать софт и сайт продавца гуглем, читать отзывы по форумам, вручную скачивать и устанавливать, и при это ещё и платить (каким-нибудь странным способом). затратив точно такие же усилия я мог получить бeсплатно взломаную версию.

                  за полгода использования iPhone я купил пару десятков программ, просто потому, что купить нужную программу можно очень просто и удобно, в пару тыков пальцем в экран.

                  В этом сокровенный смысл AppStore — пользователям очень просто купить нужный софт.
                  Разработчикам очень просто выставить свой софт на продажу.
                  Apple — радуется росту популярности своих коммуникаторов и имеет (если вообще) небольшой процент с продаж софта.

                  Все в выигрыше.
                  А гики и бедные студенты могут и дальше пользоваться тысячами апсторов и устанавливать софт из Сидии или качать его с варезников.
                    –2
                    AppStore — гавно :)

                    Почему? Да потому что централизация — это плохо… Плохо когда кто-то «один» решает чему быть а чему не быть. Аргумент — «им веднее» не прокатит…

                    Для примера: я могу в AppStore купить программу для подделки дипломов государственного образца? :)))
                      0
                      я согласен поступиться возможностью покупки программы для подделки дипломов государственного образца ради удобства использования централизованного аппстора с тысячами существующих в нём программ

                        0
                        Если я на определенном сервисе не могу купить нужную мне программу то удобство такого серсиса рано НУЛЮ! :)
                          0
                          чёрт, да ты тролль, однако
                            0
                            Так черт или троль? :)

                            И как бы я оргументировал что полезность AppStore для меня и кучи других людей равна НУЛУ :)))
                  0
                  Идея хорошая, украду для проекта. Спасибо.
                    0
                    какая именно идея? :)
                  0
                  Скачал и попопытался запустить:
                  D:\componento>componento.exe list /remote
                  octalforty Componento 1.0 Alpha 1
                  Copyright © 2009 octalforty studios

                  Unhandled Exception: System.ComponentModel.Composition.CompositionException: The
                  composition produced a single composition error. The root cause is provided bel
                  ow. Review the CompositionException.Errors property for more detailed informatio
                  n.

                  1) Could not load file or assembly 'System.Data.SQLite, Version=1.0.61.0, Cultur
                  e=neutral, PublicKeyToken=db937bc2d44ff139' or one of its dependencies. An attem
                  pt was made to load a program with an incorrect format.

                    0
                    64-битная Windows?
                      0
                      Да
                        0
                        System.Data.SQLite — это такая хитрая штучка… Это т.н. mixed-mode assembly, которая, в отличие от fully managed, компилируется под строго определенную архитектуру процессора. Выхода два — либо найти ту же версию System.Data.SQLite.dll для x64, либо скомпилировать Componento только для x86. Для начала попробую поискать библиотеку.
                          0
                          Собственно, вот — специальная сборка для x64. Должная сработать, пробуйте.
                    +1
                    Если запустить без параметров или с параметром /remote, то упадет с IndexOutOfRange- или NullReference-(убивать! убивать!)-Exception
                      0
                      В курсе, спасибо.
                      0
                      Еще вопрос: что делать, если я хочу у себя в компании развернуть репозиторий с артефактами, а не тянуть непонятно откуда (так в maven)? Как настроить ваше приложение?
                        +1
                        Пока все просто: по умолчанию Componento пытается загрузить список компонентов отсюда. Так что если на локальном веб-сервере разместить файл packages.cpri, то componento list /source http:// localhost/ (/packages.cpri добавляется автоматически) должно сработать. Вот только устанавливать компоненты придется командой componento install mycomponent /source componento+http://localhost — префикс componento+ необходим, чтобы понимать, что это — репозиторий, а не что-то еще; непоследовательное же его (префикса) использование — издержки альфы.

                        Есть мысль организовывать хранилище компонентов в виде well-known структуры папок, но пока это на уровне идеи.
                        +1
                        Проект интересный, потребность в менеджере пакетов есть, Maven тяжеловат и с .net не очень хорошо дружит.
                        Отметил бы два момента —
                        во-первых в build-process это все должно легко встраиваться — tasks для nant/msbuild сразу надо
                        во-вторых привыкших к визуальным средствам .net разработчикам объяснять что еще надо зависимости в отдельном файле описывать — … — хотелось бы просто скармливать те же файлы с проектами visual studio менеджеру пакетов, а он бы извлекал из них необходимые зависимости и скачивал библиотеки.

                          0
                          Да и кстати еще посмотрите на Ivy.
                            0
                            Слабо себе представляю нужду.
                            Если для Java есть EJB, то в .NET я не вижу такой единой спецификации компонентов и даже для Java это не так, потому что мир JavaBeans не ограничен. А так сваливать в кучу разнородных элементов с разными API? CodeProject, CodePlex, Sourcefourge имеют ещё и обсуждения где можно почитать об практике использования, pros и contras каждого, а здесь ну будет рейтинг в надцать попугаев, а оcтальное?
                            Хотя возможно для веб дивелопера это и имеет какой-то смысл, да и то в рамках одного движка, ведь не будут работать модули для DotNetNuke в SharePoint. А если порубать всё на сегменты, то изза небольшого количества компонентов для конкретного продукта смысл небольшой.
                            Как build-process в мире .NET не так уж принято перестраивать сторонние компоненты, а для личных проэктов msbuild достаточно мощная система.
                            Из тех примеров что с наскоку увидел с Maven это продукт для создания пакетов, но его нужда как раз особенностях java пакетов(упаковка в jar, метаданные, ресурсы, структура размещения файлов), в большинстве этого нужды в .NET нет. А для дистрибуции всё таки принят msi и другие системы распространения.
                              +1
                              Ну вы видимо не совсем поняли зачем нужен проект. Задача менеджера пакетов — не в том чтобы выбрать нужную библиотеку (для этого — да, CodeProject, CodePlex n etc.), а в том чтобы для имеющегося проекта собрать все необходимые пакеты без лишних трудозатрат.

                              >Если для Java есть EJB

                              EJB в коматозном состоянии уже черт знает сколько лет, плохой пример.

                              >Как build-process в мире .NET не так уж принято перестраивать сторонние компоненты

                              Ну как вас сказать — не знаю что принято, а я большинство open-source библиотек, которые использую собираю из исходников изначально.

                              >Из тех примеров что с наскоку увидел с Maven это продукт для создания пакетов, но его нужда как раз особенностях java пакетов(упаковка в jar, метаданные, ресурсы, структура размещения файлов), в большинстве этого нужды в .NET нет. А для дистрибуции всё таки принят msi и другие системы распространения.

                              Аналог .jar для .NET — это не .msi отнюдь, а просто Assembly (.dll)

                                0
                                >Ну вы видимо не совсем поняли зачем нужен проект. Задача менеджера пакетов — не в том чтобы выбрать нужную библиотеку (для этого — да, CodeProject, CodePlex n etc.), а в том чтобы для имеющегося проекта собрать все необходимые пакеты без лишних трудозатрат.

                                Я посмотрел например maven, в мире .NET болшую часть действий исполнять просто не нужно, а действий вроде регистрации COM+ объектов в java мире просто не нужно. А msbuild уже достаточно мощный инструмент, нужно только отбросить предубеждение и покурить документацию. А тянуть привычки из других языков которые в .NET выглядят как излишество не вижу смысла.

                                > Ну как вас сказать — не знаю что принято, а я большинство open-source библиотек, которые использую собираю из исходников изначально.
                                Те некоторые opensource библиотеки что я использую, так или иначе имеют файл проэкта, так что в свой проэкт добавить вызов построения не составит труда. Это две-три строчки в msbuild файле.
                                />


                                У любой сторонней библиотеки есть некоторый цыкл разработки, обычно не синхронизированный с вашим, потому перестраивать все зависимости у библиотек которые не меняются по меньшей мере неразумно. А перестроить раз в месяц в лучшем случае не думаю что большая проблема.

                            +1
                            Идея хорошая.

                            Я думал такое сделать (если добавить новый Tab в Add Reference… в VS, будет совсем удобно, а это вполне возможно). Но тут важен сам сайт (репозиторий компонентов, etc). Это сделать интересно, но долго.

                            (мелочь: название не очень: octalforty Componento, скорее с Java ассоциируется).
                              0
                              Неплохая идея. Я на данный момент использую ClickOnce в надежде что каждый кто один раз найдет мое приложение может потом постоянно его обновлять. Иметь каталог — неплохо, особенно когда хочется просто побродить и поискать что интересного есть под .Net.
                                0
                                code.google.com/p/hornget/ — не лучше?

                                Only users with full accounts can post comments. Log in, please.