Аннотация:
Статья рассказывает про новую систему сборки проектов от Microsoft – MSBuild. MSBuild будет входить в .NET Framework 2.0, а стало быть он станет основным средством сборки приложений для WinFX и новой версии Windows Longhorn. В статье рассказывается о принципах его работы, его API и средствах расширения.
Здравствуйте, Чистяков Влад (VladD2), Вы писали:
ЧВV>Есть только одна досада. Дело в том, что VS не позволяет открывать C#-проекты. Но VS можно обмануть, если переименовать файл, дав ему, например, расширение «.MyProj».
Можно проще. Кликнуть правой кнопкой по проекту в Solution Explorer'е. Выбрать Unload Project, соответствующий узел свернётся и станет сереньким. В его контекстном меню теперь появится пункт «Edit MyProj.csproj», который откроет csproj-файл в студийном XML-редакторе.
Здравствуйте, xvost, Вы писали:
X>Она не худшая.
Ну может быть есть поделки которые еще хуже но из извесных мне она однозначно худшая. X>В той нише, которую занимает СорсСэйф — он вне конкуренции.
Это какя ниша? X>По удобству использования в маленьких проектах тот же CVS нервно курит в стороне. А у больших команд/проектов и бюджет другой, они используют более продвинутые и дорогие инструменты.
Не помню как CVS (я с ним давно не работал) но по сравнению с SVN VSS нервно курит на проектах любого размера.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, xvost, Вы писали:
X>Да, может ты и интеграцию SVN с VisualStudio знаешь, сравнимую по удобству с VSS?
Кайф в том, что для SVN попросту не нужна интеграция в студию. Ну, максимум нужно комитилку на сервер сделать которая при закрытии проекта будет изменения на сервер сбрасывать.
Если приноровиться к SVN-у, то SS вспоминается как ночной кошмар. Это точно.
... << RSDN@Home 1.2.0 alpha rev. 554>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Многие конкурирующие среды (например, Borland Delphi) вообще не имели никаких средств компиляции вне IDE (вернее, такими средствами была сама IDE).
Оставим за рамками качество и удобство компиляторов командной строки в Delphi, но отметим тот факт, что они таки есть: dcc32 и make. Сейчас не имею доступа к более ранним версиям, но в Delphi 7 вышеуказанные утилиты уже есть.
Здравствуйте, xvost, Вы писали:
X>А в чем заключается "фи"?
В том, что MS который раз берется создавать аналог того, что и без того неплохо работает и, как говорится, единственный недостаток существующего в том, что это сделано не нами.
Можно посмотреть на это и с практической точки зрения. Я человек ленивый и изучать две вещи выполняющие одну и туже задачу с одним и тем же результатом мне лень. Ты можешь сказать, что меня никто это делать и не заставляет, но на практике я уверен, что на проетах мне придется столкнуться и с тем и с другим и все-таки пойти против своих принципов
X>В том, что MS в коммерческой разработке не опирается на опен-сорсовый проект,
В том, что она пытается занять нишу, которая в принципе уже заполнена. Я не против конкуренции, но смотри выше...
Опять же, как на этих форумах не раз говорилось — "прежде чем писать программу, подумай, а чем она будет отличаться от конкуртентов в лучшую сторону". Здесь я пока явных преимуществ не увидел.
X> а пытается сделать что-то свое? При этом я вполне уверен что у них получится лучше чем у ANT'а
А я вот не уверен. Я бы сказал 50 на 50. Это больше зависит от приоритетов в штабе MS. Согласись, что не все продукты от MS выгодно отличаются от конкурентов, в том числе и open source. Возьми, например, source safe — как я подозреваю, приоритет у этого направления в ms минимален и, как вывод, мы имеем худшую из систем контроля версий.
Опять же, не мне советовать, но если бы MS не распыляла бы свои силы, а сосредоточилась на нескольких направлениях, глядишь и MS SQL 2005 уже вышел бы, да и Longhorn не так долго ждать пришлось.
Но это все скорее философия. Я прекрасно понимаю, что от моего "фи" MS ни горячо, ни холодно.
Здравствуйте, VladD2, Вы писали:
A>>Интересно было бы узнать, есть ли у него какие-то преимущества по сравнению с другими решениями.
Угу. Я тоже попробовал прикинуть, а чем это лучше Ant(NAnt) и особо не понял.
VD>Как минимум отличная интеграция с VS 2005
И как следствие, сложность или даже невозможность привязать ее к другим средам разработки.
VD> и породистый родитель.
OpenSource звучит не только красиво, но еще и гордо
VD>Ну, а так... Вроде все описано. Продуманный декларативный синтаксис, хороший управляемый АПИ. Наличие рантайма во фрэймворке.
Как и в Ant.
VD>Корече, если ориентироваться на производство ПО под Виндовс, то лучше вряд ли можно что-то придумать.
Может быть. Но зная Ant, детально разбираться с еще одной аналогичной приблудой уже не очень хочется.
p.s. Не воспринимай, как упрек. Статья хорошая, скорее это очередное "фи" в сторону MS.
Здравствуйте, raskin, Вы писали:
R>GPL позволяет подкрутить для себя и никому не отдавать.
Любой измененный код обязан выпускаться под GPL и обязан быть доступен в исходных кодах. Более того. Даже использование этого кода в виде библиотеки обязывает выпускать такой продукт тоже под GPL. Есть правда еще LGPL который позволяет поставлять вместе с проприетарными продуктами LGPL-DLL-и и т.п. Но и там проблем хватает.
Короче конторе класса МС проще написать свой велосипед. Темболее что он хорошо совместим с Антом и НАнтом.
... << RSDN@Home 1.2.0 alpha rev. 557>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, raskin, Вы писали:
R>Помню — Дельфи 5, есть они. Уверен — были и раньше. Подозреваю — их и R>вызывает IDE.
Я распрощался с дельфи когда вышла 4-ка. Помню проводил эксперементы на трешке и они показали, что IDE занимается компиляцией самостоятельно. Причем только она позволяла компилировать проекты дельфи. Ну, и как водится экспорта в какие либло мэйки отсуствовали на прочь.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, DemAS, Вы писали:
DAS>Здравствуйте, xvost, Вы писали:
X>>А в чем заключается "фи"? DAS> В том, что MS который раз берется создавать аналог того, что и без того неплохо работает и, как говорится, единственный недостаток существующего в том, что это сделано не нами.
Помимо всего прочего — это очень существенный недостаток. Смотри сам:
1) До сих пор у них (MS) не существовало подобного решения. Соответсвенно, тем кому это надо — собирали солянку из инструментария, иногда крайне криво стыкующихся между собой. MS предлагает интегрированное решение. Что есть рулез.
2) Они пробиваются на этот рынок. Соответственно, увеличивают продажи студии. Это логично и правильно (с их стороны)
DAS> Можно посмотреть на это и с практической точки зрения. Я человек ленивый и изучать две вещи выполняющие одну и туже задачу с одним и тем же результатом мне лень. Ты можешь сказать, что меня никто это делать и не заставляет, но на практике я уверен, что на проетах мне придется столкнуться и с тем и с другим и все-таки пойти против своих принципов
Такова программисткая жизнь.
Приходтся постоянно держать нос по ветру новых технологий и инструментария.
X>>В том, что MS в коммерческой разработке не опирается на опен-сорсовый проект, DAS> В том, что она пытается занять нишу, которая в принципе уже заполнена. Я не против конкуренции, но смотри выше...
Во-первых, она не заполнена (про возможности интеграции nant'a в студию, или про визуальные ср-ва написания скриптов я скромно умолчу). Во-вторых — они пробиваются на новое направление.
Да и про масштабируемость nant'а я умолчу. Писали мы намедни новый task для него — матюги витали непрерывно.
DAS> Опять же, как на этих форумах не раз говорилось — "прежде чем писать программу, подумай, а чем она будет отличаться от конкуртентов в лучшую сторону". Здесь я пока явных преимуществ не увидел.
Как минимум интегрированность и удобная морда (то бишь GUI) — это очень много
DAS> А я вот не уверен. Я бы сказал 50 на 50. Это больше зависит от приоритетов в штабе MS. Согласись, что не все продукты от MS выгодно отличаются от конкурентов, в том числе и open source. Возьми, например, source safe — как я подозреваю, приоритет у этого направления в ms минимален и, как вывод, мы имеем худшую из систем контроля версий.
Она не худшая. В той нише, которую занимает СорсСэйф — он вне конкуренции. По удобству использования в маленьких проектах тот же CVS нервно курит в стороне. А у больших команд/проектов и бюджет другой, они используют более продвинутые и дорогие инструменты.
DAS> Опять же, не мне советовать, но если бы MS не распыляла бы свои силы, а сосредоточилась на нескольких направлениях, глядишь и MS SQL 2005 уже вышел бы, да и Longhorn не так долго ждать пришлось.
DAS> Но это все скорее философия. Я прекрасно понимаю, что от моего "фи" MS ни горячо, ни холодно.
С уважением, Евгений
JetBrains, Inc. "Develop with pleasure!"
VD>>Как минимум отличная интеграция с VS 2005
DAS> И как следствие, сложность или даже невозможность привязать ее к другим средам разработки.
А мне MsBuild наоборот нравится тем что его работы если студии нет, то можно прекрасно обойтись и бзе нее. У меня в данынй момент на работе стоит только фреймворк бета2 безо всяких 2005 студий и экпрессов. И для того чтобы собрать проект созданный в 2005 студии мне достаточно напустить на csproj тот же MsBuild и получить тот же результат что и при наличии студии.
Здравствуйте, xvost, Вы писали:
X>Бесплатных (вы же купили студию, да? ) source-control'ов, отлично интегрированных в среду разработки, и предоставляющих полный набор сервисов для одного/двух/трех разработчиков и проектов малого размера.
SVN бесплатен вне зависимости от того купил я студию или нет.
X>Да, может ты и интеграцию SVN с VisualStudio знаешь, сравнимую по удобству с VSS?
Прикол в том что SVN без интеграции со студией удобние чем VSS с интеграцией.
Мы на прошлой недели пересели с VSS на SVN. Переход занял пол дня в фоновом режиме.
После перехода я вобще перестал отвлекатся на систему контроля версий во время работы.
Плюс благодоря атомарным комитам вчера запустили билд после каждого комита. Причем после того как закончилась сборка информация о билде записывается в лог рядом с описанием комита.
Программист при комите написал
Пофиксил баги
после того как прошла сборака запись в логе изменилась на
Пофиксил баги SomeProject:3681 build OK
в будущем тудаже еще и результаты работы юнит-тестов попадать будут
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, xvost, Вы писали:
X>Да, может ты и интеграцию SVN с VisualStudio знаешь, сравнимую по удобству с VSS?
Я когда на SVN переходил, поначалу думал об интеграции, но потом, когда начал работать, понял что при использовании Tortoise интеграция нафиг не нужна (и даже иногда вредна).
eao197 wrote: > VD>>Далеко не единственный. NAnt и Ant — это GPL. А значит для > коммерческих разработчиков они закрыты. > > DAS> Не поняд. То есть, GPL запрещает не только использование кода в > коммерческом проекте, но и даже использование инттрументов под этой > лицензией ? > > Нет, инструменты можно использовать как угодно. Вероятно, Влад имел в > виду, что если какой-то компании потребуется build tool подкрутить под > свои нужды, то с GPL-мы инструментом эта доработка должна быть открыта. > Что для коммерческой компании может быть не приемлимо.
Подкрутить build tool под свои нужды и распространять, Вы имели в виду.
GPL позволяет подкрутить для себя и никому не отдавать.
Здравствуйте, eao197, Вы писали:
E>Нет, инструменты можно использовать как угодно. Вероятно, Влад имел в виду, что если какой-то компании потребуется build tool подкрутить под свои нужды, то с GPL-мы инструментом эта доработка должна быть открыта. Что для коммерческой компании может быть не приемлимо.
Даже без подкрутки использвать нельзя. Еще раз повторяю, MSBuild это далеко не утилита. Это и АПИ! Если они используют АПИ Анта (даже если оно прекрасно подойдет), то они обязаны будут выпустить студию под GPL. Что как понимаете в их планы не входит.
... << RSDN@Home 1.2.0 alpha rev. 557>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, PeterZT, Вы писали:
X>>Да, может ты и интеграцию SVN с VisualStudio знаешь, сравнимую по удобству с VSS? PZT>Я когда на SVN переходил, поначалу думал об интеграции, но потом, когда начал работать, понял что при использовании Tortoise интеграция нафиг не нужна (и даже иногда вредна).
Интересно... Я вот тоже недавно перешёл на SVN. Но не могу сказать что мне интеграция не нужна. А именно:
1. При коммите изменений можно забыть что-то сохранить в студии и закоммитить ерунду. Було такое пару раз с файлом проекта — все файлы сохранил вроде, а файл проекта — нет. Сейчас стал более внимателен, но интеграция в этом бы очень помогла.
2. переименование/перемещение файлов и папок. Как это сделать ? В данный момент я пользуюсь такой последовательностью: перемещаю файлы через Tortoise, а в студии делаю Exclude/Include From Project. С интеграцией было бы явно проще.
3. Удаление папок. С файлами такой проблемы не возникает — файлы можно пометить post factum. Но с директориями приходится немного повозится.
Несмотря на вышесказанное я очень рад переходу с VSS на SVN и всё это всего лишь мелкие неудобства. И интеграция действительно не так ВАЖНА.
Однако я никак не могу понять, почему многие говорят, что "интеграция нафиг не нужна" ? Наверное потому, что есть другой путь решения вышеперечисленных проблем ? Или им всё равно — в одно действие делается перемещение файла или в 5 ?
Здравствуйте, Sergey J. A., Вы писали:
SJA>Интересно... Я вот тоже недавно перешёл на SVN. Но не могу сказать что мне интеграция не нужна. А именно: SJA>1. При коммите изменений можно забыть что-то сохранить в студии и закоммитить ерунду. Було такое пару раз с файлом проекта — все файлы сохранил вроде, а файл проекта — нет. Сейчас стал более внимателен, но интеграция в этом бы очень помогла. SJA>2. переименование/перемещение файлов и папок. Как это сделать ? В данный момент я пользуюсь такой последовательностью: перемещаю файлы через Tortoise, а в студии делаю Exclude/Include From Project. С интеграцией было бы явно проще. SJA>3. Удаление папок. С файлами такой проблемы не возникает — файлы можно пометить post factum. Но с директориями приходится немного повозится.
Такая интеграция не помешала бы. Но у VSS было не это, а довольно дурацкая идея блокирующего чекаута при редактировании. Вот такая интеграция только помешала бы.
SJA>Несмотря на вышесказанное я очень рад переходу с VSS на SVN и всё это всего лишь мелкие неудобства. И интеграция действительно не так ВАЖНА.
+1
SJA>Однако я никак не могу понять, почему многие говорят, что "интеграция нафиг не нужна" ? Наверное потому, что есть другой путь решения вышеперечисленных проблем ? Или им всё равно — в одно действие делается перемещение файла или в 5 ?
Дык все примено то что ты и гворят. Поддержка конечно не помешает, но и без того намгого лучше чем было на VSS.
Тут можно говорить о некой достаточности. Тартилы дастаточно для довльно комфортной работы.
ЗЫ
Закомитить незаписанные файлы лично у меня не удается просто по тому, что я взял за правило не комитить файлы нескомпилированного и не протестированного проекта. Все случае когда я это правило нарушал выходили боком.
Переименование действительно геморойно, но оно к счастью нужно довольно редко.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Spaider wrote: > Здравствуйте, Чистяков Влад (VladD2), Вы писали: > > Многие конкурирующие среды (например, Borland Delphi) вообще не имели > никаких средств компиляции вне IDE (вернее, такими средствами была сама > IDE). > > Оставим за рамками качество и удобство компиляторов командной строки в > Delphi, но отметим тот факт, что они таки есть: dcc32 и *make*. Сейчас > не имею доступа к более ранним версиям, но в Delphi 7 вышеуказанные > утилиты уже есть.
Помню — Дельфи 5, есть они. Уверен — были и раньше. Подозреваю — их и
вызывает IDE.
Здравствуйте, Чистяков Влад (VladD2), Вы писали:
ЧВV>Статья рассказывает про новую систему сборки проектов от Microsoft – MSBuild. MSBuild будет входить в .NET Framework 2.0, а стало быть он станет основным средством сборки приложений для WinFX и новой версии Windows Longhorn. В статье рассказывается о принципах его работы, его API и средствах расширения.
Интересно было бы узнать, есть ли у него какие-то преимущества по сравнению с другими решениями.
Здравствуйте, DemAS, Вы писали:
DAS> скорее это очередное "фи" в сторону MS.
А в чем заключается "фи"?
В том, что MS в коммерческой разработке не опирается на опен-сорсовый проект, а пытается сделать что-то свое? При этом я вполне уверен что у них получится лучше чем у ANT'а
С уважением, Евгений
JetBrains, Inc. "Develop with pleasure!"
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, xvost, Вы писали:
X>>В той нише, которую занимает СорсСэйф — он вне конкуренции. WH>Это какя ниша?
Бесплатных (вы же купили студию, да? ) source-control'ов, отлично интегрированных в среду разработки, и предоставляющих полный набор сервисов для одного/двух/трех разработчиков и проектов малого размера.
WH>Не помню как CVS (я с ним давно не работал) но по сравнению с SVN VSS нервно курит на проектах любого размера.
Да, может ты и интеграцию SVN с VisualStudio знаешь, сравнимую по удобству с VSS?
С уважением, Евгений
JetBrains, Inc. "Develop with pleasure!"
Здравствуйте, DemAS, Вы писали:
VD>>Как минимум отличная интеграция с VS 2005
DAS> И как следствие, сложность или даже невозможность привязать ее к другим средам разработки.
Это почему это?
VD>> и породистый родитель.
DAS> OpenSource звучит не только красиво, но еще и гордо
Пусть оно звучит как угодно, но многие скорее будут доверять коммерческому коду.
DAS> Как и в Ant.
Где-то как. Где-то лучше. Где-то просто по другому. Как минимум отсутствие NAnt-а во фрэймворке и слабые возможности интеграции в IDE — это уже нехилые минусы.
DAS> Может быть. Но зная Ant, детально разбираться с еще одной аналогичной приблудой уже не очень хочется.
Это не проблема так как:
1. Не многие его знают.
2. Ant — это Ява, а тащить ее для дотнетного проекта не смешно (хотя конечно есть NAnt).
3. Знать его не особо то нужно так как в большинстве случаев VS сделает всю нужную работу.
DAS> p.s. Не воспринимай, как упрек. Статья хорошая, скорее это очередное "фи" в сторону MS.
Люди можно сказать на истинный путь встают. Перенимают грамотные решения и содают хорошо документированный фрэймворк, а ты на них ФИ. Все равно они не смогут использовать NAnt/Ant хотя бы потому что они ГНУ-тые. А стандартизованный АПИ, декларативный синтасксис, расширяемость и т.п. очень полезны. Я, например, привык работать с IDE и меня всегда напрягал их закрытые и довольно убогие форматы проектов. А тут такой кайф!
Я вот для R#-а был вынужден написать загрузку файлов C#-проектов. Для 2003 студии сильно схалтурил, так как парсить их формат честно да еще и без документации желания особого небыло. А для 2005-ой студии я сделал честный парсинг так как использовал их АПИ. Получились коротко и качественно.
... << RSDN@Home 1.2.0 alpha rev. 554>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, xvost, Вы писали:
X>В том, что MS в коммерческой разработке не опирается на опен-сорсовый проект, а пытается сделать что-то свое? При этом я вполне уверен что у них получится лучше чем у ANT'а
Может и не лучше. Но по крайней мере не хуже. А так как это теперь открфтый стандарт для их файлов проектов, то я бы сказал, что это просто здорово.
... << RSDN@Home 1.2.0 alpha rev. 554>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, DemAS, Вы писали:
DAS>Здравствуйте, xvost, Вы писали:
X>>А в чем заключается "фи"?
DAS> В том, что MS который раз берется создавать аналог того, что и без того неплохо работает и, как говорится, единственный недостаток существующего в том, что это сделано не нами.
Далеко не единственный. NAnt и Ant — это GPL. А значит для коммерческих разработчиков они закрыты. Другое дело, что можно было не выпендриваться и 1 в 1 содрать форматы. Но тут у МС били свои заморочки. Им же нужно собственные IDE на это дело перевести.
DAS> Можно посмотреть на это и с практической точки зрения. Я человек ленивый и изучать две вещи выполняющие одну и туже задачу с одним и тем же результатом мне лень. Ты можешь сказать, что меня никто это делать и не заставляет, но на практике я уверен, что на проетах мне придется столкнуться и с тем и с другим и все-таки пойти против своих принципов
Уже есть XSLT из MSBuld в NAnt. Думаю обратное тоже будет. Так что если влом, то можно ничего и не учить.
DAS> В том, что она пытается занять нишу, которая в принципе уже заполнена. DAS>Я не против конкуренции, но смотри выше...
А что ты не наезжашь на NAnt? Он ведь тоже эту нишу занимает. А есть еще и другие утилиты.
DAS> Опять же, как на этих форумах не раз говорилось — "прежде чем писать программу, подумай, а чем она будет отличаться от конкуртентов в лучшую сторону". Здесь я пока явных преимуществ не увидел.
Думаю, в МС очень даже подумали.
DAS> А я вот не уверен. Я бы сказал 50 на 50. Это больше зависит от приоритетов в штабе MS. Согласись, что не все продукты от MS выгодно отличаются от конкурентов, в том числе и open source. Возьми, например, source safe — как я подозреваю, приоритет у этого направления в ms минимален и, как вывод, мы имеем худшую из систем контроля версий.
Они кстати уже сделали новую систему управления версиями базирующуюся на MS SQL. Я правда ее еще не копал. В данном случае SVN вроде как хватает.
В данном же случае качество явно значительно выше чем у SS.
DAS> Опять же, не мне советовать, но если бы MS не распыляла бы свои силы, а сосредоточилась на нескольких направлениях, глядишь и MS SQL 2005 уже вышел бы, да и Longhorn не так долго ждать пришлось.
Их делают разные команды. От того что МС не написала бы MSBuild никто бы не выиграл. Мы бы и дальше комплировали бы проекты из IDE или были бы вынуждены конвертировать проекты в другие форматы. А теперь это не проблема.
... << RSDN@Home 1.2.0 alpha rev. 554>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, xvost, Вы писали:
X>Она не худшая. В той нише, которую занимает СорсСэйф — он вне конкуренции. По удобству использования в маленьких проектах тот же CVS нервно курит в стороне. А у больших команд/проектов и бюджет другой, они используют более продвинутые и дорогие инструменты.
Да даже CVS не курит. Через Интернет SS вообще капец. А при наличии CVS и темболее SVN платить за какие-то дурные утилиты третьих фирм — просто маразм.
Но есть и другие примеры. Например, редктор из VS. От сдель нервно отдыхают все что я видел. По количеству и качеству исполнения фич он явный лидер. Ну, да вы это должны были заметить. Все же как ни как конкуретны и настройщики баявнов.
... << RSDN@Home 1.2.0 alpha rev. 554>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD>Далеко не единственный. NAnt и Ant — это GPL. А значит для коммерческих разработчиков они закрыты.
Не поняд. То есть, GPL запрещает не только использование кода в коммерческом проекте, но и даже использование инттрументов под этой лицензией ?
VD>А что ты не наезжашь на NAnt? Он ведь тоже эту нишу занимает. А есть еще и другие утилиты.
Про другие не знаю, а Ant вроде как стал стандартом
VD>Они кстати уже сделали новую систему управления версиями базирующуюся на MS SQL. Я правда ее еще не копал.
А я даже не видел Он, как я понимаю, тоже beta ? Тебе не кажется, что у MS накопилось очень много проектов в этой стадии, а вот релизов мы давно не видели
Здравствуйте, DemAS, Вы писали:
VD>>Далеко не единственный. NAnt и Ant — это GPL. А значит для коммерческих разработчиков они закрыты.
DAS> Не поняд. То есть, GPL запрещает не только использование кода в коммерческом проекте, но и даже использование инттрументов под этой лицензией ?
Нет, инструменты можно использовать как угодно. Вероятно, Влад имел в виду, что если какой-то компании потребуется build tool подкрутить под свои нужды, то с GPL-мы инструментом эта доработка должна быть открыта. Что для коммерческой компании может быть не приемлимо.
VD>>А что ты не наезжашь на NAnt? Он ведь тоже эту нишу занимает. А есть еще и другие утилиты.
DAS> Про другие не знаю, а Ant вроде как стал стандартом
Чего? Где?
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, VladD2, Вы писали:
DAS>> Может быть. Но зная Ant, детально разбираться с еще одной аналогичной приблудой уже не очень хочется.
VD>Это не проблема так как: VD>1. Не многие его знают. VD>2. Ant — это Ява, а тащить ее для дотнетного проекта не смешно (хотя конечно есть NAnt).
О как! И ты, Влад, до этого аргумента дошел
Помнится, когда-то я пытался тоже сказать про маразматичность использования Java-вского Ant-а для компиляции C++ных проектов. Тогда этот аргумент не прокатывал
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, raskin, Вы писали:
>> DAS> Не поняд. То есть, GPL запрещает не только использование кода в >> коммерческом проекте, но и даже использование инттрументов под этой >> лицензией ? >> >> Нет, инструменты можно использовать как угодно. Вероятно, Влад имел в >> виду, что если какой-то компании потребуется build tool подкрутить под >> свои нужды, то с GPL-мы инструментом эта доработка должна быть открыта. >> Что для коммерческой компании может быть не приемлимо. R>Подкрутить build tool под свои нужды и распространять, Вы имели в виду.
Да. Именно это.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Чистяков Влад (VladD2), Вы писали:
ЧВV>Статья рассказывает про новую систему сборки проектов от Microsoft – MSBuild.
Такой вопрос: а MSBuild поддерживает определение необходимости перекомпиляции проекта не по времени изменения файлов, а по контрольным суммам?
Ну а что не понравилось в MSBuild, так это то, что в проектных файлах, фактически, два синтаксиса. Один XML-ный, второй для выражения логики. Например:
Как раз подобные заморочки и довели до ручки, в общем-то, простой синтаксис make-файлов.
Ну и еще в качестве комментария. В начале статьи как-то складывается ощущение, что был один примитивный make который долгое время никак не могли улучшить. На самом деле вокруг make также много чего развивалось. На эту тему буквально на днях на freshmeat две статьи было опубликовано: What is Wrong with Make? и Make alternatives. В последней статье MSBuild в качестве альтернативы make пока упомянут не был (наверное, unix-оид писал ).
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
E>Ну а что не понравилось в MSBuild, так это то, что в проектных файлах, фактически, два синтаксиса. Один XML-ный, второй для выражения логики. E>Как раз подобные заморочки и довели до ручки, в общем-то, простой синтаксис make-файлов.
XSLT видел? Вот где наступит ручка, когда такие расширения дойдут до MSBuild.
E>Make alternatives. E>В последней статье MSBuild в качестве альтернативы make пока упомянут не был
Здравствуйте, fuurin, Вы писали:
E>>Make alternatives. E>>В последней статье MSBuild в качестве альтернативы make пока упомянут не был
F>Был. Как клон Ant.
Точно, пропустил -- читал абзац про Ant по диагонали. Приношу свои извинения.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
R>>Помню — Дельфи 5, есть они. Уверен — были и раньше. Подозреваю — их и R>>вызывает IDE.
VD>Я распрощался с дельфи когда вышла 4-ка.
В 5-6-7 есть bcc32.exe — что и есть компилятор командной строки в Delphi. Он на пару с IDE использует общую библиотеку (bcc*.dll) для компиляции. bcc32 помимо параметров командной строки подхватывает настройки проекта, как они были сохранены из IDE — это, ну, как натравить msbuild на *.csproj
В Delphi 2005, помимо dcc32, добавился ещё dccil.
[]
VD>Я вот для R#-а был вынужден написать загрузку файлов C#-проектов. Для 2003 студии сильно схалтурил, так как парсить их формат честно да еще и без документации желания особого небыло.
Здравствуйте, DemAS, Вы писали:
DAS> Не поняд. То есть, GPL запрещает не только использование кода в коммерческом проекте, но и даже использование инттрументов под этой лицензией ?
Использовать не запрещает. И даже продавать можно. Но включить GPL код в комерческий продукт нельзя. МС использует MSBuild в VS для чтения проектов. Да и в других местах. Под GPL это было бы невозможно.
VD>>А что ты не наезжашь на NAnt? Он ведь тоже эту нишу занимает. А есть еще и другие утилиты.
DAS> Про другие не знаю, а Ant вроде как стал стандартом
Я вообще-то конкретный вопрос задал.
DAS> А я даже не видел Он, как я понимаю, тоже beta ?
Да. И входит только в врехнии варианты студии.
DAS> Тебе не кажется, что у MS накопилось очень много проектов в этой стадии, а вот релизов мы давно не видели
Не кажется. У них все идет по плану.
... << RSDN@Home 1.2.0 alpha rev. 557>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, eao197, Вы писали:
E>О как! И ты, Влад, до этого аргумента дошел E>Помнится, когда-то я пытался тоже сказать про маразматичность использования Java-вского Ant-а для компиляции C++ных проектов. Тогда этот аргумент не прокатывал
Как раз в связке с С++ я нахожу Яву вполне приемлемой. Смешно тащить ее в проекты созданные на дотнете, так как она ничего для них не дает. Еще раз повторюсь — есть НАнт. Это тот же Ант, но для дотнета. Так что смысл в Анте для компиляции дотнетовских проектов стимится к отрицательным величинам.
... << RSDN@Home 1.2.0 alpha rev. 557>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, eao197, Вы писали:
E>Такой вопрос: а MSBuild поддерживает определение необходимости перекомпиляции проекта не по времени изменения файлов, а по контрольным суммам?
По-моему, все же по датам.
E>Ну а что не понравилось в MSBuild, так это то, что в проектных файлах, фактически, два синтаксиса. Один XML-ный, второй для выражения логики. ... E>Как раз подобные заморочки и довели до ручки, в общем-то, простой синтаксис make-файлов.
Синтаксис make скорее девели до ручки те кто решил определять структуру файла пробелами. Ну, и отсуствие возможности расширения кроме как утилитами ОС.
В МС, кстати, в отличии от Анта попытались минимизировать императивную часть доведя все управление проектом до декларативного. Лично я не вижу каких-то проблем в наличии некоторого синтаксиса внутри атрибутов и т.п. В конце концов есть АПИ который позволяет не обращать на это никакого внимания.
E>Ну и еще в качестве комментария. В начале статьи как-то складывается ощущение, что был один примитивный make который долгое время никак не могли улучшить. На самом деле вокруг make также много чего развивалось. На эту тему буквально на днях на freshmeat две статьи было опубликовано: What is Wrong with Make? и Make alternatives. В последней статье MSBuild в качестве альтернативы make пока упомянут не был (наверное, unix-оид писал ).
... << RSDN@Home 1.2.0 alpha rev. 557>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, kig, Вы писали:
kig>Ну посмотрел бы в NAnt'е.
Да просто влом. Я сделал примитивный парсинг. Заняло это дело строк десять. Для моих задач хватет. А в будущем один фиг все будет на MSBuild. К тому же есть конвертер. Тогда уж проще конвертировать на лету проект и пользоваться единым АПИ.
... << RSDN@Home 1.2.0 alpha rev. 557>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD>>> А что ты не наезжашь на NAnt? Он ведь тоже эту нишу занимает. А есть еще и другие утилиты. DAS>> Про другие не знаю, а Ant вроде как стал стандартом VD> Я вообще-то конкретный вопрос задал.
Так я собственно и ответил. Не наезжаю потому, что он занял эту нишу первым. Серьезных претензий к нему я не слышал. Серьезных преимуществ MSBuild(интеграция не в счет, я все равно студию не использую) я пока не увидел.
Был бы MS Build первым, наезжал бы на NAnt. Хотя, думаю, в этом случае он просто бы не появился.
DAS>> А я даже не видел Он, как я понимаю, тоже beta ? VD>Да. И входит только в врехнии варианты студии.
Beta2 студии
DAS>> Тебе не кажется, что у MS накопилось очень много проектов в этой стадии, а вот релизов мы давно не видели VD>Не кажется. У них все идет по плану.
Да? А разве сроки выхода MS SQL, Longhorn, VS и прочих мелких частей ни разу не сдвигались?
Про направление MBS (Microsoft Business Solutions), которым я сравнительно недавно занимался я вообще молчу — там в этом плане вообще бардак творится. Высказывания разработчиков в блоге сводятся буквально к следующему "бизнес фреймворк напрямую зависит от WinFX, <>, <> и т.д., а так как срок их выхода сдвинулся, то когда выйдет бизнес фреймоврк вообще фиг его знает".
Здравствуйте, VladD2, Вы писали:
E>>Ну а что не понравилось в MSBuild, так это то, что в проектных файлах, фактически, два синтаксиса. Один XML-ный, второй для выражения логики. ... E>>Как раз подобные заморочки и довели до ручки, в общем-то, простой синтаксис make-файлов.
VD>Синтаксис make скорее девели до ручки те кто решил определять структуру файла пробелами. Ну, и отсуствие возможности расширения кроме как утилитами ОС.
VD>В МС, кстати, в отличии от Анта попытались минимизировать императивную часть доведя все управление проектом до декларативного. Лично я не вижу каких-то проблем в наличии некоторого синтаксиса внутри атрибутов и т.п. В конце концов есть АПИ который позволяет не обращать на это никакого внимания.
Имхо, ты ошибаешься. Табуляция вместо пробелов -- это все цветочки по сравнению вот этим:
Здравствуйте, DemAS, Вы писали:
DAS>Серьезных преимуществ MSBuild(интеграция не в счет, я все равно студию не использую) я пока не увидел.
Дело в том, что ты не один живешь на этом свете. И что самое интересное МС работает не ради тебя. Тебе может и не нужна, а мне вот нужна. И другим тоже нужна. И даже это приемущество является очень важным.
DAS> Был бы MS Build первым, наезжал бы на NAnt. Хотя, думаю, в этом случае он просто бы не появился.
Первым был Ант. И я не вижу причен для монополизма. Если еще IBM сделает свою реализацию и она окажется востребованной, то я им только спасибо скжу.
DAS> Да? А разве сроки выхода MS SQL, Longhorn, VS и прочих мелких частей ни разу не сдвигались?
Сдвигались. Но план остался.
DAS> Про направление MBS (Microsoft Business Solutions), которым я сравнительно недавно занимался я вообще молчу — там в этом плане вообще бардак творится. Высказывания разработчиков в блоге сводятся буквально к следующему "бизнес фреймворк напрямую зависит от WinFX, <>, <> и т.д., а так как срок их выхода сдвинулся, то когда выйдет бизнес фреймоврк вообще фиг его знает".
Про MBS ничего сказать не могу, так как не разбирался. MSBuild же есть и стабильно работает.
... << RSDN@Home 1.2.0 alpha rev. 557>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, eao197, Вы писали:
E>Вот уж где апофеоз разных комбинаций $(), %() и т.п.
Понимаеш ли... Есть проблемы разного рода. Полохая читабельность — это конечно проблема, но она от части решается более качественным кодированием. А вот зависимость от утилит ОС и невозможность обнаружения ошибок в следствии того, что разницу между табуляцией и пробелом отследить не просто — это уже проблемы превращающиеся в дичайший геморой при некоторых условиях.
К тому еж у MSBuild была еще одина цель. Это же ведь за одно и формат для IDE. Мэйк для этого подходит совсем плохо.
E>А структура, определяемая пробелами, как доказывает Python -- вполно жизнеспособна. Да и на писанный на Python-е scons так же себя не плохо чувствует.
Я с Питоном ного не возился, так что врать не буду. Но в мэйках — это был сущий ад. Смотришь на текст... вроде все ОК. Запускашь... о оно делает совсем не то что задумано. И никаких средств отладки. А мэйк писан не тобой и имеет размер в пол мега.
... << RSDN@Home 1.2.0 alpha rev. 557>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2 wrote: > Здравствуйте, raskin, Вы писали: > > R>GPL позволяет подкрутить для себя и никому не отдавать. > > Любой измененный код *обязан* выпускаться под GPL и обязан быть доступен > в исходных кодах. Более того. Даже использование этого кода в виде > библиотеки обязывает выпускать такой продукт тоже под GPL. Есть правда > еще LGPL который позволяет поставлять вместе с проприетарными продуктами > LGPL-DLL-и и т.п. Но и там проблем хватает.
Извините, я неточно выразился. Я имел в виду изменение build-tool для
себя (для внутреннего использования). Использование GPL build-tool не
накладывает на исполняемые файлы проекта ограничений. Если Вы её
модифицируете, Вы (пока программы выпускаются под GPLv2) не обязаны её
кому-то предоставлять, но если Вы её распространяете, то должны:...
2. You may modify your copy or copies of the Program or any portion
of it, thus forming a work based on the Program, and copy and
distribute such modifications or work under the terms of Section 1
above, provided that you also meet all of these conditions:
a) You must cause the modified files to carry prominent notices
stating that you changed the files and the date of any change.
— кому мешает лишняя строчка
b) You must cause any work that you distribute or publish, that in
whole or in part contains or is derived from the Program or any
part thereof, to be licensed as a whole at no charge to all third
parties under the terms of this License.
— только если начато распространение.
c) If the modified program normally reads commands interactively
when run, you must cause it, when started running for such
interactive use in the most ordinary way, to print or display an
announcement including an appropriate copyright notice and a
notice that there is no warranty (or else, saying that you provide
a warranty) and that users may redistribute the program under
these conditions, and telling the user how to view a copy of this
License. (Exception: if the Program itself is interactive but
does not normally print such an announcement, your work based on
the Program is not required to print an announcement.)
— это означает, что нельзя менять строчку приветствия, по существу. > > Короче конторе класса МС проще написать свой велосипед. Темболее что он > хорошо совместим с Антом и НАнтом.
Это верю. Они боятся, что кто-нибудь прочитает хоть строчку GPL-кода и
это будет иметь последствия, и т.д.
Итак, задачи – это действия, но выполнять их напрямую нельзя. Выполняются в MSBuild цели (Tasks). Именно цели и содержат вызовы задач. Цель описывается тегом Target:
Одинаковые ошибки необязательно делать каждый раз, достаточно сделать одну, а затем обращаться к ней по мере необходимости из любого места программы.
C:\PROJECTS\SAMPLES\RSDN\MSBuilgApiTest\MSBuilgApiTest\MsBuildProjectHelper.cs(132,22): error CS0246: The type or namespace name 'Item' could not be found (are you missing a using directive or an assembly reference?)
ЧВV>Авторы: ЧВV> Чистяков Влад (VladD2)
ЧВV>Аннотация: ЧВV>Статья рассказывает про новую систему сборки проектов от Microsoft – MSBuild. MSBuild будет входить в .NET Framework 2.0, а стало быть он станет основным средством сборки приложений для WinFX и новой версии Windows Longhorn. В статье рассказывается о принципах его работы, его API и средствах расширения.
на codeplex есть расширение для msbuild — msBee, позволяющее использовать vs2005 для сборки проектов под fw1.1
MSBuild Extras – Toolkit for .NET 1.1 “MSBee” is an addition to MSBuild that allows developers to build managed applications using Visual Studio 2005 projects that target .NET 1.1.
Check out all of the MSBee Features for the 1.0 release.
Здравствуйте, Sergey J. A., Вы писали:
SJA>1. Було такое пару раз с файлом проекта — все файлы сохранил вроде, а файл проекта — нет.
Ctrl+Shift+A на автомате — и все.
SJA>2. перемещаю файлы через Tortoise, а в студии делаю Exclude/Include From Project. С интеграцией было бы явно проще.
Аналогично. Здесь, пожалуй, было бы проще. Но и так привыкаешь
SJA>Однако я никак не могу понять, почему многие говорят, что "интеграция нафиг не нужна" ? Наверное потому, что есть другой путь решения вышеперечисленных проблем ? Или им всё равно — в одно действие делается перемещение файла или в 5 ?
Win+E и Тортилка творят чудеса. cmd.exe и svn.exe, конечно, тоже. Но, по большому счету, интеграция VS с VSS заключается в том, что на каждый чих появляется окошко для Check Out'а. А в остальном — толку от такой интеграции (вспомните хотя бы UI) —
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
HgLab: Mercurial Server and Repository Management for Windows
Здравствуйте, Нахлобуч, Вы писали:
SJA>>1. Було такое пару раз с файлом проекта — все файлы сохранил вроде, а файл проекта — нет. Н>Ctrl+Shift+A на автомате — и все.
Тут ещё дело в том, что именно я продвигал идею SVN-а в массы нашей фирмы. Т.е. шишки типа "вот у меня проект не закомитился" падают на меня. И даже если я буду сохранять все файлы во 100% вероятностью, наличие такой интеграции всё-же желательно — оно мне помогает косвенно.
SJA>>2. перемещаю файлы через Tortoise, а в студии делаю Exclude/Include From Project. С интеграцией было бы явно проще. Н>Аналогично. Здесь, пожалуй, было бы проще. Но и так привыкаешь
Аналогично предыдущему. Все уже вроде привыкли, но иногда я ещё бегаю и разруливаю ситуации с "я тут целый день тайпил, потом основательно поработал со структурой файлов(прямо из студии разумеется). Теперь ничего не комитится."
Здравствуйте, Sergey J. A., Вы писали:
SJA>Интересно... Я вот тоже недавно перешёл на SVN. Но не могу сказать что мне интеграция не нужна. А именно: SJA>1. При коммите изменений можно забыть что-то сохранить в студии и закоммитить ерунду. Було такое пару раз с файлом проекта — все файлы сохранил вроде, а файл проекта — нет. Сейчас стал более внимателен, но интеграция в этом бы очень помогла.
Cntrl-Shift-S
SJA>2. переименование/перемещение файлов и папок. Как это сделать ? В данный момент я пользуюсь такой последовательностью: перемещаю файлы через Tortoise, а в студии делаю Exclude/Include From Project. С интеграцией было бы явно проще.
Переименую, перемещаю через студию, затем использую самопальную утилтку для прописываниб "move" для SVN SJA>3. Удаление папок. С файлами такой проблемы не возникает — файлы можно пометить post factum. Но с директориями приходится немного повозится.
Эт-да SJA>Однако я никак не могу понять, почему многие говорят, что "интеграция нафиг не нужна" ? Наверное потому, что есть другой путь решения вышеперечисленных проблем ? Или им всё равно — в одно действие делается перемещение файла или в 5 ?
основной гимор при рефакторинге, использую свою утилиту, помогает
Здравствуйте, Sergey J. A., Вы писали:
SJA>Тут ещё дело в том, что именно я продвигал идею SVN-а в массы нашей фирмы.
Вы при переходе с VSS как репозиторий конвертировали?
SJA>Т.е. шишки типа "вот у меня проект не закомитился" падают на меня. И даже если я буду сохранять все файлы во 100% вероятностью, наличие такой интеграции всё-же желательно — оно мне помогает косвенно.
Это в каком же виде? Вы, получается, виноваты, что они инструментом пользуются через пень-колоду?
SJA>Все уже вроде привыкли, но иногда я ещё бегаю и разруливаю ситуации с "я тут целый день тайпил, потом основательно поработал со структурой файлов(прямо из студии разумеется). Теперь ничего не комитится."
Это пройдет. VSS хоть и развращает, но к хорошему привыкаешь быстро. Было бы желание.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
HgLab: Mercurial Server and Repository Management for Windows
Здравствуйте, PeterZT, Вы писали:
SJA>>Однако я никак не могу понять, почему многие говорят, что "интеграция нафиг не нужна" ? Наверное потому, что есть другой путь решения вышеперечисленных проблем ? Или им всё равно — в одно действие делается перемещение файла или в 5 ? PZT>основной гимор при рефакторинге, использую свою утилиту, помогает
Что за она ? У меня тож было пару идей. Даже AddIn писал. Почти рабочий. Но закопался с всякой фигнёй, а тут VisualSVN появился...
Здравствуйте, Нахлобуч, Вы писали:
SJA>>Тут ещё дело в том, что именно я продвигал идею SVN-а в массы нашей фирмы. Н>Вы при переходе с VSS как репозиторий конвертировали?
Никак. Просто импортнули текущую версию. Это всех устроило, т.к. раньше работали с VSS через VSS Internet(или как там его). А он по умолчанию не предоставляет ни хистори ни чего такого. Так что до SVN-а мы VSS использовали только как своего рода backup.
SJA>>Т.е. шишки типа "вот у меня проект не закомитился" падают на меня. И даже если я буду сохранять все файлы во 100% вероятностью, наличие такой интеграции всё-же желательно — оно мне помогает косвенно. Н>Это в каком же виде? Вы, получается, виноваты, что они инструментом пользуются через пень-колоду?
Ну, как известно инициатива наказуема Просто я всех уверил, что всё будет чики-пуки, хотя знал что с интеграцией будут кое-какие проблемы в начале. Вобщем немного обнанул в целях всефирменного блага
SJA>>Все уже вроде привыкли, но иногда я ещё бегаю и разруливаю ситуации с "я тут целый день тайпил, потом основательно поработал со структурой файлов(прямо из студии разумеется). Теперь ничего не комитится."
Н>Это пройдет. VSS хоть и развращает, но к хорошему привыкаешь быстро. Было бы желание.
Тем больнее возвращатся на VSS... В конторе я первый перешёл на SVN и даже начал в нём свой проект. Но иногда надо было подправить то-сё из проектов в VSS. Словами не передать, как меня бесило, что VSS что-то делает через интернет по 2-3 минуты. Причём прогреса не видно, сидиш с диким желанием разбить монитор... После таких багофиксов, SVN — просто бальзам на душу.
Здравствуйте, Sergey J. A., Вы писали:
SJA>Что за она ? У меня тож было пару идей. Даже AddIn писал. Почти рабочий. Но закопался с всякой фигнёй, а тут VisualSVN появился...
При перемещении файла средствами ос, свн отобразит два файла — один missing, а другой not-under-source-control, утилитка высвечивает их в двух списках, делаем сопоставление, затем она копирует файл обратно (или перименовывает), затем делает move через SVN. Есть ряд органичений, но в целом устраивает.
Здравствуйте, Odi$$ey, Вы писали:
OE>MSBuilgApiTest не компилится
OE>
OE>C:\PROJECTS\SAMPLES\RSDN\MSBuilgApiTest\MSBuilgApiTest\MsBuildProjectHelper.cs(132,22): error CS0246: The type or namespace name 'Item' could not be found (are you missing a using directive or an assembly reference?)
API изменился по сравлению с бэтой. Там немного другие называния появились. В принципе, с помощью комлит-ворда и какой-то матери за 5 минут проект приводится в чувства.
Потом могу попровить и тот что на сайте.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Didro, Вы писали:
D>Имелось ввиду, что теги элементов нужно помещать в тег «ItemGroup», а не «PropertyGroup»? Как в самом примере — HelloWorld.
Да, это копи-пэст-опечатка.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Захотелось расширить стандартную логику компиляции проекта.
Я хочу, чтобы некоторый мой target выполнялся только если изменилась сборка, скомпиленная по обычному порядку.
Отлично, записываем сборку в Inputs.
MSBuild требует — если заполнил Inputs, заполняй и Outputs!
А я не могу! Потому что перечень файлов Outputs, вообще говоря, зависит от содержимого файлов в Inputs.
Как к таким задачкам подходить?
Compile – это имя типа элемента. Имя типа элемента может быть каким угодно. Чтобы MSBuild мог понять, что это именно элемент теги элементов нужно помещать в тег «PropertyGroup»:
Ну, максимум нужно комитилку на сервер сделать которая при закрытии проекта будет изменения на сервер сбрасывать.
Одинаковые ошибки необязательно делать каждый раз, достаточно сделать одну, а затем обращаться к ней по мере необходимости из любого места программы.
