Запустить VS2008 Command Prompt с правами администратора и запустить BuildInstallerRelease.cmd.
Наслаждаться логами и взять инсталлятор в misc\packages\wix\bin\Release.
Никаких изменений в сорсах не требуется (по крайней мере пока).
В общем надо в файлах 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.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Здравствуйте, _nn_, Вы писали:
KV>Народ, помогите понять, у всех сборка последней ревизии 8751 сломалась и выдает кучу ошибок на parser.n, или это я у себя с окружением намудрил?
KV>
не против, если я заменю 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 ревизию, из которой собирается инсталлер
— запустить, наконец-таки, автосборку на каждый коммит и автовыкладывание обоих версий инсталлера на сайт проекта.
Не все так просто, как может показаться на первый взгляд.
Некоторые проекты в исходниках 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 файлов.
Забыл написать, что 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 или другая ?
