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

VD>А что 2012-я студия стала сильно шустрее?

Субъективно да.

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

_>>Все вопросы отменяются — с git разобрался, интеграцию с 2012 RC запустил. Оказалось там правок всего ничего, и завелось влёт.
VD>Что за изменения?

Для того, чтобы наш vsix можно было закрутить под VS2012 достаточно в его манифесте указать, что он поддерживает эту версию. Даже пересобирать не нужно. Однако, в этом случае, при работе с более-менее не учебными проектами, начинаются глюки студии, которые не воспроизводятся в 2010 с тем же vsix'ом. Поэтому, и Nemerle и vsix нужно собирать под 4.5 и 2012 SDK, тогда все ок. Что приводит нас к необходимости заводить 3ий инсталлятор

Но если делать отдельным инсталятором, то поддержку FW4.5/VS2012 мы можем обеспечить прямо сейчас, причем настолько же стабильную, насколько она является таковой в VS2010.

в общем краткая пред история
Установил Windows 8 Release Preview, Visual Studio 2012, но перед этим решил заняться Nemerle.
И вот заодно думаю попробовать интегрировать Nemerle в Visual Studio 2012 RC, может кто ни будь занимается подобным?

Основываюсь разумеется на интеграции VS2010 и руководствуясь содержимым справки MSDN.

но пока вопрос не об этом, хотелось бы уточнить куда лучше писать о багах, которые я нахожу по пути?

1) NemerleAll.nproj

312c312
<     <Exec Command="$(Junction) &quot;$(ProgramW6432)\Nemerle&quot; &quot;$(ProgramFiles(x86))\Nemerle&quot;" Condition="'$(ProgramW6432)' != '' " IgnoreExitCode="true" />
---
>     <Exec Command="$(Junction) &quot;$(ProgramW6432)\Nemerle&quot; &quot;$(ProgramFiles)\Nemerle&quot;" Condition="'$(ProgramW6432)' != '' " IgnoreExitCode="true" />

2) в проекте по интеграции VS2010 в "Nemerle.VisualStudio\Resources.resx" понапихали строк с цифрами в качестве имен, но от этого ведь коробит ResXFileCodeGenerator, для таких ресурсов правильней создать отдельный ресурсный файл и отключить для него ResXFileCodeGenerator

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

VD>Идея хорошая. Если есть желание можешь заняться ее реализацией.
я то займусь, тока пока ни чего не обещаю

VD>MsBuild рассматривает переменные окружения как псевдо-свойства. Так что в системах где объявлена переменная ProgramFiles(x86) значение будет и джанкшон должен вести именно туда.
ты не понял, как тебе еще объяснить то
ну не бывает переменных
$(ProgramFiles(x86))
нельзя в имени переменной использовать скобки
есть две переменные
$(ProgramFiles)
и
$(ProgramW6432)
а у вас в NemerleAll.nproj
в 312 строке используется $(ProgramFiles(x86))
в результате чего у меня создался junction в никуда

VD>Ну, это и 2008-я выдавала. Просто не обращай внимания. На работоспособности это никак не отражается.
дак а в чем сложность создать отдельный ресурсный файл
visual studio при создании нового проекта как раз создает такой,
но это все мелочи я понимаю )

VD>Я уже деталей не помню, но вроде бы это были уши MPF-а. Собственно, работает и фиг бы с ним. Все равно этот файл правится раз в год по обещанию.
да, да, это именно оно

тут еще один момент забыл затронуть
для того что бы установить nemerle из исходников в program files
необходимо запускать батники под администратором,
но когда запускаешь под администратором, текущая папка меняется на c:\Windows\System32
и соответственно ни чего не запускается,
можно конечно ни чего не делать, но ведь есть простейшие решения
почему бы их не использовать
основываются они на том факте, что текущую директорию в батнике можно получить из переменной %0, если точнее то %~dp0
ну и соответственно два варианта
1) менять текущую директорию, добавив в начало бат файла примерно вот такой код

@setlocal enableextensions
@pushd "%~dp0

и в конец

@popd

2) использовать абсолютные пути относительно какой нить переменной %NEMERLE_ROOT%
которую установить в

@set NEMERLE_ROOT = %~dp0

правда текущий каталог будет по прежнему c:\Windows\System32
не знаю не вызовет ли это каких либо проблем, скорее всего нет

и да, экранируйте в батнике все вызовы команд символом @
он блокирует вывод самой команды, либо выполняйте в самом начале @echo off
получается более красивое окно,
так же еще можно установить заголовок для окна

и PS:
мне почему то кажется, что не совсем кошерно через батник вида Build*.bat устанавливать что либо в Program Files, быть может создать отдельный батник, назвать его Install который будет выполнять target install
так же нужно бы написать target uninstall
и target clean
а то как то все не кошерно

ЗЫ: могу заняться
допустим все эти нюансы c запуском под админом решит вот такой вот батничек

:: BuildLib.cmd
@echo off
setlocal enableextensions
call:%1
goto:eof

:start
title Build Nemerle
set BUILD_DIR=%~dp0
set MSBUILD="%SystemRoot%\Microsoft.NET\Framework\v4.0.30319\msbuild.exe"
pushd %BUILD_DIR%
goto:eof

:stop
pause
popd
goto:eof

и соответственно

:: BuildQuick-ncc-4.cmd
@call %~dp0BuildLib start
@%MSBuild% %BUILD_DIR%NemerleAll.nproj /target:DevBuildQuickNccOnly /p:Configuration=Release /verbosity:n /p:NTargetName=Build /tv:4.0 /p:TargetFrameworkVersion=v4.0$
@call %~dp0BuildLib stop

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

Лучше всего писать тут: https://github.com/rsdn/nemerle/

А еще лучше, если есть возможность, подготовить пул реквест https://github.com/rsdn/nemerle/pulls.

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

NN>но пока вопрос не об этом, хотелось бы уточнить куда лучше писать о багах, которые я нахожу по пути?

Пробовали еще в бэта. Даже работало после доработки напильником. Но там с фрэймворком все не очень красиво у МС было и решили отложить до релиза.

Релиз уже есть?

NN>1) NemerleAll.nproj
NN>

NN>312c312
NN><     <Exec Command="$(Junction) &quot;$(ProgramW6432)\Nemerle&quot; &quot;$(ProgramFiles(x86))\Nemerle&quot;" Condition="'$(ProgramW6432)' != '' " IgnoreExitCode="true" />
NN>---
>>     <Exec Command="$(Junction) &quot;$(ProgramW6432)\Nemerle&quot; &quot;$(ProgramFiles)\Nemerle&quot;" Condition="'$(ProgramW6432)' != '' " IgnoreExitCode="true" />
NN>

И что тут не так?

NN>2) в проекте по интеграции VS2010 в "Nemerle.VisualStudio\Resources.resx" понапихали строк с цифрами в качестве имен, но от этого ведь коробит ResXFileCodeGenerator, для таких ресурсов правильней создать отдельный ресурсный файл и отключить для него ResXFileCodeGenerator

Что значит коробит?

Это работает уже черт знает сколько времени. Числа используются в MPF. Мы это унаследовали от проекта интеграции для Питона (которая была за основу немерловой взята).

Здравствуйте, Аноним, Вы писали:

А>А еще лучше, если есть возможность, подготовить пул реквест https://github.com/rsdn/nemerle/pulls.

Для начала надо понять суть претензий. Я пока что особо проблем не вижу.

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

VD>Релиз уже есть?
Релиз кандидат...

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

VD>И что тут не так?

нету в MsBuild переменной $(ProgramFiles(x86) есть $(ProgramFiles
вы для x64 создаете не правильный junction, но оно скорее всего пока работает без нареканий, так как ссылаетесь вы скорее всего не зависимо от архитектуры на $(ProgramFiles)

VD>Что значит коробит?
VS2012 выдает кучу варнингов, и в качестве решения Microsoft предлагает создать отдельный проект и отключить для него ResXFileCodeGenerator

VD>Это работает уже черт знает сколько времени. Числа используются в MPF. Мы это унаследовали от проекта интеграции для Питона (которая была за основу немерловой взята).
да у MS какая то странная архитектура, без чисел не обойтись, а в качестве ID ресурса предлагается использовать строки

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

NN>я заранее хочу оговориться, я просто решил поковырять, что там да как,
NN>на данный момент я и сам понял, что большая часть проекта была взята из примера по интеграции IronPython, я бы все таки попробовал сделать, кое какое рефакторинг, что бы добиться модульности проекта

Идея хорошая. Если есть желание можешь заняться ее реализацией.

NN>нету в MsBuild переменной $(ProgramFiles(x86) есть $(ProgramFiles
NN>вы для x64 создаете не правильный junction, но оно скорее всего пока работает без нареканий, так как ссылаетесь вы скорее всего не зависимо от архитектуры на $(ProgramFiles)

MsBuild рассматривает переменные окружения как псевдо-свойства. Так что в системах где объявлена переменная ProgramFiles(x86) значение будет и джанкшон должен вести именно туда.

VD>>Что значит коробит?
NN>VS2012 выдает кучу варнингов, и в качестве решения Microsoft предлагает создать отдельный проект и отключить для него ResXFileCodeGenerator

Ну, это и 2008-я выдавала. Просто не обращай внимания. На работоспособности это никак не отражается.

NN>да у MS какая то странная архитектура, без чисел не обойтись, а в качестве ID ресурса предлагается использовать строки

Я уже деталей не помню, но вроде бы это были уши MPF-а. Собственно, работает и фиг бы с ним. Все равно этот файл правится раз в год по обещанию.

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

NN>ну не бывает переменных
NN>$(ProgramFiles(x86))
+1. Более того их "экранирование" тоже не работает.
Для MSBuild 4 есть MSBuildProgramFiles32, которая всегда указывает в x86.

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

NN>ну не бывает переменных
NN>$(ProgramFiles(x86))
NN>нельзя в имени переменной использовать скобки

Так и надо было говорить. Я, грешным делом, думал, что МСБилду по фиг что там в именах.

NN>есть две переменные
NN>$(ProgramFiles)
NN>и
NN>$(ProgramW6432)
NN>а у вас в NemerleAll.nproj
NN>в 312 строке используется $(ProgramFiles(x86))
NN>в результате чего у меня создался junction в никуда

Похоже на то. ОК, заменим на "ProgramFiles". Он ведь по идее тоже на "ProgramFiles (x86)"-каталог должен указывать.

Спасибо за помощь!

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

VD>Похоже на то. ОК, заменим на "ProgramFiles". Он ведь по идее тоже на "ProgramFiles (x86)"-каталог должен указывать.

PROCESSOR_ARCHITECTURE = x86
ProgramFiles = C:\Program Files (x86)
ProgramW6432 = C:\Program Files
MSBuildProgramFiles32 = C:\Program Files (x86)

PROCESSOR_ARCHITECTURE = AMD64
ProgramFiles = C:\Program Files
ProgramW6432 = C:\Program Files
MSBuildProgramFiles32 = C:\Program Files (x86)

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

F>

F> PROCESSOR_ARCHITECTURE = x86
F> ProgramFiles = C:\Program Files (x86)
F> ProgramW6432 = C:\Program Files
F> MSBuildProgramFiles32 = C:\Program Files (x86)

F>

F> PROCESSOR_ARCHITECTURE = AMD64
F> ProgramFiles = C:\Program Files
F> ProgramW6432 = C:\Program Files
F> MSBuildProgramFiles32 = C:\Program Files (x86)

А можно как-то снабжать свои сообщения осмысленным текстом.

А то в приведенном тексте есть много спорного. Так PROCESSOR_ARCHITECTURE лично у меня x86 не смотря на то, что ОС 64-битная.

Кроме того в 32-битных ОС вроде как нет ProgramW6432.

ProgramFiles у меня указывает на "E:\Program Files (x86)".

На мой взгляд нам достаточно использовать ProgramFiles. Под 64-битной она будет указывать куда надо. А в 32-битной джанкшон все равно не делается.

Так что за информацию о MSBuildProgramFiles32 спасибо. Но похоже он нам не особо нужен. Тем более, что фича не особо документированная.

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

VD>А в 32-битной джанкшон все равно не делается.

Он уже нигде не делается с того момента, как мы перешли на NemerleBinPathRoot в качестве указателя на директорию установки. Даже самого SetJunction.exe в дистре уже нет. Строчка, которую привел топистартер осталась в проекте инсталлера по недоразумению, ее просто надо выпилить.

P.S: Предвосхищая вполне резонный вопрос: будет сегодня ночью У меня на ноуте накрылся винт, я из-за этого на пару дней выпал из любых активностей. Fixed.

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

VD>На мой взгляд нам достаточно использовать ProgramFiles. Под 64-битной она будет указывать куда надо. А в 32-битной джанкшон все равно не делается.

Как обычно — полез отвечать не вникнув до конца в суть написанного Подумал, что речь идет об инсталлере.

А зачем вообще нужен этот джанкшин сейчас? Для таргета Install, я так понимаю? Но ведь в том виде, в котором он есть сейчас, на системе с установленным из инсталлера немерлом, сборка этого таргета поломает все нафиг, если он был установлен не по стандартному пути. А если по стандартному, то поломается не все, а только интеграция.

Я к тому, что этот таргет — вообще кем-то используется?

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

KV>Он уже нигде не делается с того момента, как мы перешли на NemerleBinPathRoot в качестве указателя на директорию установки. Даже самого SetJunction.exe в дистре уже нет. Строчка, которую привел топистартер осталась в проекте инсталлера по недоразумению, ее просто надо выпилить.

Вообще-то речь шла не о инсталяторе, а о сборке из исходников. Этот баг был в NemerleAll.nproj. Возможно из-за него не работала прекомпиляция сборок ngen-ом и приходилось дополнительно гонять Reg-bins-2.cmd и Reg-bins-2-4.0.cmd.

KV>P.S: Предвосхищая вполне резонный вопрос: будет сегодня ночью У меня на ноуте накрылся винт, я из-за этого на пару дней выпал из любых активностей. Fixed.

ОК. С нетерпением ждем.

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

KV>А зачем вообще нужен этот джанкшин сейчас? Для таргета Install, я так понимаю?

Да для работы компилятора собранного с исходинков. В проекте используется "ProgramFiles". А это по майкрософт-логике является каталогом "E:\Program Files (x86)" под 64-битной виндой.

Вот мы и делаем джанкшон чтобы не было разницы.

Кстати, инсталлированный продукт будет вести себя так же. Так что как бы ты не поторопился что-то там удалять.

KV>Но ведь в том виде, в котором он есть сейчас, на системе с установленным из инсталлера немерлом, сборка этого таргета поломает все нафиг, если он был установлен не по стандартному пути. А если по стандартному, то поломается не все, а только интеграция.

Во-первых, для сборки с исходников инсталлированную версию нужно снести. Они все равно параллельно работать не могут.

Но я не пойму что и почему должно поломаться. Ты в инсталляторе всегда забиваешь переменную NemerleBinPathRoot*+?

KV>Я к тому, что этот таргет — вообще кем-то используется?

Какой таргет? Речь о линке между каталогами "E:\Program Files (x86)\Nemerle" и "E:\Program Files\Nemerle". Если собирать все из исходников, то этот джанкшон нужен.

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

Извиняюсь, думал и так будет понятно.
Разница возникает в зависимости от того, какой из msbuild.exe будет реально выполнен (т.е. из Framework или Framework64).

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

VD>Вот мы и делаем джанкшон чтобы не было разницы.

Nemerle не обязательно может быть установлен в Program Files. У нас есть пользователи, которые ставят его в корень C:, например. Мы из-за них тогда всю эту котовасию с NemerleBinPathRoot и начали.

VD>Кстати, инсталлированный продукт будет вести себя так же. Так что как бы ты не поторопился что-то там удалять.

А какой смысл в джанкшине из инсталлера? У нас там все переписано с захардкоженных путей на %NemerleBinPathRoot%, месяцев за 9 глюков вроде не всплыло.

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

Я имел ввиду, что они параллельно не смогут работать.

VD>Ты в инсталляторе всегда забиваешь переменную NemerleBinPathRoot*+?

Всегда, если она еще не забита на момент установки.

VD>Если собирать все из исходников, то этот джанкшон нужен.

Ок.

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

F>Извиняюсь, думал и так будет понятно.
F>Разница возникает в зависимости от того, какой из msbuild.exe будет реально выполнен (т.е. из Framework или Framework64).

Я как-то сомневаюсь, что под 64-битной версией виндовс хоть под каким-то фрэймворком будет ProgramFiles="C:\Program Files".

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

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

KV>Я имел ввиду, что они параллельно не смогут работать.

Да и фиг бы с ними. Это всегда так было.

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

F>>Извиняюсь, думал и так будет понятно.
F>>Разница возникает в зависимости от того, какой из msbuild.exe будет реально выполнен (т.е. из Framework или Framework64).
VD>Я как-то сомневаюсь, что под 64-битной версией виндовс хоть под каким-то фрэймворком будет ProgramFiles="C:\Program Files".
WOW64 Implementation Details — как бы не я это придумал и от фреймворка это вообще не зависит.
Но если хочется то вот можно попробовать:

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
    <Target Name="Build">
        <Message Importance="High" Text="PROCESSOR_ARCHITECTURE = $(PROCESSOR_ARCHITECTURE)" />
        <Message Importance="High" Text="ProgramFiles = $(ProgramFiles)" />
        <Message Importance="High" Text="ProgramW6432 = $(ProgramW6432)" />
        <Message Importance="High" Text="MSBuildProgramFiles32 = $(MSBuildProgramFiles32)" />
    </Target>
</Project>

C:\Windows\Microsoft.NET\Framework64\v4.0.30319\MSBuild.exe build.proj

батничек пока не работает )))

VD>Пробовали еще в бэта. Даже работало после доработки напильником. Но там с фрэймворком все не очень красиво у МС было и решили отложить до релиза.

А есть какая-то ветка с этими экспериментами в репозитории? Можно как-то посмотреть что там с Nemerle под .NET 4.5 RC и его взаимодействием с VS 2012 RC? Или лучше всё с нуля начать?

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

VD>>Пробовали еще в бэта. Даже работало после доработки напильником. Но там с фрэймворком все не очень красиво у МС было и решили отложить до релиза.

_>А есть какая-то ветка с этими экспериментами в репозитории? Можно как-то посмотреть что там с Nemerle под .NET 4.5 RC и его взаимодействием с VS 2012 RC? Или лучше всё с нуля начать?

Я это в репозиторий не заливал, но локально такая ветка есть у меня. В двух словах: все отлично работает, но только в том случае, если собирать компилятор и интеграцию именно под FW4.5/VS2012 SDK. В противном случае, там периодически возникают глюки в студии на ровном месте.

Короче, нам похоже придется заводить 3-ий дистрибутив

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

KV>Короче, нам похоже придется заводить 3-ий дистрибутив

Когда можно ожидать?

KV>Я это в репозиторий не заливал, но локально такая ветка есть у меня. В двух словах: все отлично работает, но только в том случае, если собирать компилятор и интеграцию именно под FW4.5/VS2012 SDK. В противном случае, там периодически возникают глюки в студии на ровном месте.

А можешь завести ветку в глобальном репозитории? Я бы тогда продолжил работу по 2012. Заодно что нужно что-бы получить права в github на запись в такую ветку? Мой ак в github: hi-octane

_>А можешь завести ветку в глобальном репозитории? Я бы тогда продолжил работу по 2012. Заодно что нужно что-бы получить права в github на запись в такую ветку? Мой ак в github: hi-octane

Все вопросы отменяются — с git разобрался, интеграцию с 2012 RC запустил. Оказалось там правок всего ничего, и завелось влёт.

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

F> Но если хочется то вот можно попробовать:...

Попробовал. Все оказалось совсем печально.

В 64-бтной версии МСБилда от 3.5-го фрэймворка найти каталог "E:\Program Files (x86)" вообще не возможно:

e:\Nemerle>set MSBuild="%SystemRoot%\Microsoft.NET\Framework64\v3.5\msbuild.exe"

e:\Nemerle>%MSBuild% x.proj
Microsoft (R) Build Engine Version 3.5.30729.5420
[Microsoft .NET Framework версии 2.0.50727.5456]
 (C) Корпорация Майкрософт (Microsoft Corp.), 2007.

Build started 08.06.2012 17:32:18.
Project "e:\Nemerle\x.proj" on node 0 (default targets).
Project file contains ToolsVersion="4.0", which is not supported by this version
Build:
  PROCESSOR_ARCHITECTURE = AMD64
  ProgramFiles = E:\Program Files
  ProgramW6432 = E:\Program Files
  MSBuildProgramFiles32 =

Вывод печальный. 64-битной версией МСБилда пользоваться прост нельзя.

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

NN>тут еще один момент забыл затронуть
NN>для того что бы установить nemerle из исходников в program files
NN>необходимо запускать батники под администратором,
NN>но когда запускаешь под администратором, текущая папка меняется на c:\Windows\System32

Все делают проще. Запускают из под админа Тотал Командер или Фар, а уже из них батники. Тогда с кталогами проблем нет.

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

_>Все вопросы отменяются — с git разобрался, интеграцию с 2012 RC запустил. Оказалось там правок всего ничего, и завелось влёт.

Что за изменения?

Здравствуйте, VladD2, Вы писали:
VD>Все делают проще. Запускают из под админа Тотал Командер или Фар, а уже из них батники. Тогда с кталогами проблем нет.
Странно как то так все делают, у меня например нет ни тотал командера, ни фара, да и смысла в этих лишних телодвижениях нету,
вся проблема то в двух строчках

@pushd "%~dp0

в начале
и

@popd

в конце

Исправленный батничек, кстати одна строчка была лишняя

:: BuildLib.cmd
@echo off
call:%1
goto:eof

:start
title Build Nemerle
set BUILD_DIR=%~dp0
set MSBUILD="%SystemRoot%\Microsoft.NET\Framework\v4.0.30319\msbuild.exe"
pushd %BUILD_DIR%
goto:eof

:stop
pause
popd
goto:eof

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

VD>Вывод печальный. 64-битной версией МСБилда пользоваться прост нельзя.
мне кажется это не правильный подход какой то, как и в соседней ветке данной дискуссии, щас отвечу там

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

KV>Для того, чтобы наш vsix можно было закрутить под VS2012 достаточно в его манифесте указать, что он поддерживает эту версию. Даже пересобирать не нужно. Однако, в этом случае, при работе с более-менее не учебными проектами, начинаются глюки студии, которые не воспроизводятся в 2010 с тем же vsix'ом. Поэтому, и Nemerle и vsix нужно собирать под 4.5 и 2012 SDK, тогда все ок. Что приводит нас к необходимости заводить 3ий инсталлятор
сборка в данном случае не требует наличия VS2010 SDK?

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

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

KV>>Для того, чтобы наш vsix можно было закрутить под VS2012 достаточно в его манифесте указать, что он поддерживает эту версию. Даже пересобирать не нужно. Однако, в этом случае, при работе с более-менее не учебными проектами, начинаются глюки студии, которые не воспроизводятся в 2010 с тем же vsix'ом. Поэтому, и Nemerle и vsix нужно собирать под 4.5 и 2012 SDK, тогда все ок. Что приводит нас к необходимости заводить 3ий инсталлятор
NN>сборка в данном случае не требует наличия VS2010 SDK?

Нет, она требует VS2012 SDK и по-моему, там еще надо повозиться с референсами, хотя и не уверен (нет сейчас под рукой той виртуалки, смогу позже глянуть).

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

KV>Нет, она требует VS2012 SDK и по-моему, там еще надо повозиться с референсами, хотя и не уверен (нет сейчас под рукой той виртуалки, смогу позже глянуть).

вот я именно об этом и говорю, а установка VS2010 на windows 8, которая нужна для установки VS2010 SDK
задача насколько я понял не тривиальная, по крайней мере у меня не получилось даже isolated shell поставить

VD>Что за изменения?

В реале я менял вот что:

Nemerle.VisualStudio.WPFProviders.NemerleEventBindingProvider

public override bool CreateMethod(EventDescription eventDescription, string methodName)//, string initialStatements) <- убрал string initialStatements

//закомментил напрочь оба метода:

    //public override void AppendStatements(EventDescription eventDescription, string methodName, string statements, int relativePosition)
    //{
    //  throw new NotImplementedException();
    //}

    //public override string CodeProviderLanguage
    //{
    //  get { throw new NotImplementedException(); }
    //}

Хотел по правильному, патч сделать. Но ацццкий git пишет что no-changes. Или gitextensions показывают изменения только после коммита?

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

NN>Странно как то так все делают, у меня например нет ни тотал командера, ни фара, да и смысла в этих лишних телодвижениях нету,

Лично я все равно работаю из Тотал Камандера. Так что для меня это не является лишними движениями. У меня наоборот все в нем на кнопках замаплено.

NN>вся проблема то в двух строчках
NN>

NN>@pushd "%~dp0
NN>

NN>в начале
NN>и
NN>

NN>@popd
NN>

NN>в конце

Ну, дык сделай это, протестируй и предложи пул-реквест. Делов то?

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

VD>>Вывод печальный. 64-битной версией МСБилда пользоваться прост нельзя.
NN>мне кажется это не правильный подход какой то, как и в соседней ветке данной дискуссии, щас отвечу там

Что-то я не вижу связи между ветками.

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

VD>Попробовал. Все оказалось совсем печально.
VD>В 64-бтной версии МСБилда от 3.5-го фрэймворка найти каталог "E:\Program Files (x86)" вообще не возможно:
VD>Вывод печальный. 64-битной версией МСБилда пользоваться прост нельзя.
Пропа появилась по моему только в 4-м.
Имхо, если хочется избавиться от этих разностей — только делать свой build task.

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

F> Имхо, если хочется избавиться от этих разностей — только делать свой build task.

Проще не использовать 64-битный МСБилд. Толку от него все равно — 0.

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

F>> Имхо, если хочется избавиться от этих разностей — только делать свой build task.
VD>Проще не использовать 64-битный МСБилд. Толку от него все равно — 0.
Вполне возможно — тебе виднее.

Хотя если хочется таргетится на mono и его xbuild — то ко всем этим скриптам имеет смысл относится несколько более бережно, а msbuild 3.5/4.0 — становится вообще не показательным. Всё зависит от поставленной цели.

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

KV>Но если делать отдельным инсталятором, то поддержку FW4.5/VS2012 мы можем обеспечить прямо сейчас, причем настолько же стабильную, насколько она является таковой в VS2010.

Если это реально сделать , то чего ждем ?
Тормоза 2010-й студии достают

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

KV>>Но если делать отдельным инсталятором, то поддержку FW4.5/VS2012 мы можем обеспечить прямо сейчас, причем настолько же стабильную, насколько она является таковой в VS2010.

_NN>Если это реально сделать , то чего ждем ?
_NN>Тормоза 2010-й студии достают

А что 2012-я студия стала сильно шустрее?

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

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

KV>>Но если делать отдельным инсталятором, то поддержку FW4.5/VS2012 мы можем обеспечить прямо сейчас, причем настолько же стабильную, насколько она является таковой в VS2010.

_NN>Если это реально сделать , то чего ждем ?
_NN>Тормоза 2010-й студии достают

Ап. Студия уже в RTM ушла, хотелось бы на нее потихоньку перебираться.

Здравствуйте, Аноним, Вы писали:

_NN>>Тормоза 2010-й студии достают
А>Ап. Студия уже в RTM ушла, хотелось бы на нее потихоньку перебираться.
Судя по этому — скачать можно будет — 15 августа — так что уже несколько дней можно и потерпеть.