Комментарии 28
что скажете по поводу того, что nant скорее мертв, чем жив и что не обновлялся уже несколько лет? вообще после создания своего CI и пляски с msbuild'ом, nant'ом у меня возникло стойкое отвращение к описанию build процесса в xml'е при отсутствии визуальных средств.
сейчас прикрутил psake — рад нещадно github.com/JamesKovacs/psake
сейчас прикрутил psake — рад нещадно github.com/JamesKovacs/psake
> при отсутствии визуальных средств
вот сюда гляньте: www.attrice.info/msbuild/index.htm
вот сюда гляньте: www.attrice.info/msbuild/index.htm
спасибо, но это за деньги. да косяков у msbuild'а хватает, чего стоит, что properties исполняются с include=* на момент парсинга конфига, а не в момент использования — от чего вылезают очень интересные косяки, если вам, например, надо что то сделать с файлами после build'а посредством properties. в баню этот msbuild — я за скриптовой build скрипт.
nant в этом году ожил.
не могу сейчас посмотреть точно (пишу комментарий с телефона) но вроде как последняя версия 0.91alpha была в июне этого года.
не могу сейчас посмотреть точно (пишу комментарий с телефона) но вроде как последняя версия 0.91alpha была в июне этого года.
НЛО прилетело и опубликовало эту надпись здесь
Мы щас пытаемся уйти с nant, на чистый msbuild. Отличия минимальны, а вот расхаоды на интеграцию какието ненормальные. Чего тока стоит эпопея с потдержкой .NET 4.0. Хотя надо отдать должность, Win SDK в отличии от нанта в реопзитарий не положиш.
Кстати, для второго пункта есть еще третяя опция (ИМХО правильная). Это Microsoft.WebApplication.targets и Microsoft.Web.Publishing.targets. Там уже все есть для паблишенга. Правда слету разобратся сложновато.
Публикуйте вторую часть. Думаю, многим будет интересно.
полюбому надо вторую статью, ато как то не полно получилось
у нас все на чистом msbuild но геморно добавлять новые проекты
так же интересно (хотя это уже не совсем в тему) как быть с базой и с откатами
у нас все на чистом msbuild но геморно добавлять новые проекты
так же интересно (хотя это уже не совсем в тему) как быть с базой и с откатами
Используем для тех же целей MSBuild. Хотя от XML в конфигурациях просто тошнит — особенно противно от WiX. Надо что-то с этим делать, чтобы был intellisense и все плюшки не только для конфига но и для файлов настройки. p.s.: xsd для intellisense не предлагать — знаю, пользуюсь, плююсь.
Я понимаю, что на определеном этапе развития .NET было оправдано адаптировать технологии из Java — тот же NAnt, NHibernate и т.д.
Но сейчас-то появляются продукты, разработанные именно для .net и без Java'вских косяков, тот же MSBuild, Linq2SQL и т.д.
В чем же прикол до сих пор использовать в новых продуктах устаревшие фреймворки?
Но сейчас-то появляются продукты, разработанные именно для .net и без Java'вских косяков, тот же MSBuild, Linq2SQL и т.д.
В чем же прикол до сих пор использовать в новых продуктах устаревшие фреймворки?
Насколько я знаю, разработка Linq2SQL прекращена, в отличие от NHibernate.
На счет MSBuild — по возможностям он практически повторяет NAnt.
Можете привести конкретные причины, по которым Вы считаете NAnt и NHibernate «устаревшими фреймворками» (а также интересуют примеры «Java'вских косяков»)?
На счет MSBuild — по возможностям он практически повторяет NAnt.
Можете привести конкретные причины, по которым Вы считаете NAnt и NHibernate «устаревшими фреймворками» (а также интересуют примеры «Java'вских косяков»)?
На смену Linq2SQL пришел Linq2Entities с еще более широкими возможностями. К слову сказать я в своих проектах до сих пор использую Linq2SQL, поскольку его возможностей, быстродействия и удобства мне вполне хватает. Ну а если требуется что-то экстра-ординарное, то хранимые процедуры ни один фреймворк не перебьет. Так что явных бонусов перехода на Linq2Entities я для себя не вижу, хотя за развитием слежу, чтобы не оказаться за бортом.
Так вот, с Linq2SQL я работаю напрямую из Visual Studio, в графическом радакторе. NHibernate — как обычно в Java-world, засучил рукава и вперед — лопатить xml в редакторе в обнимку с доками, потому как очень легко облажаться в синтаксисе.
Реально это и есть самый главный косяк переноса из Java в .net — большая любовь все законфигурить через xml, не предоставляя инструментов как это удобно сделать из Visual Studio.
С NAnt я знаком чисто из любопытства, на работе у нас MS Build. Чисто из интереса — есть ли какая-то причина чтобы я выбрал NAnt вместо MS native MS Build?
Так вот, с Linq2SQL я работаю напрямую из Visual Studio, в графическом радакторе. NHibernate — как обычно в Java-world, засучил рукава и вперед — лопатить xml в редакторе в обнимку с доками, потому как очень легко облажаться в синтаксисе.
Реально это и есть самый главный косяк переноса из Java в .net — большая любовь все законфигурить через xml, не предоставляя инструментов как это удобно сделать из Visual Studio.
С NAnt я знаком чисто из любопытства, на работе у нас MS Build. Чисто из интереса — есть ли какая-то причина чтобы я выбрал NAnt вместо MS native MS Build?
Несомненно Linq2SQL и Linq2Entities (наверно, Вы все-таки имели в виду Entity Framework) отличные средства для работы с данными.
К сожалению, это все же относительно новые и незрелые инструменты, по сравнению с NHibernate. В т.ч. они содержат некоторые проблемы, которые в NH уже давно решены. Например, даже последний EF 4 не поддерживает пакетную запись/чтение данных.
Кроме того, в EF значительно сложнее сделать что-то, что выходит за пределы возможностей, предоставляемых фреймворком. NHibernate же в большинстве случаев легко расширяется.
Для NHibernate существует большое количество различных утилит, облегчающих настройку мэппинга (в т.ч. и с GUI), так что, можно сказать, «самый главный косяк переноса из Java в .NET» отсутствует. (А если честно, то никакие утилиты и не нужны. Настройка мэппинга в XML только кажется страшной — на самом деле, там все просто.)
Более того, (я вижу, что Вам нравится использовать LINQ) для NHibernate реализован LINQ-провайдер (правда, стоит признать, что реализован не так хорошо, как для Entity Framework).
— Я пишу все это не для того, чтобы сказать «NHibernate лучше, чем Entity Framework». Я думаю, что оба этих продукта прекрасно выполняют свои функции и выбор, какой продукт использовать, зависит от конкретной задачи и от предпочтений конкретного разработчика. Просто попробовал обратить Ваше внимание на достоинства NHibernate.
К сожалению, это все же относительно новые и незрелые инструменты, по сравнению с NHibernate. В т.ч. они содержат некоторые проблемы, которые в NH уже давно решены. Например, даже последний EF 4 не поддерживает пакетную запись/чтение данных.
Кроме того, в EF значительно сложнее сделать что-то, что выходит за пределы возможностей, предоставляемых фреймворком. NHibernate же в большинстве случаев легко расширяется.
Для NHibernate существует большое количество различных утилит, облегчающих настройку мэппинга (в т.ч. и с GUI), так что, можно сказать, «самый главный косяк переноса из Java в .NET» отсутствует. (А если честно, то никакие утилиты и не нужны. Настройка мэппинга в XML только кажется страшной — на самом деле, там все просто.)
Более того, (я вижу, что Вам нравится использовать LINQ) для NHibernate реализован LINQ-провайдер (правда, стоит признать, что реализован не так хорошо, как для Entity Framework).
— Я пишу все это не для того, чтобы сказать «NHibernate лучше, чем Entity Framework». Я думаю, что оба этих продукта прекрасно выполняют свои функции и выбор, какой продукт использовать, зависит от конкретной задачи и от предпочтений конкретного разработчика. Просто попробовал обратить Ваше внимание на достоинства NHibernate.
На счет MsBuild vs NAnt — на мой взгляд, нет объективных причин для выбора одного из них.
Эти инструменты содержат практически одинаковый набор возможностей и одинаковые неудобства.
Лично мне субъективно нравится NAnt и его конфиги мне легче понять.
Если Вы — сторонник MsBuild — то могу сказать, что Вы также выбрали отличный инструмент для автоматизации сборки приложений.
Эти инструменты содержат практически одинаковый набор возможностей и одинаковые неудобства.
Лично мне субъективно нравится NAnt и его конфиги мне легче понять.
Если Вы — сторонник MsBuild — то могу сказать, что Вы также выбрали отличный инструмент для автоматизации сборки приложений.
главный косяк переноса из java в .net чудесным образом затронул unity application block — там, стыдно признаться, тоже можно и нужно конфигурить контейнер через xml…
«Насколько я знаю, разработка Linq2SQL прекращена»
Откуда дровишки?
Откуда дровишки?
http://ayende.com/Blog/archive/2008/10/31/microsoft-kills-linq-to-sql.aspx
http://blogs.msdn.com/b/adonet/archive/2008/10/29/update-on-linq-to-sql-and-linq-to-entities-roadmap.aspx
Если честно, подробности не узнавал. Есть вероятность, что я что-то не так понял.
http://blogs.msdn.com/b/adonet/archive/2008/10/29/update-on-linq-to-sql-and-linq-to-entities-roadmap.aspx
Если честно, подробности не узнавал. Есть вероятность, что я что-то не так понял.
Да, не так поняли. По второй ссылке написано: «We are listening to customers regarding LINQ to SQL and will continue to evolve the product based on feedback we receive from the community as well.» Т.е., «мы будем продолжать развивать продукт, основываясь на».
А дальше все зависит от степени паникерства читающего.
А дальше все зависит от степени паникерства читающего.
не могу найти вторую часть. она была?
Добрый вечер!
Вторая часть в черновиках уже несколько лет. Она готова на 90%, но мне она не нравится и я не хотел бы ее выкладывать. Если хотите, могу ее прислать.
На мой взгляд, для автоматизации достаточно знать основы, описанные здесь, а все остальное — это связано с особенностями конкретных задач и легко ищется в гугле. Собственно, во второй части у меня получилось объемное описание этих особенностей, от которых без реальных задач мало пользы.
Вторая часть в черновиках уже несколько лет. Она готова на 90%, но мне она не нравится и я не хотел бы ее выкладывать. Если хотите, могу ее прислать.
На мой взгляд, для автоматизации достаточно знать основы, описанные здесь, а все остальное — это связано с особенностями конкретных задач и легко ищется в гугле. Собственно, во второй части у меня получилось объемное описание этих особенностей, от которых без реальных задач мало пользы.
>>Если хотите, могу ее прислать.
NAnt — очень актуальная сейчас для меня тема. Я был бы невероятно признателен, если бы Вы прислали или опубликовали вторую часть статьи (эта написана очень доступно и вдруг многое для меня прояснила). Таже, возможно, у Вас есть подборка ссылок с хорошими статьями про NAnt?
NAnt — очень актуальная сейчас для меня тема. Я был бы невероятно признателен, если бы Вы прислали или опубликовали вторую часть статьи (эта написана очень доступно и вдруг многое для меня прояснила). Таже, возможно, у Вас есть подборка ссылок с хорошими статьями про NAnt?
Вторая часть здесь, но это на другую тему, чем планировалось изначально.
Черновик первого варианта: http://sdrv.ms/1fefUNn.
Черновик первого варианта: http://sdrv.ms/1fefUNn.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Автоматизация сборки web-приложения на платформе .NET