Комментарии 37
Apache Maven это не только «менеджер компонентов», но и среда управления жизненным циклом приложений.
У Microsoft есть подобие менеджера пакетов для Web: Microsoft Web Platform
А, вообще, идея хорошая и восстребованная.
А, вообще, идея хорошая и восстребованная.
Byldan, NMaven, Maven.net не смотрели?
Нужен AppStore для .NET (а в перспективе для любых приложений для Windows)
С похожими условиями — платное размещение; проверка исходников программистами Microsoft; поиск, покупка, оплата кредиткой, установка и удаление приложений в пару кликов.
Я никогда не покупал столько софта, пока у меня не появился iPhone.
С похожими условиями — платное размещение; проверка исходников программистами Microsoft; поиск, покупка, оплата кредиткой, установка и удаление приложений в пару кликов.
Я никогда не покупал столько софта, пока у меня не появился iPhone.
Таких апсторов есть тысячи.
Те же даунлоад.ком, да еще и без левого контроля цензуры.
Те же даунлоад.ком, да еще и без левого контроля цензуры.
1. такой аппстор всего один — у Apple
Репозитории Linux немного похожи на аппстор, своей централизованностью (весь софт в одной куче), кое-каким удобством установки софта (через стандартный менеджер пакетов). исходники проверяются (опенсорс всё-таки).
поиск, установка, удаление — всё есть.
денег нет. аудитория ограничена гиками и сисадминами.
разработчикам коммерческого прикладного софта там делать практически нечего.
2. тысячи файлопомоек и софтоотстойников — это просто какие-то сайты в сети.
их минус как раз в том, что их тысячи.
они не интегрированы в систему
нет единого менеджера софта
каждую программу нужно устанавливать по-своему, а удалять — как повезёт.
их использовать ничуть не проще, чем популярные варезники — так зачем платить больше? :)
вы действительно не видите разницы между AppStore Apple и тысячами апсторов?
за четыре года у меня никогда не возникало желания купить софт под мои Winmobile-коммуникаторы — искать софт и сайт продавца гуглем, читать отзывы по форумам, вручную скачивать и устанавливать, и при это ещё и платить (каким-нибудь странным способом). затратив точно такие же усилия я мог получить бeсплатно взломаную версию.
за полгода использования iPhone я купил пару десятков программ, просто потому, что купить нужную программу можно очень просто и удобно, в пару тыков пальцем в экран.
В этом сокровенный смысл AppStore — пользователям очень просто купить нужный софт.
Разработчикам очень просто выставить свой софт на продажу.
Apple — радуется росту популярности своих коммуникаторов и имеет (если вообще) небольшой процент с продаж софта.
Все в выигрыше.
А гики и бедные студенты могут и дальше пользоваться тысячами апсторов и устанавливать софт из Сидии или качать его с варезников.
Репозитории Linux немного похожи на аппстор, своей централизованностью (весь софт в одной куче), кое-каким удобством установки софта (через стандартный менеджер пакетов). исходники проверяются (опенсорс всё-таки).
поиск, установка, удаление — всё есть.
денег нет. аудитория ограничена гиками и сисадминами.
разработчикам коммерческого прикладного софта там делать практически нечего.
2. тысячи файлопомоек и софтоотстойников — это просто какие-то сайты в сети.
их минус как раз в том, что их тысячи.
они не интегрированы в систему
нет единого менеджера софта
каждую программу нужно устанавливать по-своему, а удалять — как повезёт.
их использовать ничуть не проще, чем популярные варезники — так зачем платить больше? :)
вы действительно не видите разницы между AppStore Apple и тысячами апсторов?
за четыре года у меня никогда не возникало желания купить софт под мои Winmobile-коммуникаторы — искать софт и сайт продавца гуглем, читать отзывы по форумам, вручную скачивать и устанавливать, и при это ещё и платить (каким-нибудь странным способом). затратив точно такие же усилия я мог получить бeсплатно взломаную версию.
за полгода использования iPhone я купил пару десятков программ, просто потому, что купить нужную программу можно очень просто и удобно, в пару тыков пальцем в экран.
В этом сокровенный смысл AppStore — пользователям очень просто купить нужный софт.
Разработчикам очень просто выставить свой софт на продажу.
Apple — радуется росту популярности своих коммуникаторов и имеет (если вообще) небольшой процент с продаж софта.
Все в выигрыше.
А гики и бедные студенты могут и дальше пользоваться тысячами апсторов и устанавливать софт из Сидии или качать его с варезников.
AppStore — гавно :)
Почему? Да потому что централизация — это плохо… Плохо когда кто-то «один» решает чему быть а чему не быть. Аргумент — «им веднее» не прокатит…
Для примера: я могу в AppStore купить программу для подделки дипломов государственного образца? :)))
Почему? Да потому что централизация — это плохо… Плохо когда кто-то «один» решает чему быть а чему не быть. Аргумент — «им веднее» не прокатит…
Для примера: я могу в AppStore купить программу для подделки дипломов государственного образца? :)))
Идея хорошая, украду для проекта. Спасибо.
Скачал и попопытался запустить:
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.
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.
64-битная Windows?
Да
System.Data.SQLite — это такая хитрая штучка… Это т.н. mixed-mode assembly, которая, в отличие от fully managed, компилируется под строго определенную архитектуру процессора. Выхода два — либо найти ту же версию System.Data.SQLite.dll для x64, либо скомпилировать Componento только для x86. Для начала попробую поискать библиотеку.
Собственно, вот — специальная сборка для x64. Должная сработать, пробуйте.
Тоже самой. Не та версия библиотеки.
Скачал отсюда sourceforge.net/projects/sqlite-dotnet2/files/SQLite%20for%20ADO.NET%202.0/1.0.61.0/SQLite-1.0.61.0-managedonly-binaries.zip/download и подставил нужную.
Скачал отсюда sourceforge.net/projects/sqlite-dotnet2/files/SQLite%20for%20ADO.NET%202.0/1.0.61.0/SQLite-1.0.61.0-managedonly-binaries.zip/download и подставил нужную.
Если запустить без параметров или с параметром /remote, то упадет с IndexOutOfRange- или NullReference-(убивать! убивать!)-Exception
Еще вопрос: что делать, если я хочу у себя в компании развернуть репозиторий с артефактами, а не тянуть непонятно откуда (так в maven)? Как настроить ваше приложение?
Пока все просто: по умолчанию Componento пытается загрузить список компонентов отсюда. Так что если на локальном веб-сервере разместить файл
Есть мысль организовывать хранилище компонентов в виде well-known структуры папок, но пока это на уровне идеи.
packages.cpri, то componento list /source http:// localhost/ (/packages.cpri добавляется автоматически) должно сработать. Вот только устанавливать компоненты придется командой componento install mycomponent /source componento+http://localhost — префикс componento+ необходим, чтобы понимать, что это — репозиторий, а не что-то еще; непоследовательное же его (префикса) использование — издержки альфы.Есть мысль организовывать хранилище компонентов в виде well-known структуры папок, но пока это на уровне идеи.
Проект интересный, потребность в менеджере пакетов есть, Maven тяжеловат и с .net не очень хорошо дружит.
Отметил бы два момента —
во-первых в build-process это все должно легко встраиваться — tasks для nant/msbuild сразу надо
во-вторых привыкших к визуальным средствам .net разработчикам объяснять что еще надо зависимости в отдельном файле описывать — … — хотелось бы просто скармливать те же файлы с проектами visual studio менеджеру пакетов, а он бы извлекал из них необходимые зависимости и скачивал библиотеки.
Отметил бы два момента —
во-первых в build-process это все должно легко встраиваться — tasks для nant/msbuild сразу надо
во-вторых привыкших к визуальным средствам .net разработчикам объяснять что еще надо зависимости в отдельном файле описывать — … — хотелось бы просто скармливать те же файлы с проектами visual studio менеджеру пакетов, а он бы извлекал из них необходимые зависимости и скачивал библиотеки.
Да и кстати еще посмотрите на Ivy.
Слабо себе представляю нужду.
Если для Java есть EJB, то в .NET я не вижу такой единой спецификации компонентов и даже для Java это не так, потому что мир JavaBeans не ограничен. А так сваливать в кучу разнородных элементов с разными API? CodeProject, CodePlex, Sourcefourge имеют ещё и обсуждения где можно почитать об практике использования, pros и contras каждого, а здесь ну будет рейтинг в надцать попугаев, а оcтальное?
Хотя возможно для веб дивелопера это и имеет какой-то смысл, да и то в рамках одного движка, ведь не будут работать модули для DotNetNuke в SharePoint. А если порубать всё на сегменты, то изза небольшого количества компонентов для конкретного продукта смысл небольшой.
Как build-process в мире .NET не так уж принято перестраивать сторонние компоненты, а для личных проэктов msbuild достаточно мощная система.
Из тех примеров что с наскоку увидел с Maven это продукт для создания пакетов, но его нужда как раз особенностях java пакетов(упаковка в jar, метаданные, ресурсы, структура размещения файлов), в большинстве этого нужды в .NET нет. А для дистрибуции всё таки принят msi и другие системы распространения.
Если для Java есть EJB, то в .NET я не вижу такой единой спецификации компонентов и даже для Java это не так, потому что мир JavaBeans не ограничен. А так сваливать в кучу разнородных элементов с разными API? CodeProject, CodePlex, Sourcefourge имеют ещё и обсуждения где можно почитать об практике использования, pros и contras каждого, а здесь ну будет рейтинг в надцать попугаев, а оcтальное?
Хотя возможно для веб дивелопера это и имеет какой-то смысл, да и то в рамках одного движка, ведь не будут работать модули для DotNetNuke в SharePoint. А если порубать всё на сегменты, то изза небольшого количества компонентов для конкретного продукта смысл небольшой.
Как build-process в мире .NET не так уж принято перестраивать сторонние компоненты, а для личных проэктов msbuild достаточно мощная система.
Из тех примеров что с наскоку увидел с Maven это продукт для создания пакетов, но его нужда как раз особенностях java пакетов(упаковка в jar, метаданные, ресурсы, структура размещения файлов), в большинстве этого нужды в .NET нет. А для дистрибуции всё таки принят msi и другие системы распространения.
Ну вы видимо не совсем поняли зачем нужен проект. Задача менеджера пакетов — не в том чтобы выбрать нужную библиотеку (для этого — да, CodeProject, CodePlex n etc.), а в том чтобы для имеющегося проекта собрать все необходимые пакеты без лишних трудозатрат.
>Если для Java есть EJB
EJB в коматозном состоянии уже черт знает сколько лет, плохой пример.
>Как build-process в мире .NET не так уж принято перестраивать сторонние компоненты
Ну как вас сказать — не знаю что принято, а я большинство open-source библиотек, которые использую собираю из исходников изначально.
>Из тех примеров что с наскоку увидел с Maven это продукт для создания пакетов, но его нужда как раз особенностях java пакетов(упаковка в jar, метаданные, ресурсы, структура размещения файлов), в большинстве этого нужды в .NET нет. А для дистрибуции всё таки принят msi и другие системы распространения.
Аналог .jar для .NET — это не .msi отнюдь, а просто Assembly (.dll)
>Если для Java есть EJB
EJB в коматозном состоянии уже черт знает сколько лет, плохой пример.
>Как build-process в мире .NET не так уж принято перестраивать сторонние компоненты
Ну как вас сказать — не знаю что принято, а я большинство open-source библиотек, которые использую собираю из исходников изначально.
>Из тех примеров что с наскоку увидел с Maven это продукт для создания пакетов, но его нужда как раз особенностях java пакетов(упаковка в jar, метаданные, ресурсы, структура размещения файлов), в большинстве этого нужды в .NET нет. А для дистрибуции всё таки принят msi и другие системы распространения.
Аналог .jar для .NET — это не .msi отнюдь, а просто Assembly (.dll)
>Ну вы видимо не совсем поняли зачем нужен проект. Задача менеджера пакетов — не в том чтобы выбрать нужную библиотеку (для этого — да, CodeProject, CodePlex n etc.), а в том чтобы для имеющегося проекта собрать все необходимые пакеты без лишних трудозатрат.
Я посмотрел например maven, в мире .NET болшую часть действий исполнять просто не нужно, а действий вроде регистрации COM+ объектов в java мире просто не нужно. А msbuild уже достаточно мощный инструмент, нужно только отбросить предубеждение и покурить документацию. А тянуть привычки из других языков которые в .NET выглядят как излишество не вижу смысла.
> Ну как вас сказать — не знаю что принято, а я большинство open-source библиотек, которые использую собираю из исходников изначально.
Те некоторые opensource библиотеки что я использую, так или иначе имеют файл проэкта, так что в свой проэкт добавить вызов построения не составит труда. Это две-три строчки в msbuild файле.
У любой сторонней библиотеки есть некоторый цыкл разработки, обычно не синхронизированный с вашим, потому перестраивать все зависимости у библиотек которые не меняются по меньшей мере неразумно. А перестроить раз в месяц в лучшем случае не думаю что большая проблема.
Я посмотрел например maven, в мире .NET болшую часть действий исполнять просто не нужно, а действий вроде регистрации COM+ объектов в java мире просто не нужно. А msbuild уже достаточно мощный инструмент, нужно только отбросить предубеждение и покурить документацию. А тянуть привычки из других языков которые в .NET выглядят как излишество не вижу смысла.
> Ну как вас сказать — не знаю что принято, а я большинство open-source библиотек, которые использую собираю из исходников изначально.
Те некоторые opensource библиотеки что я использую, так или иначе имеют файл проэкта, так что в свой проэкт добавить вызов построения не составит труда. Это две-три строчки в msbuild файле.
/>
У любой сторонней библиотеки есть некоторый цыкл разработки, обычно не синхронизированный с вашим, потому перестраивать все зависимости у библиотек которые не меняются по меньшей мере неразумно. А перестроить раз в месяц в лучшем случае не думаю что большая проблема.
Идея хорошая.
Я думал такое сделать (если добавить новый Tab в Add Reference… в VS, будет совсем удобно, а это вполне возможно). Но тут важен сам сайт (репозиторий компонентов, etc). Это сделать интересно, но долго.
(мелочь: название не очень: octalforty Componento, скорее с Java ассоциируется).
Я думал такое сделать (если добавить новый Tab в Add Reference… в VS, будет совсем удобно, а это вполне возможно). Но тут важен сам сайт (репозиторий компонентов, etc). Это сделать интересно, но долго.
(мелочь: название не очень: octalforty Componento, скорее с Java ассоциируется).
Неплохая идея. Я на данный момент использую ClickOnce в надежде что каждый кто один раз найдет мое приложение может потом постоянно его обновлять. Иметь каталог — неплохо, особенно когда хочется просто побродить и поискать что интересного есть под .Net.
code.google.com/p/hornget/ — не лучше?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Менеджер пакетов для .NET