в общем краткая пред история
Установил 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

Здравствуйте, 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-а. Собственно, работает и фиг бы с ним. Все равно этот файл правится раз в год по обещанию.

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

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

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

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

VD>Я уже деталей не помню, но вроде бы это были уши 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