Предлагаю пренести Интеграции в проект компилятора.

То есть http://nemerle.org/svn/vs-plugin/trunk перенести в http://nemerle.org/svn/nemerle/trunk/VsIntegration. В итоге у нас будет единый корень, и следовательно, возможность беспрепятственно создавать относительные ссылки. Это сним проблему сборки единым нажатием Компилятора, Интеграции и инсталлятора к ним.

Есть возражения?

Если нет, то можно как-то при переносе оставить историю файлов?

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

VD>Предлагаю пренести Интеграции в проект компилятора.
Мысль здравая. Это сильно упростит сборку всего солюшина. Если что, я готов с msbuild-ом повоевать.
Еще хотелось бы избавиться от батников. Все можно сделать в виде msbuild task-ов.

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

VD>Если нет, то можно как-то при переносе оставить историю файлов?

Можно попробовать в RepoБраузере каталоги мышкой потаскать.

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

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

VD>>Если нет, то можно как-то при переносе оставить историю файлов?

IT>Можно попробовать в RepoБраузере каталоги мышкой потаскать.

Зачем нам маны, даешь импровизацию

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

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

VD>>Предлагаю пренести Интеграции в проект компилятора.
GR>Мысль здравая. Это сильно упростит сборку всего солюшина. Если что, я готов с msbuild-ом повоевать.
GR>Еще хотелось бы избавиться от батников. Все можно сделать в виде msbuild task-ов.

Я перенес

Автор: VladD2
Дата: 27.06.08

папку Интеграци, так что можно заняться причесыванием msbuild-ных фалов.

Было бы сдорово вообще избавиться от батников перенеся весь процесс сборки в msbuild.

Что желательно сделать:
1. Солюшен сборки компилятора. Он должен компилировать компилятор и производить его регистрацию. Нужно сделать так чтобы можно было компилировать и без регистрации. Кроме того регистрация должна производиться как в %ProgramFiles%\Nemerle, так и в boot. Кроме того должна поддерживаться двух студийная сборка проекта (сначала собирается компилятор в некой промежуточной директории, например, stage2, а потом компилятор собирается полученными на предыдущей стадии бинарниками). При неудаче сборки ничего не должно быть унитожено. Бут должен изменяться только при успешном завершении второй стадии компиляции. Желательно (но не обязательно) сделать и третью стадию компиляции которая бы собирала исходники бинарниками созданными на второй стадии. Эти бинарники нужно сравнить с бинарниками получеными на второй стадии. Если они не равны, то процесс сборки должен считаться неудачным. Это конечно немного параноя, но так было сделано в исходном процессе сборки компилятора (том который был на Гну-сных утилитах основан). Да, желательно, чтобы этот солюшен собирал и МСБилдный таск.
2. Еще один солющен должен собирать утилиты и прочую дрибедень.
3. Третий солюшен должен собирать интеграцию.
4. Ну, и должен быть еще один солюшен который собирает три предыдущих солюшена (точнее проекты из них) и собирает инсталлятор.
5. Кроме того хорошо бы сделать еще один солюшен который собирал бы компилятор и интеграцию и прогонял тесты. В случае успеха можно комитить изменения. Если автоматизировать еще и комит — это будет вообще супер.

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

Выходные не прошли бесследно Предлагаю посмотреть на мой патч и покритиковать.

Установка патча:
1. Скачать и распаковать Rev8060.rar
2. Скопировать папку Nemerle поверх корня компилятора.
3. Применить патч.

Некоторые варианты сборки:
1. msbuild NemerleAll.nproj — сборка компилятора, утилит, интеграции, shell-а, инсталлятора. Затем бинарники компилятора копируются в Program Files и регистрируются в реестре.
2. msbuild NemerleAll.nproj /t:Installer — то же, что и в п.1, но без копирования и регистрации в Program Files
3. msbuild NemerleAll.nproj /t:Stage2 — двухпроходная сборка сомпилятора
4. msbuild NemerleAll.nproj /t:VSIntegration — снячала двухпроходная сборка компилятора, потом — интеграция
5. msbuild NemerleAll.nproj /t:RegBoot — зарегистрировать *.targets в boot
Реально вариантов больше, кому интересно — см. NemerleAll.nproj

VD>Было бы сдорово вообще избавиться от батников перенеся весь процесс сборки в msbuild.
Готово, но требует критики.

VD>Что желательно сделать:
VD>1. Солюшен сборки компилятора. Он должен компилировать компилятор и производить его регистрацию. Нужно сделать так чтобы можно было компилировать и без регистрации. Кроме того регистрация должна производиться как в %ProgramFiles%\Nemerle, так и в boot.
Готово.
3. msbuild NemerleAll.nproj /t:Stage2

VD>Кроме того должна поддерживаться двух студийная сборка проекта (сначала собирается компилятор в некой промежуточной директории, например, stage2, а потом компилятор собирается полученными на предыдущей стадии бинарниками). При неудаче сборки ничего не должно быть унитожено. Бут должен изменяться только при успешном завершении второй стадии компиляции.
Готово, требует тестирования, т.к. реальную ситуацию с ошибкой я создать не смог, но если генерировать ошибку искуственно, то откат работает. В общем нужно тестировать.

VD>Желательно (но не обязательно) сделать и третью стадию компиляции которая бы собирала исходники бинарниками созданными на второй стадии. Эти бинарники нужно сравнить с бинарниками получеными на второй стадии. Если они не равны, то процесс сборки должен считаться неудачным. Это конечно немного параноя, но так было сделано в исходном процессе сборки компилятора (том который был на Гну-сных утилитах основан). Да, желательно, чтобы этот солюшен собирал и МСБилдный таск.
Этого пока не делал.

VD>2. Еще один солющен должен собирать утилиты и прочую дрибедень.
2. msbuild NemerleAll.nproj /t:Tools

VD>3. Третий солюшен должен собирать интеграцию.
4. msbuild NemerleAll.nproj /t:VSIntegration

VD>4. Ну, и должен быть еще один солюшен который собирает три предыдущих солюшена (точнее проекты из них) и собирает инсталлятор.
2. msbuild NemerleAll.nproj /t:Installer

VD>5. Кроме того хорошо бы сделать еще один солюшен который собирал бы компилятор и интеграцию и прогонял тесты. В случае успеха можно комитить изменения. Если автоматизировать еще и комит — это будет вообще супер.
Это чуть позже — времени не хватило.

Здравствуйте, gloomy rocker!

GR>Выходные не прошли бесследно Предлагаю посмотреть на мой патч и покритиковать.
Может ты просто зайдёшь на
http://groups.google.com/group/nemerle-dev?hl=en
и попросишь доступ к репозиторию?

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

БП>Может ты просто зайдёшь на
БП>http://groups.google.com/group/nemerle-dev?hl=en
БП>и попросишь доступ к репозиторию?

Да, пожалуй стоит так сделать. Только это несколько затянет процесс причесывания msbuild-ных скриптов.

Заодно хотел бы услышать мнение. Сейчас я подправил проекты интеграции и шелла так, чтобы они ссылались на сборки из boot, а не на Program Files\Nemerle. ИМХО это правильней. Если я не прав — покритикуйте.

Еще я реализовал возможность зарегистрировать путь к Nemerle.MSBuild.targets в boot, но толку от этого мало, т.к. во всех шаблонах проектов есть такой код:

    <PropertyGroup>
        <NoStdLib>true</NoStdLib>
        <Nemerle Condition=" '$(Nemerle)' == '' ">$(ProgramFiles)\Nemerle</Nemerle>
    </PropertyGroup>

Единственный способ, который я нашел, заставить студию смотреть на boot — определить переменную окружения Nemerle=<путь к boot>. Если такой вариант устроит, то нужно будет в таск RegBoot добавить инструкцию, которая создает эту переменную в системе.

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

GR>Единственный способ, который я нашел, заставить студию смотреть на boot — определить переменную окружения Nemerle=<путь к boot>.

Может какую другую переменную объявить? Типа NemerleBoot. Хорошо бы вообще разделить установленный на машине Nemerle стандартным образом с тем, с чем работают девелоперв. Тогда можно будет писать интеграцию на самой интеграции.

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

GR>Сейчас я подправил проекты интеграции и шелла так, чтобы они ссылались на сборки из boot, а не на Program Files\Nemerle. ИМХО это правильней. Если я не прав — покритикуйте.

Это не верное решение. В boot почти всегда находятся устаревшие версии компилятора. Он нужен исключительно для бутсрипинга. Изменяться boot должен только после успешного прохождения второй стадии компиляции (а по уму и тестов). Файлы в нем должны комититься как можно реже, так как это довольно большие бинарные файлы, к тому же ктитичные.

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

GR>Еще я реализовал возможность зарегистрировать путь к Nemerle.MSBuild.targets в boot, но толку от этого мало, т.к. во всех шаблонах проектов есть такой код:

GR>

GR>    <PropertyGroup>
GR>        <NoStdLib>true</NoStdLib>
GR>        <Nemerle Condition=" '$(Nemerle)' == '' ">$(ProgramFiles)\Nemerle</Nemerle>
GR>    </PropertyGroup>
GR>

GR>Единственный способ, который я нашел, заставить студию смотреть на boot — определить переменную окружения Nemerle=<путь к boot>. Если такой вариант устроит, то нужно будет в таск RegBoot добавить инструкцию, которая создает эту переменную в системе.

Не надо работать из бута. Можно сделать тупое копирование файлов из бута в %ProgramFiles%\Nemerle, если это кому-то надо. Но надо понимать, что современные версии Интеграции могут попросту не собираться из бута.
Ну, а задать Nemerle можно и через командную строку при запуске MSBuild-а через ключ /property:<n>=<v> или /p:<n>=<v>:

MSBuild.exe /property:Nemerle=D:\MyProjects\Nemerle\nemerle\trunk

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

GR>Выходные не прошли бесследно Предлагаю посмотреть на мой патч и покритиковать.

Здорово! Молодец.

Несколько вопросов:
1. Поддерживается ли прекомпиляция ngen-ом (как это было в батч.файлах)?
2. Производится ли инициализация ключей реестра вроде HKLM\SOFTWARE\Microsoft\VisualStudio\9.0\MSBuild\SafeImports?

Другими словами насколько полно воспроизведен http:\\nemerle.org\svn\nemerle\trunk\Reg.cmd?

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

Насчет раскоментаривания <DocumentationFile>bin\Debug\Nemerle.XML</DocumentationFile> в дебаге — это приведет к еще большему замедлению процесса компиляции. Так что надо бы защитить описание этих тегов неким условием. Кому надо пусть опишут некое свойство и получат эти файлы (или наоборот, кому не надо опишут некое свойство и файлы документации генерироваться не будут.

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

Кстати, можно попробовать вот эти мсбилдные задачи:
http://msbuildtasks.tigris.org/
С их помощью можно избавиться от вызова внешних утилит и сделать многие фишки вроде комита в SVN-репозиторий.

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

VD>Несколько вопросов:
VD>1. Поддерживается ли прекомпиляция ngen-ом (как это было в батч.файлах)?
VD>2. Производится ли инициализация ключей реестра вроде HKLM\SOFTWARE\Microsoft\VisualStudio\9.0\MSBuild\SafeImports?

Посмотрел исходники... Данные вопросы снимаются. Остается только вопрос не лучше ли использовать сторонние задачи (http://www.rsdn.ru/forum/message/3007014.1.aspx

Автор: VladD2
Дата: 30.06.08

) вместо exe-шников?

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

GR>3. msbuild NemerleAll.nproj /t:Stage2 — двухпроходная сборка сомпилятора
GR>4. msbuild NemerleAll.nproj /t:VSIntegration — снячала двухпроходная сборка компилятора, потом — интеграция

Можно ли собирать компилятор и интеграцию в один проход? При работе над интеграцией частенько приходится менять компилятор. Так как это промежуточные сборки и комитить код сразу после этого не надо, то ждать второго похода слишком накладно. Плюс частенько в работе компилятор оказывается "разобранным" и собрать им себя становится невозможным, так что нельзя затирать boot.

GR>5. msbuild NemerleAll.nproj /t:RegBoot — зарегистрировать *.targets в boot

А как регистрировать в %ProgramFiles%\Nemerle?

При работе над интеграцией и компилятором самый частый сценарий это:
1. Однопроходная сборка компилятора.
2. Регистрация файлов компилятора в %ProgramFiles%\Nemerle.
3. Сборка тестов.
4. Сборка Интеграции.

Причем желательно чтобы все эти задачи выполнялись только при успешной сборке предыдущих пунктов (чтобы сборка прерывалась в случае сбоя).
Как это сделать с помощью NemerleAll.nproj?

GR>Реально вариантов больше, кому интересно — см. NemerleAll.nproj

Будем поглядать...

VD>>1. Солюшен сборки компилятора. Он должен компилировать компилятор и производить его регистрацию. Нужно сделать так чтобы можно было компилировать и без регистрации. Кроме того регистрация должна производиться как в %ProgramFiles%\Nemerle, так и в boot.
GR>Готово.
GR>3. msbuild NemerleAll.nproj /t:Stage2

Э... нужно чтобы компиляция и регистрация могла бы производиться в оду стадию. Иначе резко замедлится работа над компилятором. Я выполняю сборку в две стадии исключительно когда подготавливаю файлы к комиту в SVN.

GR>Готово, требует тестирования, т.к. реальную ситуацию с ошибкой я создать не смог, но если генерировать ошибку искуственно, то откат работает. В общем нужно тестировать.

О. Это не проблема. Для этого ошибку надо посадить в макрос которые генерировал бы некорректный код.

VD>>3. Третий солюшен должен собирать интеграцию.
GR>4. msbuild NemerleAll.nproj /t:VSIntegration

Здорово! А перед этим производится компиляция компилятора? Интеграция при этом компилируется уже новой версией компилятора? Зачастую Интеграция может быть скомпилирована только новой версией компилятора, а портить boot нельзя, так как компилятор может и не собраться текущей своей версией (частая ситуация при работе над макросами из стандартной библиотеки).

VD>>4. Ну, и должен быть еще один солюшен который собирает три предыдущих солюшена (точнее проекты из них) и собирает инсталлятор.
GR>2. msbuild NemerleAll.nproj /t:Installer

Отлично! Вот это и есть подход "зеленой факсовой кнопки".

VD>>5. Кроме того хорошо бы сделать еще один солюшен который собирал бы компилятор и интеграцию и прогонял тесты. В случае успеха можно комитить изменения. Если автоматизировать еще и комит — это будет вообще супер.
GR>Это чуть позже — времени не хватило.

Как я понимаю встроенными задачами это не реализовать (если только вызвать внешние утилиты командной строки). Но вот это

Автор: VladD2
Дата: 30.06.08

должно помочь. Можно залить бинарники этих тасков на сервер и пользоваться ими.

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

IT>Может какую другую переменную объявить? Типа NemerleBoot.
Я не совсем понимаю идею... Изначально я хотел добиться того, чтобы экспериментальная ветка смотрела на сборки компилятора из boot, а рабочая — на Program Files. Как этого добиться введением переменной NemerleBoot?

IT>Хорошо бы вообще разделить установленный на машине Nemerle стандартным образом с тем, с чем работают девелоперв. Тогда можно будет писать интеграцию на самой интеграции.
У нас мысли сходятся Как первый шаг на пути к этому я изменил все проекты (кроме самого компилятора) так, чтобы они смотрели на boot, но Влад такой ход раскритиковал — будем искать более удачное решение.

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

Сначала опишу, чего я хотел этим добиться.
1. Иметь две версии Nemerle на одной машине:
а. Стабильная версия, установленная последним официальным инсталлятором.
б. Девелоперская версия, собранная из исходников.
2. Избавиться от необходимости в процессе сборки копировать компилятор в Program Files и регистрировать его там. Это автоматом делает невозможным п. 1
3. Разрабатывать компилятор и интеграцию на чуть более ранней версии интеграции.

GR>>Сейчас я подправил проекты интеграции и шелла так, чтобы они ссылались на сборки из boot, а не на Program Files\Nemerle. ИМХО это правильней. Если я не прав — покритикуйте.
VD>Это не верное решение. В boot почти всегда находятся устаревшие версии компилятора. Он нужен исключительно для бутсрипинга. Изменяться boot должен только после успешного прохождения второй стадии компиляции (а по уму и тестов).
Сейчас так и делается. Последовательность сборки компилятора:
1. Первая фаза компиляции (исп. оригинальный boot)
2. В случае успеха п.1 копируем в boot то, что скомпилировалось
2.1 Вторая фаза — компилируем новой версией самого себя.
2.2 В случае ошибки восстанавливаем оригинальный boot.
То есть в результате сборки второй фазы boot будет уже изменен, и там лежит вполне рабочая версия компилятора.
Это то, как я понимал до сих пор процесс сборки. Но видимо в это справедливо только для тех, кому интересно просто нажать кнопку и получить работающую интеграцию. По-этому я прошу описать наиболее типичные варианты сборки для девелопера и для потребителя, т.к. удовлетворить нужно всех.

VD>Файлы в нем должны комититься как можно реже, так как это довольно большие бинарные файлы, к тому же ктитичные.
Для комита можно предусмотреть специальный таск, который в случае необходимости можно указать при сборке в командной строке явно:

msbuild NemerleAll.nproj /t:Stage2;Commit

VD>Кроме того очень важно производить прекомпиляцию сборок компилятора ngen-ом, так как это во много раз ускоряет загрузку компилятора.
Это можно делать сразу после Stage2 вот так:

msbuild NemerleAll.nproj /t:Stage2;RegProgramFiles

Для самых частых типов задач можно придумать что-нить покороче.

GR>>Еще я реализовал возможность зарегистрировать путь к Nemerle.MSBuild.targets в boot, но толку от этого мало, т.к. во всех шаблонах проектов есть такой код:

GR>>

GR>>    <PropertyGroup>
GR>>        <NoStdLib>true</NoStdLib>
GR>>        <Nemerle Condition=" '$(Nemerle)' == '' ">$(ProgramFiles)\Nemerle</Nemerle>
GR>>    </PropertyGroup>
GR>>

GR>>Единственный способ, который я нашел, заставить студию смотреть на boot — определить переменную окружения Nemerle=<путь к boot>. Если такой вариант устроит, то нужно будет в таск RegBoot добавить инструкцию, которая создает эту переменную в системе.

VD>Не надо работать из бута. Можно сделать тупое копирование файлов из бута в %ProgramFiles%\Nemerle, если это кому-то надо. Но надо понимать, что современные версии Интеграции могут попросту не собираться из бута.
В %ProgramFiles%\Nemerle очень хотелось бы иметь версию, установленную инсталлятором. Может рассмотреть вариант — копировать все это в некий \work, и там обрабатывать ngen-ом. work в SVN класть будет совсем не обязательно.

VD>Ну, а задать Nemerle можно и через командную строку при запуске MSBuild-а через ключ /property:<n>=<v> или /p:<n>=<v>:
VD>

MSBuild.exe /property:Nemerle=D:\MyProjects\Nemerle\nemerle\trunk

Или определить эту переменную в NemerleAll.nproj...

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

VD>Посмотрел исходники... Данные вопросы снимаются. Остается только вопрос не лучше ли использовать сторонние задачи (http://www.rsdn.ru/forum/message/3007014.1.aspx

Автор: VladD2
Дата: 30.06.08

) вместо exe-шников?

На выходных попробую, но сразу могу сказать, что NGen таска там нет. Смотрел еще вот эти таски http://www.codeplex.com/sdctasks, но там тоже нет.
К стати наткнулся на редактор msbuild скриптов http://www.attrice.info/downloads/index.htm — может кому пригодится.

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

VD>Насчет раскоментаривания <DocumentationFile>bin\Debug\Nemerle.XML</DocumentationFile> в дебаге — это приведет к еще большему замедлению процесса компиляции. Так что надо бы защитить описание этих тегов неким условием. Кому надо пусть опишут некое свойство и получат эти файлы (или наоборот, кому не надо опишут некое свойство и файлы документации генерироваться не будут.

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

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

VD>Можно ли собирать компилятор и интеграцию в один проход? При работе над интеграцией частенько приходится менять компилятор. Так как это промежуточные сборки и комитить код сразу после этого не надо, то ждать второго похода слишком накладно. Плюс частенько в работе компилятор оказывается "разобранным" и собрать им себя становится невозможным, так что нельзя затирать boot.
В данной версии скриптов это не предусмотрено, но сделать можно. Но пред тем, как что-то делать хотелось бы договориться насчет копирования (а точнее не копирования) бинарников в Program Files. Как вариант рядом с boot можно разместить папку work, и туда класть результат превой фазу. Туда же копировать и targets, и там же все это регистрировать. При этом work в SVN класть не нужно — он всегда будет создаваться на первой фазе компиляции.

VD>А как регистрировать в %ProgramFiles%\Nemerle?
msbuild NemerleAll.nproj /t:RegProgramFiles

VD>При работе над интеграцией и компилятором самый частый сценарий это:
VD>1. Однопроходная сборка компилятора.
VD>2. Регистрация файлов компилятора в %ProgramFiles%\Nemerle.
VD>3. Сборка тестов.
VD>4. Сборка Интеграции.
Добро, реализую такой сценарий и сделаю его по умолчанию. Сборка будет до безобрази проста: msbuild NemerleAll.nproj

VD>Причем желательно чтобы все эти задачи выполнялись только при успешной сборке предыдущих пунктов (чтобы сборка прерывалась в случае сбоя).
VD>Как это сделать с помощью NemerleAll.nproj?

GR>>Реально вариантов больше, кому интересно — см. NemerleAll.nproj
VD>Будем поглядать...
Это поможет http://www.attrice.info/downloads/index.htm

VD>>>1. Солюшен сборки компилятора. Он должен компилировать компилятор и производить его регистрацию. Нужно сделать так чтобы можно было компилировать и без регистрации. Кроме того регистрация должна производиться как в %ProgramFiles%\Nemerle, так и в boot.
GR>>Готово.
GR>>3. msbuild NemerleAll.nproj /t:Stage2

VD>Э... нужно чтобы компиляция и регистрация могла бы производиться в оду стадию. Иначе резко замедлится работа над компилятором. Я выполняю сборку в две стадии исключительно когда подготавливаю файлы к комиту в SVN.
Не вопрос
msbuild NemerleAll.nproj /t:Stage2;RegProgramFiles
или
msbuild NemerleAll.nproj /t:Stage2;RegBoot

GR>>Готово, требует тестирования, т.к. реальную ситуацию с ошибкой я создать не смог, но если генерировать ошибку искуственно, то откат работает. В общем нужно тестировать.
VD>О. Это не проблема. Для этого ошибку надо посадить в макрос которые генерировал бы некорректный код.
На выходных попробую

VD>>>3. Третий солюшен должен собирать интеграцию.
GR>>4. msbuild NemerleAll.nproj /t:VSIntegration

VD>Здорово! А перед этим производится компиляция компилятора?
Да, Stage2, но насколько я понял, здесь нужна Stage1.
VD>Интеграция при этом компилируется уже новой версией компилятора?
Да, из boot, в котором уже новая версия компилятора
VD>Зачастую Интеграция может быть скомпилирована только новой версией компилятора, а портить boot нельзя, так как компилятор может и не собраться текущей своей версией (частая ситуация при работе над макросами из стандартной библиотеки).
А вот над этим нужно будет еще потрудиться, т.к. интеграция сейчас смотрит на boot, который затирается после Stage2 (см. предложение относительно work)

VD>>>4. Ну, и должен быть еще один солюшен который собирает три предыдущих солюшена (точнее проекты из них) и собирает инсталлятор.
GR>>2. msbuild NemerleAll.nproj /t:Installer
VD>Отлично! Вот это и есть подход "зеленой факсовой кнопки".
Это значительно приятней, чем когда только посвященные могут собрать инсталлятор

VD>>>5. Кроме того хорошо бы сделать еще один солюшен который собирал бы компилятор и интеграцию и прогонял тесты. В случае успеха можно комитить изменения. Если автоматизировать еще и комит — это будет вообще супер.
GR>>Это чуть позже — времени не хватило.

VD>Как я понимаю встроенными задачами это не реализовать (если только вызвать внешние утилиты командной строки). Но вот это

Автор: VladD2
Дата: 30.06.08

должно помочь. Можно залить бинарники этих тасков на сервер и пользоваться ими.
Вот только как бы все это протестировать... На живом SVN, пожалуй, не хорошо. Нужно будет копию развернуть и в тестовом режиме туда комитить пока не заработает как положено.