BuildInstallerRelease.cmd
От: _nn_ www.nemerleweb.com
Дата: 03.03.10 13:55
Оценка: 168 (3)
Добавил новый батник.
Просто запускаете и инсталлятор компилируется.

Необходимые программы:
  • Visual Studio 2008 + Visual Studio 2008 SDK 1.1
  • Вариант№2 C# Express, C++ Express и Visual Studio 2008 Shell (isolated mode) должнד тоже подойти.
  • http://reflector.red-gate.com/download.aspx положить только Reflector.exe в tools\reflector-addon\lib.
  • Wix 3.0
  • NUnit 2.5.2+

    Запустить VS2008 Command Prompt с правами администратора и запустить BuildInstallerRelease.cmd.
    Наслаждаться логами и взять инсталлятор в misc\packages\wix\bin\Release.

    Никаких изменений в сорсах не требуется (по крайней мере пока).
  • http://rsdn.nemerleweb.com
    http://nemerleweb.com
    Re: BuildInstallerRelease.cmd
    От: _nn_ www.nemerleweb.com
    Дата: 03.03.10 14:14
    Оценка:
    Здравствуйте, _nn_, Вы писали:

    Забыл что да нужны изменения

    В общем надо в файлах misc\packages\wix\src\*.wxs убрать требование PDB: <?if $(var.IncludePdb) ?>.
    Либо изменить на <?if $(var.IncludePdb) = "true" ?>

    Тут надо либо решить, что PDB нужны в релизе либо решить что они не нужны, и изменить проверку как надо.
    http://rsdn.nemerleweb.com
    http://nemerleweb.com
    Re[2]: BuildInstallerRelease.cmd
    От: _nn_ www.nemerleweb.com
    Дата: 03.03.10 14:21
    Оценка:
    Здравствуйте, _nn_, Вы писали:

    Решение нашлось:

    <?if $(var.IncludePdb) ?> => <?if $(var.IncludePdb) != false ?>

    Update + Build
    http://rsdn.nemerleweb.com
    http://nemerleweb.com
    Re[2]: BuildInstallerRelease.cmd
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 03.03.10 17:16
    Оценка:
    Здравствуйте, _nn_, Вы писали:

    __>В общем надо в файлах misc\packages\wix\src\*.wxs убрать требование PDB: <?if $(var.IncludePdb) ?>.

    __>Либо изменить на <?if $(var.IncludePdb) = "true" ?>

    __>Тут надо либо решить, что PDB нужны в релизе либо решить что они не нужны, и изменить проверку как надо.


    PDB-шки конечно хорошо бы иметь. Это позволит упростить отладку макросов.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[3]: BuildInstallerRelease.cmd
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 03.03.10 17:17
    Оценка:
    Здравствуйте, _nn_, Вы писали:

    __>Решение нашлось:


    __> <?if $(var.IncludePdb) ?> => <?if $(var.IncludePdb) != false ?>


    И какой результат?
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re: BuildInstallerRelease.cmd
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 03.03.10 21:23
    Оценка:
    Здравствуйте, _nn_, Вы писали:

    __>Добавил новый батник.


    А зачем копировать boot в "%ProgramFiles%\Nemerle ?

    В boot-е бинарники более старых версий. А при сборке проектов самого компилятора можно указать, чтобы использовался компилятор из boot-а.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[2]: BuildInstallerRelease.cmd
    От: _nn_ www.nemerleweb.com
    Дата: 04.03.10 09:28
    Оценка:
    Здравствуйте, VladD2, Вы писали:

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


    __>>Добавил новый батник.


    VD>А зачем копировать boot в "%ProgramFiles%\Nemerle ?


    VD>В boot-е бинарники более старых версий. А при сборке проектов самого компилятора можно указать, чтобы использовался компилятор из boot-а.


    Если не сложно, подправь.
    Я не знаю как это делается
    http://rsdn.nemerleweb.com
    http://nemerleweb.com
    Re[3]: BuildInstallerRelease.cmd
    От: _nn_ www.nemerleweb.com
    Дата: 04.03.10 09:31
    Оценка:
    Здравствуйте, VladD2, Вы писали:

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


    __>>В общем надо в файлах misc\packages\wix\src\*.wxs убрать требование PDB: <?if $(var.IncludePdb) ?>.

    __>>Либо изменить на <?if $(var.IncludePdb) = "true" ?>

    __>>Тут надо либо решить, что PDB нужны в релизе либо решить что они не нужны, и изменить проверку как надо.


    VD>PDB-шки конечно хорошо бы иметь. Это позволит упростить отладку макросов.

    Согласен.

    Я в MSBuild-е не силен, вот и не добавил.
    Кто может, исправьте
    http://rsdn.nemerleweb.com
    http://nemerleweb.com
    Re[3]: BuildInstallerRelease.cmd
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 04.03.10 17:59
    Оценка:
    Здравствуйте, _nn_, Вы писали:

    VD>>В boot-е бинарники более старых версий. А при сборке проектов самого компилятора можно указать, чтобы использовался компилятор из boot-а.


    __>Если не сложно, подправь.

    __>Я не знаю как это делается

    Чтобы править, нужно тестировать (и вникать в проблематику). Я загружен другими делами, так что лучше правь ты.

    Что касается boot-а, то как я понимаю, особо правит ничего не надо. Проекты компилятора включают импорт Compiler.MSBuild.targets в котором пути к компилятору и Nemerle.MSBuild.Tasks.dll прописаны на boot.

    Для проекты интеграции используют импорт стандартного Nemerle.MSBuild.targets где для вычисления пути к каталогу компилятора используется переменная среды окружения "Nemerle". Ее можно заменить в самом начале компиляции, так чтобы она уазывала на bin\Release компилятора.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re: BuildInstallerRelease.cmd
    От: seregaa Ниоткуда http://blogtani.ru
    Дата: 05.03.10 07:47
    Оценка:
    Здравствуйте, _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.


    вот думаю — то ли я в коде накосячил, то ли с окружением/настройками что то не так?
    Мобильная версия сайта RSDN — http://rsdn.org/forum/rsdn/6938747
    Автор: sergeya
    Дата: 19.10.17
    Re[2]: BuildInstallerRelease.cmd
    От: seregaa Ниоткуда http://blogtani.ru
    Дата: 05.03.10 11:09
    Оценка:
    Здравствуйте, 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"
    и сборка заработала.
    Мобильная версия сайта RSDN — http://rsdn.org/forum/rsdn/6938747
    Автор: sergeya
    Дата: 19.10.17
    Re: BuildInstallerRelease.cmd
    От: kochetkov.vladimir Россия https://kochetkov.github.io
    Дата: 08.03.10 21:09
    Оценка:
    Здравствуйте, _nn_, Вы писали:

    Народ, помогите понять, у всех сборка последней ревизии 8751 сломалась и выдает кучу ошибок на parser.n, или это я у себя с окружением намудрил?

    ... << RSDN@Home 1.2.0 alpha 4 rev. 1437>>

    [Интервью] .NET Security — это просто
    Автор: kochetkov.vladimir
    Дата: 07.11.17
    Re[2]: BuildInstallerRelease.cmd
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 08.03.10 23:09
    Оценка:
    Здравствуйте, kochetkov.vladimir, Вы писали:

    KV>Народ, помогите понять, у всех сборка последней ревизии 8751 сломалась и выдает кучу ошибок на parser.n, или это я у себя с окружением намудрил?


    Похоже я что-то напортачил. Только не в parser.n, а в PreParser.n.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[2]: BuildInstallerRelease.cmd
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 09.03.10 00:00
    Оценка:
    Здравствуйте, kochetkov.vladimir, Вы писали:

    KV>Народ, помогите понять, у всех сборка последней ревизии 8751 сломалась и выдает кучу ошибок на parser.n, или это я у себя с окружением намудрил?


    Похоже это не я, а emperon в ревизии 8566.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re: BuildInstallerRelease.cmd
    От: _nn_ www.nemerleweb.com
    Дата: 09.03.10 08:29
    Оценка:
    Здравствуйте, _nn_, Вы писали:

    Обновление.
    Теперь нет необходимости копировать в %ProgramFiles%.
    http://rsdn.nemerleweb.com
    http://nemerleweb.com
    Re[2]: BuildInstallerRelease.cmd
    От: _nn_ www.nemerleweb.com
    Дата: 09.03.10 10:53
    Оценка: +1
    Здравствуйте, kochetkov.vladimir, Вы писали:

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


    KV>Народ, помогите понять, у всех сборка последней ревизии 8751 сломалась и выдает кучу ошибок на parser.n, или это я у себя с окружением намудрил?


    KV>


    Уже исправлено, у меня собирается.
    http://rsdn.nemerleweb.com
    http://nemerleweb.com
    Re: BuildInstallerRelease.cmd
    От: kochetkov.vladimir Россия https://kochetkov.github.io
    Дата: 09.03.10 21:51
    Оценка: 7 (1)
    Здравствуйте, _nn_, Вы писали:

    не против, если я заменю 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 ревизию, из которой собирается инсталлер
    — запустить, наконец-таки, автосборку на каждый коммит и автовыкладывание обоих версий инсталлера на сайт проекта.

    ок?
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1437>>

    [Интервью] .NET Security — это просто
    Автор: kochetkov.vladimir
    Дата: 07.11.17
    Re[2]: BuildInstallerRelease.cmd
    От: gloomy rocker Россия  
    Дата: 09.03.10 23:13
    Оценка: 18 (1)
    Здравствуйте, kochetkov.vladimir, Вы писали:

    Привет от автора NemerleAll.nproj

    Не все так просто, как может показаться на первый взгляд.
    Некоторые проекты в исходниках 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 и т.д. следующим образм:

    Исходный файл ncc.nproj
    <Project DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
      <PropertyGroup>
        <Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
        <Platform Condition=" '$(Platform)' == '' ">AnyCPU</Platform>
        ...
      </PropertyGroup>
      ...
      <Import Project="tools\msbuild-task\Compiler.MSBuild.targets" /> 
      ...
    </Project>


    Измененный ncc.nproj
    <Project DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
      <PropertyGroup>
        <Nemerle Condition=" '$(Nemerle)' == '' ">$(MSBuildProjectDirectory)\boot</Nemerle>
        <Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
        <Platform Condition=" '$(Platform)' == '' ">AnyCPU</Platform>
        ...
      </PropertyGroup>
      ...
      <Import Project="$(Nemerle)\Nemerle.MSBuild.targets" /> 
      ...
    </Project>


    В результате, как я и ожидал, все прекрасно скомпилировалось, но пришлось докручивать NemerleAll.nproj

    Теперь немного о том, чего хочется от NemerleAll.nproj и что я уже сделал.
    Сейчас у меня компиляция идет в 4 стадии и результат каждой стадии компиляции лежит отдельно в папке bin\$(Configuration)\$(Stage)
    Stage1 компилируется компилятором из boot
    Stage2 — компилятором из bin\$(Configuration)\Stage1
    и т.д.

    Кроме всего прочего решилась проблема с цветным выводом сообщений на консоль при компиляции. Это стало возможным благодаря тому,
    что одна и та же цель собирается с разными параметрами.

    Собственно на этом я пока остановился. Думаю денек-другой, и смогу довести этот MSBuild-ный скрипт до ума так, чтобы не использовать $(ProgramFiles).
    Но для того нужна отмашка старших разработчиков. Может я не до конца понимаю смысл наличия двух разных targets файлов.
    Скука — двигатель прогресса.
    Re[3]: BuildInstallerRelease.cmd
    От: gloomy rocker Россия  
    Дата: 09.03.10 23:17
    Оценка:
    Здравствуйте, gloomy rocker, Вы писали:

    Забыл написать, что Nemerle.MSBuild.targets приходится перед началом очередной фазы компиляции копировать в папку, на которую указывает переменная $(Nemerle). В том числе и в boot.
    Скука — двигатель прогресса.
    Re[3]: BuildInstallerRelease.cmd
    От: _nn_ www.nemerleweb.com
    Дата: 10.03.10 08:44
    Оценка:
    Здравствуйте, 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 .

    Все должно работать нормально.
    Linq.nproj:
    <Project DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
      <PropertyGroup>
        <NoStdLib>true</NoStdLib>
        <Nemerle Condition=" '$(Nemerle)' == '' ">$(ProgramFiles)\Nemerle</Nemerle>
        <Name>Linq</Name>
        <TargetPlatform>v2</TargetPlatform>
      </PropertyGroup>


    Tests.nproj
    <Project DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
      <PropertyGroup>
        <NoStdLib>true</NoStdLib>
        <Nemerle Condition=" '$(Nemerle)' == '' ">$(ProgramFiles)\Nemerle</Nemerle>
      </PropertyGroup>


    Только если $(Nemerle) не установлен берется $(ProgramFiles).
    А вообще конечно хорошо убрать $(ProgramFiles) как директорию по умолчанию.
    Может проще требовать, чтобы переменная Nemerle была установлена или там NRoot или другая ?
    http://rsdn.nemerleweb.com
    http://nemerleweb.com
    Re[2]: BuildInstallerRelease.cmd
    От: _nn_ www.nemerleweb.com
    Дата: 10.03.10 08:56
    Оценка: 9 (1) +1
    Здравствуйте, 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


    Обновление версии это хорошо

    P.S.
    Жаль нет [batch]
    http://rsdn.nemerleweb.com
    http://nemerleweb.com
    Re[3]: BuildInstallerRelease.cmd
    От: kochetkov.vladimir Россия https://kochetkov.github.io
    Дата: 10.03.10 09:08
    Оценка: :)
    Здравствуйте, _nn_, Вы писали:

    __>Здравствуйте, kochetkov.vladimir, Вы писали:


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


    KV>>не против, если я заменю BuildInstallerRelease.cmd и BuildInstallerFull.cmd на один

    __>Только за

    Ок, добавлю проверки prereq и залью в проект

    __>Батник можно немного улучшить


    __>
    __>if "%~1"=="" (
    __>    set Type=Release    
    __>) else (
    __>    set Type=%1
    __>)
    __>
    __>


    А так хотелось хоть куда-нибудь впихнуть goto... (http://www.rsdn.ru/Forum/Info/FAQ.HUMOR.gotomustdie.aspx
    Автор: IT
    Дата: 08.06.02
    )
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1437>>

    [Интервью] .NET Security — это просто
    Автор: kochetkov.vladimir
    Дата: 07.11.17
    Re[3]: BuildInstallerRelease.cmd
    От: gloomy rocker Россия  
    Дата: 10.03.10 09:18
    Оценка:
    Здравствуйте, 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. Предложите свой вариант.
    Скука — двигатель прогресса.
    Re[4]: BuildInstallerRelease.cmd
    От: gloomy rocker Россия  
    Дата: 10.03.10 09:37
    Оценка: +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 и т.д. нужно делать отдельной целью.
    Скука — двигатель прогресса.
    Re[4]: BuildInstallerRelease.cmd
    От: _nn_ www.nemerleweb.com
    Дата: 10.03.10 09:46
    Оценка:
    Здравствуйте, kochetkov.vladimir, Вы писали:

    KV>Ок, добавлю проверки prereq и залью в проект


    Я вот как-то подумал, может стоит добавить wget.exe (Ну или VBScript + WinHTTP, или что-то другое чтобы под линуксом собрать можно было ) в проект и если не найдена нужная программа, то ее можно предложить скачать и установить.
    Это я про VS SDK, Wix, NUnit, Reflector.

    Для небольших файлов можно, наверное, добавить сам msi в проект и запускать его если не установлен.
    А для больших файлов, или с которыми может быть проблема с лицензией, предлагать скачать.
    http://rsdn.nemerleweb.com
    http://nemerleweb.com
    Re[4]: BuildInstallerRelease.cmd
    От: gloomy rocker Россия  
    Дата: 10.03.10 10:35
    Оценка:
    Здравствуйте, 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, но переусложнять тоже не хочется.
    Скука — двигатель прогресса.
    Re[3]: BuildInstallerRelease.cmd
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 10.03.10 15:57
    Оценка:
    Здравствуйте, gloomy rocker, Вы писали:

    GR>Не все так просто, как может показаться на первый взгляд.

    GR>Некоторые проекты в исходниках Nemerle компилируются только если в $(ProgramFiles)\Nemerle лежат сборки компилятора.
    GR>Так ведет себя, например проект Linq.nproj.

    Это не совсем так. Linq.nproj — это стандартный проект интеграции и то где лежат бинарники определяется (в нем) переменной среды окружения "Nemerle". Если она не задана, то в нее подставляется путь "$(ProgramFiles)\Nemerle". Если задана, то используется заданный путь. Вот начала этого проекта:
    <Project DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
      <PropertyGroup>
        <NoStdLib>true</NoStdLib>
        <Nemerle Condition=" '$(Nemerle)' == '' ">$(ProgramFiles)\Nemerle</Nemerle>
        <Name>Linq</Name>
        <TargetPlatform>v2</TargetPlatform>
      </PropertyGroup>


    Так что перед компиляцией этого проекта достаточно задать путь к бинарникам в переменную "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>
    GR>    <Nemerle Condition=" '$(Nemerle)' == '' ">$(MSBuildProjectDirectory)\boot</Nemerle>
    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 файлов.

    С таргетами ты совершенно прав.

    Так что заливай изменения. В крайнем случае, будем разбираться по месту.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[4]: BuildInstallerRelease.cmd
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 10.03.10 16:18
    Оценка:
    Здравствуйте, gloomy rocker, Вы писали:

    GR>Забыл написать, что Nemerle.MSBuild.targets приходится перед началом очередной фазы компиляции копировать в папку, на которую указывает переменная $(Nemerle). В том числе и в boot.


    Мы уже пользуемся услугами утилиты junction.exe. Наверно, имеет смысл вместо копирования создавать с ее помощью ссылки на файлы.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[4]: BuildInstallerRelease.cmd
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 10.03.10 16:21
    Оценка:
    Здравствуйте, _nn_, Вы писали:

    __>Только если $(Nemerle) не установлен берется $(ProgramFiles).

    __>А вообще конечно хорошо убрать $(ProgramFiles) как директорию по умолчанию.
    __>Может проще требовать, чтобы переменная Nemerle была установлена или там NRoot или другая ?

    Вот этого не надо. Явно заданная переменная на машине будет приводить к проблемам. Ее должен задавать исключительно инсталлятор и только при условии, что местоположение компилятора не совпадает с "$(ProgramFiles)\Nemerle".
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[5]: BuildInstallerRelease.cmd
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 10.03.10 16:23
    Оценка:
    Здравствуйте, gloomy rocker, Вы писали:

    GR>Я думаю, что скрипт NemerleAll.nproj нужно доделать таким образом, чтобы можно было на каждой стадии задавать, где взять boot-компилятор, и куда положить новый компилятор. Это делается путем задания двух свойств: Nemerle и OutDir.


    +1

    GR>А установку в ProgramFiles, регистрацию в GAC, NGen и т.д. нужно делать отдельной целью.


    А вот в GAC лучше не надо. Только если совсем отдельной целью которая по умолчанию не будет вызваться.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[3]: BuildInstallerRelease.cmd
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 10.03.10 16:30
    Оценка: 1 (1)
    Здравствуйте, _nn_, Вы писали:

    __>
    __>set Nemerle=%~dp0\boot
    __>


    От такого решения могут быть проблемы. Дело в том, что проекты интеграции и Linq-а должны компилироваться исключительно бинарниками собранными из исходника. В boot-е может быть версия которая не подходит для их сборки. Так что компиляция попросту может не пройти.

    Переменную Nemerle нужно задавать только после того как будут скомпилированы сборки компилятора и на ту директорию в которую они будут помещены в процессе компиляции.
    Соответственно это нужно делать из проекта, а не из батника.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[4]: BuildInstallerRelease.cmd
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 10.03.10 17:02
    Оценка:
    Здравствуйте, 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 на шарпе. Тогда всех этих проблем с зависимостями попросту не было бы.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[5]: BuildInstallerRelease.cmd
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 10.03.10 17:19
    Оценка:
    Здравствуйте, 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.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[4]: BuildInstallerRelease.cmd
    От: gloomy rocker Россия  
    Дата: 10.03.10 21:36
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    GR>>Я попробовал изменить файлы проектов ncc.nproj, nemerle.nproj и т.д. следующим образм:

    GR>>...Измененный ncc.nproj
    GR>>
    GR>>    <Nemerle Condition=" '$(Nemerle)' == '' ">$(MSBuildProjectDirectory)\boot</Nemerle>
    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
    Скука — двигатель прогресса.
    Re[5]: BuildInstallerRelease.cmd
    От: gloomy rocker Россия  
    Дата: 10.03.10 21:46
    Оценка:
    Здравствуйте, 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 на шарпе. Тогда всех этих проблем с зависимостями попросту не было бы.

    У меня, если честно, времени на это сейчас нет. Если найдутся энтузиасты и сделают это, я потом могу доработать скрипт.
    Скука — двигатель прогресса.
    Re[6]: BuildInstallerRelease.cmd
    От: gloomy rocker Россия  
    Дата: 10.03.10 21:49
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    VD>А вот в GAC лучше не надо. Только если совсем отдельной целью которая по умолчанию не будет вызваться.

    GAC я по инерции упомянул. Сейчас в скрипте вроде и нет такой задачи.
    Скука — двигатель прогресса.
    Re[5]: BuildInstallerRelease.cmd
    От: gloomy rocker Россия  
    Дата: 10.03.10 21:51
    Оценка:
    Здравствуйте, VladD2, Вы писали:

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


    GR>>Забыл написать, что Nemerle.MSBuild.targets приходится перед началом очередной фазы компиляции копировать в папку, на которую указывает переменная $(Nemerle). В том числе и в boot.


    VD>Мы уже пользуемся услугами утилиты junction.exe. Наверно, имеет смысл вместо копирования создавать с ее помощью ссылки на файлы.

    ИМХО разницы никакой. Но в принципе можно, когда скрипт будет отлажен и останется только причесать его.
    Скука — двигатель прогресса.
    Re[4]: BuildInstallerRelease.cmd
    От: gloomy rocker Россия  
    Дата: 11.03.10 00:41
    Оценка: 136 (2)
    Здравствуйте, VladD2, Вы писали:

    VD>А полученный инсталлятор не глючит? А то мы тут пытаемся на сервере процесс компиляции запустить и в результате получаются битые инсталляторы. При попытке создать проект выдается сообщение что languageService == null.

    Довел скрипт до состояния, когда можно скомпилировать инсталлятор. Полученный инсталлятор глючит.
    Собирать сейчас можно двумя способами — быстро и очень медленно.
    Быстрый способ — одна стадия компиляции компилятора, нет вылидации и тесты не запускаются
    Очень медленный — 4 фазы компиляции компилятора, валидация сборок, запуск тестов

    Инсталлятор проверил пока только в случае быстрой сборки.
    Скука — двигатель прогресса.
    Re[5]: BuildInstallerRelease.cmd
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 11.03.10 11:09
    Оценка:
    Здравствуйте, 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

    Добавил.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[6]: BuildInstallerRelease.cmd
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 11.03.10 11:11
    Оценка:
    Здравствуйте, 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-задачу можно очень быстро. Ща добавлю...
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[6]: BuildInstallerRelease.cmd
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 11.03.10 11:13
    Оценка:
    Здравствуйте, gloomy rocker, Вы писали:

    VD>>Мы уже пользуемся услугами утилиты junction.exe. Наверно, имеет смысл вместо копирования создавать с ее помощью ссылки на файлы.

    GR>ИМХО разницы никакой. Но в принципе можно, когда скрипт будет отлажен и останется только причесать его.

    Разница есть когда речь идет о девелоперских сборках. Этот файл переодически меняется и очень легко поменять не ту версию и забыть ее скопировать.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[5]: BuildInstallerRelease.cmd
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 11.03.10 11:14
    Оценка:
    Здравствуйте, gloomy rocker, Вы писали:

    GR>Полученный инсталлятор глючит.


    Это как раз то сообщение о том что "languageService == null"?
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[7]: BuildInstallerRelease.cmd
    От: gloomy rocker Россия  
    Дата: 11.03.10 11:56
    Оценка:
    Здравствуйте, 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
    Скука — двигатель прогресса.
    Re[6]: BuildInstallerRelease.cmd
    От: gloomy rocker Россия  
    Дата: 11.03.10 12:06
    Оценка:
    Здравствуйте, VladD2, Вы писали:

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


    GR>>А не затрется ли в таком случае значение переменной $(Nemerle), переданное извне? У меня сильное предчувствие, что затрется, и невозможно будет указать, каким компилятором собирать проект.


    VD>Конечно затрется. Но, как я понимаю, только в рамках текущего проекта.

    VD>И в нем оно уже будет не интересно. Ведь ведется сборка конкретной конфигурации. Если кому-то оно нужно, то можно создать еще одно свойство, например NemerleOldValue и сохранить старое значение свойства в нем.
    Не все так просто. Переменная $(Nemerle) используется в Nemerle.MSBuild.targets
        <UsingTask
          TaskName="Nemerle.Tools.MSBuildTask.Ncc"
          AssemblyFile="$(Nemerle)\Nemerle.MSBuild.Tasks.dll"/>

    и еще она потребуется для задания, где искать 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>Добавил.

    Ок.
    Скука — двигатель прогресса.
    Re[6]: BuildInstallerRelease.cmd
    От: gloomy rocker Россия  
    Дата: 11.03.10 12:07
    Оценка:
    Здравствуйте, VladD2, Вы писали:

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


    GR>>Полученный инсталлятор глючит.


    VD>Это как раз то сообщение о том что "languageService == null"?

    Оно самое.
    Скука — двигатель прогресса.
    Re[7]: BuildInstallerRelease.cmd
    От: seregaa Ниоткуда http://blogtani.ru
    Дата: 11.03.10 12:15
    Оценка: 70 (2)
    Здравствуйте, gloomy rocker, Вы писали:

    GR>>>Полученный инсталлятор глючит.


    VD>>Это как раз то сообщение о том что "languageService == null"?

    GR>Оно самое.

    У меня такое сообщение появлялось при отсутствии в "\Program Files\Nemerle" файла WpfHint.dll
    Мобильная версия сайта RSDN — http://rsdn.org/forum/rsdn/6938747
    Автор: sergeya
    Дата: 19.10.17
    Re[8]: BuildInstallerRelease.cmd
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 11.03.10 12:42
    Оценка:
    Здравствуйте, gloomy rocker, Вы писали:

    GR>Давай. Попробую вариант с указанием, где брать NCC.exe


    Добавил. Свойство называется CompilerPath. Я уже установил его в значение из $(Nemerle) в Nemerle.MSBuild.targets:
            <Ncc
                  ...
                  CompilerPath="$(Nemerle)"


    Так что по идее должно заработать как надо.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[7]: BuildInstallerRelease.cmd
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 11.03.10 12:45
    Оценка:
    Здравствуйте, gloomy rocker, Вы писали:

    VD>>Конечно затрется. Но, как я понимаю, только в рамках текущего проекта.

    VD>>И в нем оно уже будет не интересно. Ведь ведется сборка конкретной конфигурации. Если кому-то оно нужно, то можно создать еще одно свойство, например NemerleOldValue и сохранить старое значение свойства в нем.
    GR>Не все так просто. Переменная $(Nemerle) используется в Nemerle.MSBuild.targets
    GR>
    GR>    <UsingTask
    GR>      TaskName="Nemerle.Tools.MSBuildTask.Ncc"
    GR>      AssemblyFile="$(Nemerle)\Nemerle.MSBuild.Tasks.dll"/>
    GR>

    GR>и еще она потребуется для задания, где искать ncc.exe.
    GR>Это означает, что по крайней мере до импорта Nemerle.MSBuild.targets ее затирать нельзя.

    Дык, именно для этих целей ты ее и будешь затирать. Так что проблем быть не должно. Свойство я уже добавил
    Автор: VladD2
    Дата: 11.03.10
    . Так что можешь пробовать.

    GR>Инсталлятор уже собирается, но еще глючит.


    А что там не так?
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[8]: BuildInstallerRelease.cmd
    От: kochetkov.vladimir Россия https://kochetkov.github.io
    Дата: 11.03.10 14:42
    Оценка:
    Здравствуйте, seregaa, Вы писали:

    S>У меня такое сообщение появлялось при отсутствии в "\Program Files\Nemerle" файла WpfHint.dll


    Как оказалось, это оно и было, т.к. WpfHint отсутствовал в проекте инсталлера. fixed.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1437>>

    [Интервью] .NET Security — это просто
    Автор: kochetkov.vladimir
    Дата: 07.11.17
    Re[9]: BuildInstallerRelease.cmd
    От: gloomy rocker Россия  
    Дата: 11.03.10 14:49
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    VD>Добавил. Свойство называется CompilerPath. Я уже установил его в значение из $(Nemerle) в Nemerle.MSBuild.targets:

    VD>
    VD>        <Ncc
    VD>              ...
    VD>              CompilerPath="$(Nemerle)"
    VD>


    VD>Так что по идее должно заработать как надо.

    После работы попробую.
    Скука — двигатель прогресса.
    Re[8]: BuildInstallerRelease.cmd
    От: gloomy rocker Россия  
    Дата: 11.03.10 14:52
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    GR>>Инсталлятор уже собирается, но еще глючит.


    VD>А что там не так?

    Да все то же "languageService == null"
    Скука — двигатель прогресса.
     
    Подождите ...
    Wait...
    Пока на собственное сообщение не было ответов, его можно удалить.