Здравствуйте, eao197, Вы писали:

E>Вот уж где апофеоз разных комбинаций $(), %() и т.п.

Понимаеш ли... Есть проблемы разного рода. Полохая читабельность — это конечно проблема, но она от части решается более качественным кодированием. А вот зависимость от утилит ОС и невозможность обнаружения ошибок в следствии того, что разницу между табуляцией и пробелом отследить не просто — это уже проблемы превращающиеся в дичайший геморой при некоторых условиях.

К тому еж у MSBuild была еще одина цель. Это же ведь за одно и формат для IDE. Мэйк для этого подходит совсем плохо.

E>А структура, определяемая пробелами, как доказывает Python -- вполно жизнеспособна. Да и на писанный на Python-е scons так же себя не плохо чувствует.

Я с Питоном ного не возился, так что врать не буду. Но в мэйках — это был сущий ад. Смотришь на текст... вроде все ОК. Запускашь... о оно делает совсем не то что задумано. И никаких средств отладки. А мэйк писан не тобой и имеет размер в пол мега.

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-кода и
это будет иметь последствия, и т.д.

Здравствуйте, Чистяков Влад (VladD2), Вы писали:

ЧВV>Статья:
ЧВV>MSBuild

Автор(ы): Чистяков Влад (VladD2)
Дата: 09.07.2005
Статья рассказывает про новую систему сборки проектов от Microsoft – MSBuild. MSBuild будет входить в .NET Framework 2.0, а стало быть он станет основным средством сборки приложений для WinFX и новой версии Windows Longhorn. В статье рассказывается о принципах его работы, его API и средствах расширения.

маленькая ошибка

Итак, задачи – это действия, но выполнять их напрямую нельзя. Выполняются в MSBuild цели (Tasks). Именно цели и содержат вызовы задач. Цель описывается тегом Target:

Здравствуйте, Max404.NET, Вы писали:

ЧВV>>Статья:
ЧВV>>MSBuild

Автор(ы): Чистяков Влад (VladD2)
Дата: 09.07.2005
Статья рассказывает про новую систему сборки проектов от Microsoft – MSBuild. MSBuild будет входить в .NET Framework 2.0, а стало быть он станет основным средством сборки приложений для WinFX и новой версии Windows Longhorn. В статье рассказывается о принципах его работы, его API и средствах расширения.

MN>маленькая ошибка

Не понимаю ещё одного места в статье, а именно в разделе Элементы (Items)

Автор(ы): Чистяков Влад (VladD2)
Дата: 09.07.2005
Статья рассказывает про новую систему сборки проектов от Microsoft – MSBuild. MSBuild будет входить в .NET Framework 2.0, а стало быть он станет основным средством сборки приложений для WinFX и новой версии Windows Longhorn. В статье рассказывается о принципах его работы, его API и средствах расширения.

написано, что

Имя типа элемента может быть каким угодно. Чтобы MSBuild мог понять, что это именно элемент теги элементов нужно помещать в тег «PropertyGroup»:

<PropertyGroup>
  <Compile Include="HelloWorld.cs" />
</PropertyGroup>

Имелось ввиду, что теги элементов нужно помещать в тег «ItemGroup», а не «PropertyGroup»? Как в самом примере — HelloWorld.

Здравствуйте, Чистяков Влад (VladD2), Вы писали:

ЧВV>MSBuild

Автор(ы): Чистяков Влад (VladD2)
Дата: 09.07.2005
Статья рассказывает про новую систему сборки проектов от Microsoft – MSBuild. MSBuild будет входить в .NET Framework 2.0, а стало быть он станет основным средством сборки приложений для WinFX и новой версии Windows Longhorn. В статье рассказывается о принципах его работы, его API и средствах расширения.

MSBuilgApiTest не компилится

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?)

Здравствуйте, Чистяков Влад (VladD2), Вы писали:

ЧВV>Статья:
ЧВV>MSBuild

Автор(ы): Чистяков Влад (VladD2)
Дата: 09.07.2005
Статья рассказывает про новую систему сборки проектов от Microsoft – MSBuild. MSBuild будет входить в .NET Framework 2.0, а стало быть он станет основным средством сборки приложений для WinFX и новой версии Windows Longhorn. В статье рассказывается о принципах его работы, его API и средствах расширения.

ЧВV>Авторы:
ЧВV> Чистяков Влад (VladD2)

ЧВV>Аннотация:
ЧВV>Статья рассказывает про новую систему сборки проектов от Microsoft – MSBuild. MSBuild будет входить в .NET Framework 2.0, а стало быть он станет основным средством сборки приложений для WinFX и новой версии Windows Longhorn. В статье рассказывается о принципах его работы, его API и средствах расширения.

на codeplex есть расширение для msbuild — msBee, позволяющее использовать vs2005 для сборки проектов под fw1.1

http://codeplex.com/Wiki/View.aspx?ProjectName=MSBee

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.

Здравствуйте, 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>1. Було такое пару раз с файлом проекта — все файлы сохранил вроде, а файл проекта — нет.

Ctrl+Shift+A на автомате — и все.

SJA>2. перемещаю файлы через Tortoise, а в студии делаю Exclude/Include From Project. С интеграцией было бы явно проще.

Аналогично. Здесь, пожалуй, было бы проще. Но и так привыкаешь

SJA>Однако я никак не могу понять, почему многие говорят, что "интеграция нафиг не нужна" ? Наверное потому, что есть другой путь решения вышеперечисленных проблем ? Или им всё равно — в одно действие делается перемещение файла или в 5 ?

Win+E и Тортилка творят чудеса. cmd.exe и svn.exe, конечно, тоже. Но, по большому счету, интеграция VS с VSS заключается в том, что на каждый чих появляется окошко для Check Out'а. А в остальном — толку от такой интеграции (вспомните хотя бы UI) —

Здравствуйте, Нахлобуч, Вы писали:

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 хоть и развращает, но к хорошему привыкаешь быстро. Было бы желание.

Здравствуйте, 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 минут проект приводится в чувства.

Потом могу попровить и тот что на сайте.

Здравствуйте, Didro, Вы писали:

D>Имелось ввиду, что теги элементов нужно помещать в тег «ItemGroup», а не «PropertyGroup»? Как в самом примере — HelloWorld.

Да, это копи-пэст-опечатка.

Здравствуйте, 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.
Тут можно говорить о некой достаточности. Тартилы дастаточно для довльно комфортной работы.

ЗЫ

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

Переименование действительно геморойно, но оно к счастью нужно довольно редко.

Здравствуйте, PeterZT, Вы писали:

PZT>Переименую, перемещаю через студию, затем использую самопальную утилтку для прописываниб "move" для SVN

Поделился бы с народом.

Захотелось расширить стандартную логику компиляции проекта.
Я хочу, чтобы некоторый мой target выполнялся только если изменилась сборка, скомпиленная по обычному порядку.
Отлично, записываем сборку в Inputs.
MSBuild требует — если заполнил Inputs, заполняй и Outputs!
А я не могу! Потому что перечень файлов Outputs, вообще говоря, зависит от содержимого файлов в Inputs.
Как к таким задачкам подходить?

Хорошая статья

Можно подправить текст?

Compile – это имя типа элемента. Имя типа элемента может быть каким угодно. Чтобы MSBuild мог понять, что это именно элемент теги элементов нужно помещать в тег «PropertyGroup»:

<PropertyGroup>
  <Compile Include="HelloWorld.cs" />
</PropertyGroup>

по-моему должно быть

<ItemGroup>
  <Compile Include="HelloWorld.cs" />
</ItemGroup>