Запустить VS2008 Command Prompt с правами администратора и запустить BuildInstallerRelease.cmd.
Наслаждаться логами и взять инсталлятор в misc\packages\wix\bin\Release.
Никаких изменений в сорсах не требуется (по крайней мере пока).
Здравствуйте, VladD2, Вы писали:
VD>А полученный инсталлятор не глючит? А то мы тут пытаемся на сервере процесс компиляции запустить и в результате получаются битые инсталляторы. При попытке создать проект выдается сообщение что languageService == null.
Довел скрипт до состояния, когда можно скомпилировать инсталлятор. Полученный инсталлятор глючит.
Собирать сейчас можно двумя способами — быстро и очень медленно.
Быстрый способ — одна стадия компиляции компилятора, нет вылидации и тесты не запускаются
Очень медленный — 4 фазы компиляции компилятора, валидация сборок, запуск тестов
Инсталлятор проверил пока только в случае быстрой сборки.
Здравствуйте, gloomy rocker, Вы писали:
GR>>>Полученный инсталлятор глючит.
VD>>Это как раз то сообщение о том что "languageService == null"? GR>Оно самое.
У меня такое сообщение появлялось при отсутствии в "\Program Files\Nemerle" файла WpfHint.dll
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Здравствуйте, _nn_, Вы писали:
KV>не против, если я заменю BuildInstallerRelease.cmd и BuildInstallerFull.cmd на один
Только за
Батник можно немного улучшить
@echo off
rem Check perquisites
rem // Тут надо еще добавить проверку, что есть необходимые файлы, необходимые программы и т.п.
rem // Лучше сразу узнать что не хватает чем получить непонятные сообщения об ошибках.
rem // Проверка VS
rem // Проверка VS SDK
rem // Проверка NUnit
rem // Проверка Wix
rem // Проверка Reflector addon
rem И т.д.
if"%~1"=="" (
set Type=Release
) else (
set Type=%1
)
set NoPause=true
set Nemerle=%~dp0\boot
rem Build MSBuild task
call Build-MSBuildTask.cmd
rem Copy MSBuild targets to boot
copy "tools\msbuild-task\Nemerle.MSBuild.targets" /b "boot\"
rem Actualize revision number
misc\packages\wix\tools\SubWCRev.exe .\ misc\packages\wix\src\Version.wxi.template misc\packages\wix\src\Version.wxi
rem Build Installer
set MSBuild="%SystemRoot%\Microsoft.NET\Framework\v3.5\msbuild.exe"
%MSBuild% NemerleAll.nproj /t:InstallerFull /p:Configuration=%Type%
rem Done
set Type=
set NoPause=
set Nemerle=
del misc\packages\wix\src\Version.wxi
Не все так просто, как может показаться на первый взгляд.
Некоторые проекты в исходниках Nemerle компилируются только если в $(ProgramFiles)\Nemerle лежат сборки компилятора.
Так ведет себя, например проект Linq.nproj. Кроме того в NemerleAll.nproj, при сборке цели NccFull или NccFast (а они предшествуют сборке интеграции и инсталлятора) идет копирование всего необходимого в $(ProgramFiles)\Nemerle.
От $(ProgramFiles)\Nemerle при сборке инсталлятора или компилятора по хорошему вообще нужно избавиться.
У меня на работе назрела необходимость перейти на одну из последних версий Nemerle, и пришлось взяться за старое и повозиться со сборкой.
Выяснился такой нюанс. В $(Nemerle)\tools\msbuild-task есть два интересных файла: Compiler.MSBuild.targets и Nemerle.MSBuild.targets. Основное их отличие состоит в том, что Compiler.MSBuild.targets предполагает, что компилер находится в boot-е, а Nemerle.MSBuild.targets — ищет компилер там, куда указывает переменная $(Nemerle). В связи с этим у мня появилась идея, что Compiler.MSBuild.targets есть частный случай Nemerle.MSBuild.targets.
Я попробовал изменить файлы проектов ncc.nproj, nemerle.nproj и т.д. следующим образм:
В результате, как я и ожидал, все прекрасно скомпилировалось, но пришлось докручивать NemerleAll.nproj
Теперь немного о том, чего хочется от NemerleAll.nproj и что я уже сделал.
Сейчас у меня компиляция идет в 4 стадии и результат каждой стадии компиляции лежит отдельно в папке bin\$(Configuration)\$(Stage)
Stage1 компилируется компилятором из boot
Stage2 — компилятором из bin\$(Configuration)\Stage1
и т.д.
Кроме всего прочего решилась проблема с цветным выводом сообщений на консоль при компиляции. Это стало возможным благодаря тому,
что одна и та же цель собирается с разными параметрами.
Собственно на этом я пока остановился. Думаю денек-другой, и смогу довести этот MSBuild-ный скрипт до ума так, чтобы не использовать $(ProgramFiles).
Но для того нужна отмашка старших разработчиков. Может я не до конца понимаю смысл наличия двух разных targets файлов.
не против, если я заменю BuildInstallerRelease.cmd и BuildInstallerFull.cmd на один
BuildInstaller.cmd:
@echo off
if "%1"=="" goto default
set Type=%1
goto build
:default
set Type=Release
:build
set NoPause=true
set Nemerle=%~dp0\boot
rem Build MSBuild task
call Build-MSBuildTask.cmd
rem Copy MSBuild targets to boot
copy "tools\msbuild-task\Nemerle.MSBuild.targets" /b "boot\"
rem Actualize revision number
misc\packages\wix\tools\SubWCRev.exe .\ misc\packages\wix\src\Version.wxi.template misc\packages\wix\src\Version.wxi
rem Build Installer
set MSBuild="%SystemRoot%\Microsoft.NET\Framework\v3.5\msbuild.exe"
%MSBuild% NemerleAll.nproj /t:InstallerFull /p:Configuration=%Type%
rem Done
set Type=
set NoPause=
set Nemerle=
del misc\packages\wix\src\Version.wxi
это позволит:
— собирать и debug и release инсталлеры одним скриптом (передавая ему параметром нужную конфигурацию, либо release, если без параметров)
— подставлять автоматом в ProductVersion ревизию, из которой собирается инсталлер
— запустить, наконец-таки, автосборку на каждый коммит и автовыкладывание обоих версий инсталлера на сайт проекта.
От такого решения могут быть проблемы. Дело в том, что проекты интеграции и Linq-а должны компилироваться исключительно бинарниками собранными из исходника. В boot-е может быть версия которая не подходит для их сборки. Так что компиляция попросту может не пройти.
Переменную Nemerle нужно задавать только после того как будут скомпилированы сборки компилятора и на ту директорию в которую они будут помещены в процессе компиляции.
Соответственно это нужно делать из проекта, а не из батника.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Здравствуйте, _nn_, Вы писали:
KV>Народ, помогите понять, у всех сборка последней ревизии 8751 сломалась и выдает кучу ошибок на parser.n, или это я у себя с окружением намудрил?
KV>
Здравствуйте, _nn_, Вы писали:
__>Здравствуйте, kochetkov.vladimir, Вы писали:
KV>>Здравствуйте, _nn_, Вы писали:
KV>>не против, если я заменю BuildInstallerRelease.cmd и BuildInstallerFull.cmd на один __>Только за
Ок, добавлю проверки prereq и залью в проект
__>Батник можно немного улучшить
__>
__>if"%~1"=="" (
__> set Type=Release
__>) else (
__> set Type=%1
__>)
__>
__>
Здравствуйте, _nn_, Вы писали:
GR>>Не все так просто, как может показаться на первый взгляд. GR>>Некоторые проекты в исходниках Nemerle компилируются только если в $(ProgramFiles)\Nemerle лежат сборки компилятора. GR>>Так ведет себя, например проект Linq.nproj. Кроме того в NemerleAll.nproj, при сборке цели NccFull или NccFast (а они предшествуют сборке интеграции и инсталлятора) идет копирование всего необходимого в $(ProgramFiles)\Nemerle. GR>>От $(ProgramFiles)\Nemerle при сборке инсталлятора или компилятора по хорошему вообще нужно избавиться.
__>У меня при установке set Nemerle=NemerleProjectPath\boot ничего не копируется в $(ProgramFiles). __>Собирал через BuildInstallerRelease.cmd .
Я имел виду, что внутренности NemerleAll.nproj устроены так, что в $(ProgramFiles) компилятор все же копируется.
Там есть такая цель, называется RegProgFiles. Кроме того boot лучше лишний раз не трогать. По хорошему его можно
перезаписать только после четвертой стадии и всех возможных тестов и валидаций.
__>Все должно работать нормально.
Да, если задать переменную $(Nemerle).
__>Только если $(Nemerle) не установлен берется $(ProgramFiles). __>А вообще конечно хорошо убрать $(ProgramFiles) как директорию по умолчанию. __>Может проще требовать, чтобы переменная Nemerle была установлена или там NRoot или другая ?
Я думаю, что скрипт NemerleAll.nproj нужно доделать таким образом, чтобы можно было на каждой стадии задавать, где взять boot-компилятор, и куда положить новый компилятор. Это делается путем задания двух свойств: Nemerle и OutDir.
А установку в ProgramFiles, регистрацию в GAC, NGen и т.д. нужно делать отдельной целью.
В общем надо в файлах misc\packages\wix\src\*.wxs убрать требование PDB: <?if $(var.IncludePdb) ?>.
Либо изменить на <?if $(var.IncludePdb) = "true" ?>
Тут надо либо решить, что PDB нужны в релизе либо решить что они не нужны, и изменить проверку как надо.
Здравствуйте, _nn_, Вы писали:
__>В общем надо в файлах misc\packages\wix\src\*.wxs убрать требование PDB: <?if $(var.IncludePdb) ?>. __>Либо изменить на <?if $(var.IncludePdb) = "true" ?>
__>Тут надо либо решить, что PDB нужны в релизе либо решить что они не нужны, и изменить проверку как надо.
PDB-шки конечно хорошо бы иметь. Это позволит упростить отладку макросов.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, _nn_, Вы писали:
__>>Добавил новый батник.
VD>А зачем копировать boot в "%ProgramFiles%\Nemerle ?
VD>В boot-е бинарники более старых версий. А при сборке проектов самого компилятора можно указать, чтобы использовался компилятор из boot-а.
Если не сложно, подправь.
Я не знаю как это делается
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, _nn_, Вы писали:
__>>В общем надо в файлах misc\packages\wix\src\*.wxs убрать требование PDB: <?if $(var.IncludePdb) ?>. __>>Либо изменить на <?if $(var.IncludePdb) = "true" ?>
__>>Тут надо либо решить, что PDB нужны в релизе либо решить что они не нужны, и изменить проверку как надо.
VD>PDB-шки конечно хорошо бы иметь. Это позволит упростить отладку макросов.
Согласен.
Я в MSBuild-е не силен, вот и не добавил.
Кто может, исправьте
Здравствуйте, _nn_, Вы писали:
VD>>В boot-е бинарники более старых версий. А при сборке проектов самого компилятора можно указать, чтобы использовался компилятор из boot-а.
__>Если не сложно, подправь. __>Я не знаю как это делается
Чтобы править, нужно тестировать (и вникать в проблематику). Я загружен другими делами, так что лучше правь ты.
Что касается boot-а, то как я понимаю, особо правит ничего не надо. Проекты компилятора включают импорт Compiler.MSBuild.targets в котором пути к компилятору и Nemerle.MSBuild.Tasks.dll прописаны на boot.
Для проекты интеграции используют импорт стандартного Nemerle.MSBuild.targets где для вычисления пути к каталогу компилятора используется переменная среды окружения "Nemerle". Ее можно заменить в самом начале компиляции, так чтобы она уазывала на bin\Release компилятора.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, _nn_, Вы писали:
__>Добавил новый батник. __>Просто запускаете и инсталлятор компилируется.
Никто с такой ошибкой при сборке инсталлятора не сталкивался?
"D:\Projects\Nemerle\svn\NemerleAll.nproj" (InstallerFast target) (1) ->
"D:\Projects\Nemerle\svn\VSIntegration\Nemerle.VSIP.sln" (Rebuild target) (7) ->
"D:\Projects\Nemerle\svn\VSIntegration\Nemerle.VisualStudio\Nemerle.VisualStudio.csproj" (Rebuild target) (13) ->
(GeneratePkgDef target) ->
regpkg : error : Unable to load one or more of the requested types. Retrieve the LoaderExceptions property for more information.
вот думаю — то ли я в коде накосячил, то ли с окружением/настройками что то не так?
Здравствуйте, seregaa, Вы писали:
S>Никто с такой ошибкой при сборке инсталлятора не сталкивался?
S>
S>"D:\Projects\Nemerle\svn\NemerleAll.nproj" (InstallerFast target) (1) ->
S>"D:\Projects\Nemerle\svn\VSIntegration\Nemerle.VSIP.sln" (Rebuild target) (7) ->
S>"D:\Projects\Nemerle\svn\VSIntegration\Nemerle.VisualStudio\Nemerle.VisualStudio.csproj" (Rebuild target) (13) ->
S>(GeneratePkgDef target) ->
S> regpkg : error : Unable to load one or more of the requested types. Retrieve the LoaderExceptions property for more information.
S>
S>вот думаю — то ли я в коде накосячил, то ли с окружением/настройками что то не так?
Разобрался. Причина была в том, что я добавил в проект Nemerle.VisualStudio ссылку на сборку
"C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\Microsoft.VisualStudio.Web.Application.dll"
заменил на
"C:\Program Files\Microsoft Visual Studio 2008 SDK\VisualStudioIntegration\Common\Assemblies\"Microsoft.VisualStudio.Web.Application.dll"
и сборка заработала.
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Народ, помогите понять, у всех сборка последней ревизии 8751 сломалась и выдает кучу ошибок на parser.n, или это я у себя с окружением намудрил?
Похоже я что-то напортачил. Только не в parser.n, а в PreParser.n.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Народ, помогите понять, у всех сборка последней ревизии 8751 сломалась и выдает кучу ошибок на parser.n, или это я у себя с окружением намудрил?
Похоже это не я, а emperon в ревизии 8566.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Забыл написать, что Nemerle.MSBuild.targets приходится перед началом очередной фазы компиляции копировать в папку, на которую указывает переменная $(Nemerle). В том числе и в boot.
Здравствуйте, gloomy rocker, Вы писали:
GR>Здравствуйте, kochetkov.vladimir, Вы писали:
GR>Привет от автора NemerleAll.nproj
GR>Не все так просто, как может показаться на первый взгляд. GR>Некоторые проекты в исходниках Nemerle компилируются только если в $(ProgramFiles)\Nemerle лежат сборки компилятора. GR>Так ведет себя, например проект Linq.nproj. Кроме того в NemerleAll.nproj, при сборке цели NccFull или NccFast (а они предшествуют сборке интеграции и инсталлятора) идет копирование всего необходимого в $(ProgramFiles)\Nemerle. GR>От $(ProgramFiles)\Nemerle при сборке инсталлятора или компилятора по хорошему вообще нужно избавиться.
У меня при установке set Nemerle=NemerleProjectPath\boot ничего не копируется в $(ProgramFiles).
Собирал через BuildInstallerRelease.cmd .
Только если $(Nemerle) не установлен берется $(ProgramFiles).
А вообще конечно хорошо убрать $(ProgramFiles) как директорию по умолчанию.
Может проще требовать, чтобы переменная Nemerle была установлена или там NRoot или другая ?
Здравствуйте, gloomy rocker, Вы писали:
GR>Сейчас у меня компиляция идет в 4 стадии и результат каждой стадии компиляции лежит отдельно в папке bin\$(Configuration)\$(Stage) GR>Stage1 компилируется компилятором из boot GR>Stage2 — компилятором из bin\$(Configuration)\Stage1 GR>и т.д.
С четырьмя стадиями сборки обнаружилась проблема. Дело все в том, что вся сборка идет в одном AppDomain-е. Происходит следующее:
1. При сборке Stage1 из boot загружается Nemerle.MSBuild.Tasks.dll версии, допустим, 1.1.1.1
2. Результат компиляции помещается в папку bin\$(Configuration)\Stage1
3. При компиляции Stage2 из bin\$(Configuration)\Stage1 загружается Nemerle.MSBuild.Tasks.dll версии, допустим, 2.2.2.2
4. Поскольку версии в данном случае разные, то пока все хорошо и Stage2 собирается компилятором из Stage1
5. При компиляции Stage3 MSBuild пытается загрузить Nemerle.MSBuild.Tasks.dll из bin\$(Configuration)\Stage2
6. Поскольку версии сборок в bin\$(Configuration)\Stage1 и bin\$(Configuration)\Stage2 совпадают, то MSBuild продолжает использовать ранее загруженную из bin\$(Configuration)\Stage1 сборку.
7. Задача Ncc, которая в этой сборке находится использует ncc.exe, который лежит в той же папке, где и Nemerle.MSBuild.Tasks.dll
В результате получается, что Stage1 компилируется компилятором из boot, а Stage2-4 — из компилятором bin\$(Configuration)\Stage1
GR>Кроме всего прочего решилась проблема с цветным выводом сообщений на консоль при компиляции. Это стало возможным благодаря тому, GR>что одна и та же цель собирается с разными параметрами.
В свете описанной проблемы это утверждение временно утратило силу.
Варианты решения:
1. Вместо задачи MSBuild использовать Exec, но тогда теряется цветной вывод на консоль.
2. Спекулятивное присвоение версии сборкам разных стадий
3. Копирование boot в промежуточную папку, а потом копировать туда результат каждой стадии, за исключением Nemerle.MSBuild.Tasks.dll
4. Предложите свой вариант.
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Ок, добавлю проверки prereq и залью в проект
Я вот как-то подумал, может стоит добавить wget.exe (Ну или VBScript + WinHTTP, или что-то другое чтобы под линуксом собрать можно было ) в проект и если не найдена нужная программа, то ее можно предложить скачать и установить.
Это я про VS SDK, Wix, NUnit, Reflector.
Для небольших файлов можно, наверное, добавить сам msi в проект и запускать его если не установлен.
А для больших файлов, или с которыми может быть проблема с лицензией, предлагать скачать.
Здравствуйте, gloomy rocker, Вы писали:
GR>Варианты решения: GR>1. Вместо задачи MSBuild использовать Exec, но тогда теряется цветной вывод на консоль.
ИМХО это пока наиболее простой и наименее кривой вариант.
GR>2. Спекулятивное присвоение версии сборкам разных стадий GR>3. Копирование boot в промежуточную папку, а потом копировать туда результат каждой стадии, за исключением Nemerle.MSBuild.Tasks.dll
Этот вариант проверил — не работает. Nemerle.MSBuild.Tasks.dll зависит от Nemerle.dll, которая блокируется процессом MSBuild.
Чтобы такой вариант заработал нужно будет переписать Nemerle.MSBuild.Tasks.dll так, чтобы он не зависел от Nemerle.dll.
GR>4. Предложите свой вариант.
Можно еще посмотреть в сторону AppDomainIsolatedTask, но переусложнять тоже не хочется.
Здравствуйте, gloomy rocker, Вы писали:
GR>Не все так просто, как может показаться на первый взгляд. GR>Некоторые проекты в исходниках Nemerle компилируются только если в $(ProgramFiles)\Nemerle лежат сборки компилятора. GR>Так ведет себя, например проект Linq.nproj.
Это не совсем так. Linq.nproj — это стандартный проект интеграции и то где лежат бинарники определяется (в нем) переменной среды окружения "Nemerle". Если она не задана, то в нее подставляется путь "$(ProgramFiles)\Nemerle". Если задана, то используется заданный путь. Вот начала этого проекта:
Так что перед компиляцией этого проекта достаточно задать путь к бинарникам в переменную "Nemerle" и он будет использовать именно их.
GR> Кроме того в NemerleAll.nproj, при сборке цели NccFull или NccFast (а они предшествуют сборке интеграции и инсталлятора) идет копирование всего необходимого в $(ProgramFiles)\Nemerle. GR>От $(ProgramFiles)\Nemerle при сборке инсталлятора или компилятора по хорошему вообще нужно избавиться.
Согласен.
GR>У меня на работе назрела необходимость перейти на одну из последних версий Nemerle, и пришлось взяться за старое и повозиться со сборкой. GR>Выяснился такой нюанс. В $(Nemerle)\tools\msbuild-task есть два интересных файла: Compiler.MSBuild.targets и Nemerle.MSBuild.targets. Основное их отличие состоит в том, что Compiler.MSBuild.targets предполагает, что компилер находится в boot-е, а Nemerle.MSBuild.targets — ищет компилер там, куда указывает переменная $(Nemerle). В связи с этим у мня появилась идея, что Compiler.MSBuild.targets есть частный случай Nemerle.MSBuild.targets.
Да, так и есть. Копи-пас там по недоразумению.
GR>Я попробовал изменить файлы проектов ncc.nproj, nemerle.nproj и т.д. следующим образм: GR>...Измененный ncc.nproj GR>
Думаю, что условие (Condition=" '$(Nemerle)' == '' ") тут лишнее.
Может получиться так, что кто-то задаст переменную "Nemerle" в Windows. Это приведет к тому, что компилятор начнет собираться черт знает какими бинарниками. А он обязан собираться только бинарниками из boot-а или скомпилированными из них.
GR>В результате, как я и ожидал, все прекрасно скомпилировалось, но пришлось докручивать NemerleAll.nproj
Отлично!
GR>Теперь немного о том, чего хочется от NemerleAll.nproj и что я уже сделал. GR>Сейчас у меня компиляция идет в 4 стадии и результат каждой стадии компиляции лежит отдельно в папке bin\$(Configuration)\$(Stage) GR>Stage1 компилируется компилятором из boot GR>Stage2 — компилятором из bin\$(Configuration)\Stage1 GR>и т.д.
А полученный инсталлятор не глючит? А то мы тут пытаемся на сервере процесс компиляции запустить и в результате получаются битые инсталляторы. При попытке создать проект выдается сообщение что languageService == null.
GR>Кроме всего прочего решилась проблема с цветным выводом сообщений на консоль при компиляции. Это стало возможным благодаря тому, что одна и та же цель собирается с разными параметрами.
Этого не понял, ну да ладно.
GR>Собственно на этом я пока остановился. Думаю денек-другой, и смогу довести этот MSBuild-ный скрипт до ума так, чтобы не использовать $(ProgramFiles). GR>Но для того нужна отмашка старших разработчиков. Может я не до конца понимаю смысл наличия двух разных targets файлов.
С таргетами ты совершенно прав.
Так что заливай изменения. В крайнем случае, будем разбираться по месту.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, gloomy rocker, Вы писали:
GR>Забыл написать, что Nemerle.MSBuild.targets приходится перед началом очередной фазы компиляции копировать в папку, на которую указывает переменная $(Nemerle). В том числе и в boot.
Мы уже пользуемся услугами утилиты junction.exe. Наверно, имеет смысл вместо копирования создавать с ее помощью ссылки на файлы.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, _nn_, Вы писали:
__>Только если $(Nemerle) не установлен берется $(ProgramFiles). __>А вообще конечно хорошо убрать $(ProgramFiles) как директорию по умолчанию. __>Может проще требовать, чтобы переменная Nemerle была установлена или там NRoot или другая ?
Вот этого не надо. Явно заданная переменная на машине будет приводить к проблемам. Ее должен задавать исключительно инсталлятор и только при условии, что местоположение компилятора не совпадает с "$(ProgramFiles)\Nemerle".
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, gloomy rocker, Вы писали:
GR>Я думаю, что скрипт NemerleAll.nproj нужно доделать таким образом, чтобы можно было на каждой стадии задавать, где взять boot-компилятор, и куда положить новый компилятор. Это делается путем задания двух свойств: Nemerle и OutDir.
+1
GR>А установку в ProgramFiles, регистрацию в GAC, NGen и т.д. нужно делать отдельной целью.
А вот в GAC лучше не надо. Только если совсем отдельной целью которая по умолчанию не будет вызваться.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, gloomy rocker, Вы писали:
GR>5. При компиляции Stage3 MSBuild пытается загрузить Nemerle.MSBuild.Tasks.dll из bin\$(Configuration)\Stage2 GR>6. Поскольку версии сборок в bin\$(Configuration)\Stage1 и bin\$(Configuration)\Stage2 совпадают, то MSBuild продолжает использовать ранее загруженную из bin\$(Configuration)\Stage1 сборку.
Хм. Фигово.
Пути решения проблемы видятся следующие:
1. Использовать не задачу MSBuild, а задачу Exec в которой уже вызвать MSBuild.exe. Тогда он будет в отдельном процессе и проблема должна исчезнуть.
2. Подправить Nemerle.MSBuild.Tasks.dll так чтобы она могла получать путь к NCC.exe в качестве одного из свойств.
3. К едрене фене переписать Nemerle.MSBuild.Tasks.dll на C#, чтобы он больше не доставал. Он уже давно проблемы создает.
GR>7. Задача Ncc, которая в этой сборке находится использует ncc.exe, который лежит в той же папке, где и
GR>Варианты решения: GR>1. Вместо задачи MSBuild использовать Exec, но тогда теряется цветной вывод на консоль. GR>2. Спекулятивное присвоение версии сборкам разных стадий GR>3. Копирование boot в промежуточную папку, а потом копировать туда результат каждой стадии, за исключением Nemerle.MSBuild.Tasks.dll
Ой. Вот что значит отвечать не дочитав до конца .
Мне кажется, все, кроме первого, предложенные тобой варианты имеют свои изъяны. Так копирование может привести к блокированию файлов во время сборки. От этого мы ведь и пытаемся уйти.
GR>4. Предложите свой вариант.
Мои я уже предложил выше. Самым простым видится добавление параметра (свойства) в Nemerle.MSBuild.Tasks.dll который будет указывать ему где брать компилятор.
А вообще, изначально нужно было писать Nemerle.MSBuild.Tasks.dll на шарпе. Тогда всех этих проблем с зависимостями попросту не было бы.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, gloomy rocker, Вы писали:
GR>Чтобы такой вариант заработал нужно будет переписать Nemerle.MSBuild.Tasks.dll так, чтобы он не зависел от Nemerle.dll.
Это уже делали, но видимо снова что-то напортачили.
GR>>4. Предложите свой вариант.
GR>Можно еще посмотреть в сторону AppDomainIsolatedTask, но переусложнять тоже не хочется.
Согласен.
Мне кажется разумных выхода только три:
1. Переписать Nemerle.MSBuild.Tasks.dll на шарпе. Логика там примитивная.
2. Добавить в Nemerle.MSBuild.Tasks.dll параметр говорящий откуда брать ncc.exe. Тут так же могут быть проблемы с блокировками.
3. Вызвать вложенные MSBuild-ы через Exec.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
GR>>Я попробовал изменить файлы проектов ncc.nproj, nemerle.nproj и т.д. следующим образм: GR>>...Измененный ncc.nproj GR>>
VD>Думаю, что условие (Condition=" '$(Nemerle)' == '' ") тут лишнее. VD>Может получиться так, что кто-то задаст переменную "Nemerle" в Windows. Это приведет к тому, что компилятор начнет собираться черт знает какими бинарниками. А он обязан собираться только бинарниками из boot-а или скомпилированными из них.
А не затрется ли в таком случае значение переменной $(Nemerle), переданное извне? У меня сильное предчувствие, что затрется, и невозможно будет указать, каким компилятором собирать проект.
GR>>В результате, как я и ожидал, все прекрасно скомпилировалось, но пришлось докручивать NemerleAll.nproj
VD>Отлично!
Я имел в виду, что собрался компилятор. Дальше я пока не продвинулся.
GR>>Теперь немного о том, чего хочется от NemerleAll.nproj и что я уже сделал. GR>>Сейчас у меня компиляция идет в 4 стадии и результат каждой стадии компиляции лежит отдельно в папке bin\$(Configuration)\$(Stage) GR>>Stage1 компилируется компилятором из boot GR>>Stage2 — компилятором из bin\$(Configuration)\Stage1 GR>>и т.д.
VD>А полученный инсталлятор не глючит? А то мы тут пытаемся на сервере процесс компиляции запустить и в результате получаются битые инсталляторы. При попытке создать проект выдается сообщение что languageService == null.
До инсталлятора пока дело не дошло. См. выше.
GR>>Кроме всего прочего решилась проблема с цветным выводом сообщений на консоль при компиляции. Это стало возможным благодаря тому, что одна и та же цель собирается с разными параметрами.
VD>Этого не понял, ну да ладно.
Раньше сборка компилятора запускалась в отдельном процессе с помощью задачи Exec. При этом вывод на консоль цветом не выделялся, как выделялся бы при использовании задачи MSBuild. MSBuild у меня раньше не получалось использовать, т.к. с одними и теми же параметрами его можно выполнить только один раз.
GR>>Собственно на этом я пока остановился. Думаю денек-другой, и смогу довести этот MSBuild-ный скрипт до ума так, чтобы не использовать $(ProgramFiles). GR>>Но для того нужна отмашка старших разработчиков. Может я не до конца понимаю смысл наличия двух разных targets файлов.
VD>С таргетами ты совершенно прав.
Ок
VD>Так что заливай изменения. В крайнем случае, будем разбираться по месту.
Для этого нужен доступ к SVN. Мой gmail: gordynych@gmail.com
Здравствуйте, VladD2, Вы писали:
VD>Пути решения проблемы видятся следующие: VD>1. Использовать не задачу MSBuild, а задачу Exec в которой уже вызвать MSBuild.exe. Тогда он будет в отдельном процессе и проблема должна исчезнуть. VD>2. Подправить Nemerle.MSBuild.Tasks.dll так чтобы она могла получать путь к NCC.exe в качестве одного из свойств. VD>3. К едрене фене переписать Nemerle.MSBuild.Tasks.dll на C#, чтобы он больше не доставал. Он уже давно проблемы создает.
Если нет возражений, я остановлюсь на первом варианте. Минус будет только один — цели, предупреждения и ошибки не будут подсвечиваться соответствующими цветами.
GR>>1. Вместо задачи MSBuild использовать Exec, но тогда теряется цветной вывод на консоль. VD>Мне кажется, все, кроме первого, предложенные тобой варианты имеют свои изъяны. Так копирование может привести к блокированию файлов во время сборки. От этого мы ведь и пытаемся уйти.
Мнения сходятся.
VD>А вообще, изначально нужно было писать Nemerle.MSBuild.Tasks.dll на шарпе. Тогда всех этих проблем с зависимостями попросту не было бы.
У меня, если честно, времени на это сейчас нет. Если найдутся энтузиасты и сделают это, я потом могу доработать скрипт.
Здравствуйте, VladD2, Вы писали:
VD>А вот в GAC лучше не надо. Только если совсем отдельной целью которая по умолчанию не будет вызваться.
GAC я по инерции упомянул. Сейчас в скрипте вроде и нет такой задачи.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, gloomy rocker, Вы писали:
GR>>Забыл написать, что Nemerle.MSBuild.targets приходится перед началом очередной фазы компиляции копировать в папку, на которую указывает переменная $(Nemerle). В том числе и в boot.
VD>Мы уже пользуемся услугами утилиты junction.exe. Наверно, имеет смысл вместо копирования создавать с ее помощью ссылки на файлы.
ИМХО разницы никакой. Но в принципе можно, когда скрипт будет отлажен и останется только причесать его.
Здравствуйте, gloomy rocker, Вы писали:
GR>А не затрется ли в таком случае значение переменной $(Nemerle), переданное извне? У меня сильное предчувствие, что затрется, и невозможно будет указать, каким компилятором собирать проект.
Конечно затрется. Но, как я понимаю, только в рамках текущего проекта.
И в нем оно уже будет не интересно. Ведь ведется сборка конкретной конфигурации. Если кому-то оно нужно, то можно создать еще одно свойство, например NemerleOldValue и сохранить старое значение свойства в нем.
GR>Я имел в виду, что собрался компилятор. Дальше я пока не продвинулся. GR>...До инсталлятора пока дело не дошло. См. выше.
Ясно. Жаль. Ну, да может все же дойдут.
Для инсталлятора Nemerle можно смело задавать нужное значение (кактлог).
GR>Раньше сборка компилятора запускалась в отдельном процессе с помощью задачи Exec. При этом вывод на консоль цветом не выделялся, как выделялся бы при использовании задачи MSBuild. MSBuild у меня раньше не получалось использовать, т.к. с одними и теми же параметрами его можно выполнить только один раз.
Понял, то есть цвет зависит от того используется ли задача MSBuild или Exec.
Ну, значит надо решать вопрос с Nemerle.MSBuild.Tasks.dll.
VD>>Так что заливай изменения. В крайнем случае, будем разбираться по месту. GR>Для этого нужен доступ к SVN. Мой gmail: gordynych@gmail.com
Добавил.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, gloomy rocker, Вы писали:
VD>>Пути решения проблемы видятся следующие: VD>>1. Использовать не задачу MSBuild, а задачу Exec в которой уже вызвать MSBuild.exe. Тогда он будет в отдельном процессе и проблема должна исчезнуть. VD>>2. Подправить Nemerle.MSBuild.Tasks.dll так чтобы она могла получать путь к NCC.exe в качестве одного из свойств. VD>>3. К едрене фене переписать Nemerle.MSBuild.Tasks.dll на C#, чтобы он больше не доставал. Он уже давно проблемы создает. GR>Если нет возражений, я остановлюсь на первом варианте. Минус будет только один — цели, предупреждения и ошибки не будут подсвечиваться соответствующими цветами.
Ну, вот как раз против бесцветия возражения есть. Привык я к цветам . Так что двай как для начала попробуем вариант 2. Там делов то на 5 минут.
VD>>А вообще, изначально нужно было писать Nemerle.MSBuild.Tasks.dll на шарпе. Тогда всех этих проблем с зависимостями попросту не было бы. GR>У меня, если честно, времени на это сейчас нет. Если найдутся энтузиасты и сделают это, я потом могу доработать скрипт.
Ну, переписать все на шарпе действительно задача не на 5 минут, а вот добавить свойство в NCC-задачу можно очень быстро. Ща добавлю...
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, gloomy rocker, Вы писали:
VD>>Мы уже пользуемся услугами утилиты junction.exe. Наверно, имеет смысл вместо копирования создавать с ее помощью ссылки на файлы. GR>ИМХО разницы никакой. Но в принципе можно, когда скрипт будет отлажен и останется только причесать его.
Разница есть когда речь идет о девелоперских сборках. Этот файл переодически меняется и очень легко поменять не ту версию и забыть ее скопировать.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, gloomy rocker, Вы писали:
VD>>>Пути решения проблемы видятся следующие: VD>>>1. Использовать не задачу MSBuild, а задачу Exec в которой уже вызвать MSBuild.exe. Тогда он будет в отдельном процессе и проблема должна исчезнуть. VD>>>2. Подправить Nemerle.MSBuild.Tasks.dll так чтобы она могла получать путь к NCC.exe в качестве одного из свойств. VD>>>3. К едрене фене переписать Nemerle.MSBuild.Tasks.dll на C#, чтобы он больше не доставал. Он уже давно проблемы создает. GR>>Если нет возражений, я остановлюсь на первом варианте. Минус будет только один — цели, предупреждения и ошибки не будут подсвечиваться соответствующими цветами.
VD>Ну, вот как раз против бесцветия возражения есть. Привык я к цветам . Так что двай как для начала попробуем вариант 2. Там делов то на 5 минут.
Согласен. Отказываться от удобств не хочется.
VD>>>А вообще, изначально нужно было писать Nemerle.MSBuild.Tasks.dll на шарпе. Тогда всех этих проблем с зависимостями попросту не было бы. GR>>У меня, если честно, времени на это сейчас нет. Если найдутся энтузиасты и сделают это, я потом могу доработать скрипт.
VD>Ну, переписать все на шарпе действительно задача не на 5 минут, а вот добавить свойство в NCC-задачу можно очень быстро. Ща добавлю...
Давай. Попробую вариант с указанием, где брать NCC.exe
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, gloomy rocker, Вы писали:
GR>>А не затрется ли в таком случае значение переменной $(Nemerle), переданное извне? У меня сильное предчувствие, что затрется, и невозможно будет указать, каким компилятором собирать проект.
VD>Конечно затрется. Но, как я понимаю, только в рамках текущего проекта. VD>И в нем оно уже будет не интересно. Ведь ведется сборка конкретной конфигурации. Если кому-то оно нужно, то можно создать еще одно свойство, например NemerleOldValue и сохранить старое значение свойства в нем.
Не все так просто. Переменная $(Nemerle) используется в Nemerle.MSBuild.targets
и еще она потребуется для задания, где искать ncc.exe.
Это означает, что по крайней мере до импорта Nemerle.MSBuild.targets ее затирать нельзя.
GR>>Я имел в виду, что собрался компилятор. Дальше я пока не продвинулся. GR>>...До инсталлятора пока дело не дошло. См. выше.
VD>Ясно. Жаль. Ну, да может все же дойдут.
Инсталлятор уже собирается, но еще глючит.
GR>>Раньше сборка компилятора запускалась в отдельном процессе с помощью задачи Exec. При этом вывод на консоль цветом не выделялся, как выделялся бы при использовании задачи MSBuild. MSBuild у меня раньше не получалось использовать, т.к. с одними и теми же параметрами его можно выполнить только один раз.
VD>Понял, то есть цвет зависит от того используется ли задача MSBuild или Exec. VD>Ну, значит надо решать вопрос с Nemerle.MSBuild.Tasks.dll.
Именно так.
VD>>>Так что заливай изменения. В крайнем случае, будем разбираться по месту. GR>>Для этого нужен доступ к SVN. Мой gmail: gordynych@gmail.com
VD>Добавил.
Ок.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, gloomy rocker, Вы писали:
GR>>Полученный инсталлятор глючит.
VD>Это как раз то сообщение о том что "languageService == null"?
Оно самое.
Здравствуйте, gloomy rocker, Вы писали:
VD>>Конечно затрется. Но, как я понимаю, только в рамках текущего проекта. VD>>И в нем оно уже будет не интересно. Ведь ведется сборка конкретной конфигурации. Если кому-то оно нужно, то можно создать еще одно свойство, например NemerleOldValue и сохранить старое значение свойства в нем. GR>Не все так просто. Переменная $(Nemerle) используется в Nemerle.MSBuild.targets GR>
Здравствуйте, VladD2, Вы писали:
VD>Добавил. Свойство называется CompilerPath. Я уже установил его в значение из $(Nemerle) в Nemerle.MSBuild.targets: VD>