Установил отсюда NemerleSetup-net-4.0-v1.1.923.0-nightly.msi.

При попытке создать/открыть Nemerle проект в Visual Studio 2010 SP1 вылетает ошибка

assertion failed in file ncc\passes.n, line 758: internal type Nemerle.Core.list with 1 type arguments not found.

При попытке откомпилировать программку

using System.Console;

WriteLine("Hello, World!");

Из командной строки

C:\NemerleProjects>ncc -no-color HelloWord.n -out:HelloWord.exe

Появляется ошибка

error: Can't load types from 'Nemerle, Version=1.1.923.0, Culture=neutral, PublicKeyToken=e080a9c724e2bfcd'. Error: Не удалось загрузить тип "System.Runtime.CompilerServices.ExtensionAttribute" из сборки "mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"..
confused by earlier errors bailing out

С версией
NemerleSetup-net-4.0-v1.1.921.0-nightly.msi
та же проблема

А вот при установке
NemerleSetup-net-4.0-v1.1.746.0.msi
и то и то работает.

Интересно, у меня только такие проблемы? Подскажите, что с этим можно поделать? К кому обратиться?

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

D>Подскажите, что с этим можно поделать?

Сносил старые версии?

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

D>Интересно, у меня только такие проблемы? Подскажите, что с этим можно поделать? К кому обратиться?

Нет, это глобальные проблемы. В настоящий момент, их можно решить обновлением FW4.0 на FW4.5, либо самостоятельной сборкой инсталлятора под чистым FW4.0

Здравствуйте, hardcase, Вы писали:
H>Здравствуйте, d8m1k, Вы писали:

D>>Подскажите, что с этим можно поделать?
H>Сносил старые версии?

Не поможет.

"Хьюстон, у нас проблемы" (с) Версии Nemerle для FW4.0/VS2010, собранные на нашем билд-сервере, теперь требуют установленной FW4.5 после того, как FW на сервере обновили до этой версии

Я пока , что с этим делать

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

KV>Я пока , что с этим делать
Известно что делать:
Сброка 4.0 должна собираться только на хосте где нет 4.5. Тут, это кстати обсуждали с моим и без моего участия не раз — но ваш билд сервер видимо обновился не взирая на всё это. Не в упрёк вашей команде — но всё таки это минус. Обмусолено не раз, и наступили на эти грабли. При том все об этом знали.

Известно что делать 2:
Переводить N — на IKVM/Cecil/Cci — пока там SRE — это гемор.
Переводить — я так и сам краем глаза видел — удовольствие то ещё. Начиная от extern-alias-ов и т.п. Т.е. всё то от чего авторы отказались неясно почему — оказывается таки нужно. При чём, что ироничнее всего — это нужно в первую очередь самому компилятору, а не его пользователям. Но тут правда я авторов понимаю — когда они это начинали — оно нужно не было.

Если есть планы воссоздать компилятор N на N2 — т.е. написать его заново и по нормальному — то, я имхо считаю так:
а) выбросить идеи о использовании IKVM нафиг. Оно нужно, только если нужно API SRE;
б) выбрать таки Mono.Cecil;
в) выбрать таки Mono.Cecil;
г) выбрать таки Mono.Cecil;
д) возможно Microsoft.Cci, и то если он нормально работает под Mono — нужно смотреть/проверять.
Так вот — если есть идеи воссоздать, то потерпеть полгода-год-два — можно и с текущим компилятором, имхо. И в этом свете заморачиваться на изменение текущего — я лично не вижу смысла.

Ну либо реально пилить с помощью IKVM текущий компилятор... Но, опять же — имхо — даже с учетом нароботок hardcase — это будет работа просто в пустую, может кто-то осилить продолжить его начинание — но что-то сомневаюсь. Я посмотрел — по себе вижу — не осилю, да и в первую очередь потому что не вижу смысла в этом.
А тот кому нужен просто реальный таргет на 4.0 — может уж как-то и сбилдить на 4.0, на той же виртуалке. А те кто пошли на 4.5-only — тех это и так не парит.
2012-ая студия преимуществ по большому счету никаких не даёт. Супер скорости в ней нет, особенно в интеграции с Немерле — кардинально там точно ничего не добавится. Хотя кардинального ускорения на шарповых проектах я тоже не увидел.

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

KV>>Я пока , что с этим делать
F> Известно что делать:
F> Сброка 4.0 должна собираться только на хосте где нет 4.5. Тут, это кстати обсуждали с моим и без моего участия не раз — но ваш билд сервер видимо обновился не взирая на всё это. Не в упрёк вашей команде — но всё таки это минус. Обмусолено не раз, и наступили на эти грабли. При том все об этом знали.

Наш "билд-сервер" по совместительству еще и данный конкретный сервер (rsdn.ru) и весь бэкенд инфраструктуры разработки RSDN Team, если че) Накладки неизбежны, а интересы тима приоритетнее в любом случае. Нужно выносить сборку на отдельный сервер (теперь уже получается, что два), выделенный специально под эту задачу.

F> А тот кому нужен просто реальный таргет на 4.0 — может уж как-то и сбилдить на 4.0, на той же виртуалке. А те кто пошли на 4.5-only — тех это и так не парит.

Т.е. ты предлагешь переименовать дистрибутив в Nemerle v1.1.x.0 nightly .Net v4.5 binaries and Visual Studio 2010 extension installer и не париться по этому поводу?

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

KV>Наш "билд-сервер" по совместительству еще и данный конкретный сервер (rsdn.ru) и весь бэкенд инфраструктуры разработки RSDN Team, если че) Накладки неизбежны, а интересы тима приоритетнее в любом случае. Нужно выносить сборку на отдельный сервер (теперь уже получается, что два), выделенный специально под эту задачу.
Вообще в конкретном данном случае — пользователям Nemerle — честно говоря — фиолетово на интересы RSDN team. И оправдываться этим — просто издевательство. Хотя разумеется RSDN team не обязана никому и ничего — но, выкладывая сборку — люди ожидают её видеть рабочей.

KV>Т.е. ты предлагешь переименовать дистрибутив в Nemerle v1.1.x.0 nightly .Net v4.5 binaries and Visual Studio 2010 extension installer и не париться по этому поводу?
В этой ситуации, всё что вы можете предложить — это отказаться от билдов под 4.0. Т.е. да, почти тупо переименовать — но вот в чём дело — это всё равно не решает проблемы.
Т.к. это не просто приложение — а это таки компилятор — то производные им сборки — зависят от установленного рантайма, и теперь end-user получает туже самую проблему. На 4.0 — всё идеально, запускаемся на 4.0 и 4.5 — на 4.5 — запускаемся только на 4.5. Это проблема тупо компилятора.
Я вот от 4.0 откажусь в лучшем случае года через 2-5 — как думаешь — как быть? (риторически)
Можно попробовать конечно прикрутить какие-то костыли, я для себя пока что решил этот вопрос ограничив сборочную среду — это просто проще всего.

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

А вообще — чего они не сделали side-by-side установку 4.5... Экономы блин. Ведь таки поломали обратную совместимость, более того — набажили же ж с верификацией...
Так отлично всё получалось ранее. А на фоне размера установленного W7 — ещё один фреймворк бы никто и не заметил.

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

F>Можно попробовать конечно прикрутить какие-то костыли, я для себя пока что решил этот вопрос ограничив сборочную среду — это просто проще всего.

Если мы заботимся о наших пользователях, то должны предоставить два дистрибутива с интеграцией с VS2010: один под 4.0, один под 4.5, а еще лучше поставлять это в одном и выбирать в зависимости от окружения в котором его разворачивают. Это тяжеловато реализовать с точки зрения автоматизации сборки, но не невозможно.

Обновление до FW4.5 помогло. Благодарю! Смотрю, версию NemerleSetup-net-4.0-v1.1.924.0-nightly.msi выложили вместо той — оперативно

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

F> Я вот от 4.0 откажусь в лучшем случае года через 2-5 — как думаешь — как быть? (риторически)

Одно дело — отказываться от старой, другое — использовать новую. Новая уже доступна в релизе, так в чём проблема качнуть?
Мелкомягкие — те ещё дебилы, конечно, но это не должно особо мешать: просто ставим FW 4.5 и предупреждаем, что "чисто 4.0" теперь не работает. Считай, как апгрейд.
Кстати, что по этому поводу выкатит Липперт? Опять "nobody designed, blah-blah..."?

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

M>Одно дело — отказываться от старой, другое — использовать новую. Новая уже доступна в релизе, так в чём проблема качнуть?
M>Мелкомягкие — те ещё дебилы, конечно, но это не должно особо мешать: просто ставим FW 4.5 и предупреждаем, что "чисто 4.0" теперь не работает. Считай, как апгрейд.
Обычно проблемы качнуть конечно же нет. Но дело ещё в том, что .NET 4.5 не работает на Windows XP и Server 2003, судя по списку поддерживаемых платформ. Таким образом имеем таки необходимость поддерживать 4.0. Я не спорю, что не так страшен чёрт, как его рисуют, но нам, — разработчикам — легче от этого ну никак не становится.
Тем более, что если клиент обновится до 4.5, — и сталкивается с ломающим изменением — то, разработчик, получается, что должен изволить выкатить обновление, если на сервере — среда обычно контроллируемая, то всё таки требовать наличия 4.0-only на клиентских местах — некрасиво. Технически это не проблема — но работы всё равно таки добавляет. А в случаях когда обновление происходит, скажем раз в год — это уже тянет на внеочередное обновление.
И это всё безотносительно проблем компилятора N. Ну а тут ещё ncc доставляет немножко хлопот, увы.

M>Кстати, что по этому поводу выкатит Липперт? Опять "nobody designed, blah-blah..."?
Без понятия. Я читал, что они задумали in-place обновление ради уменьшения размера инсталлятора.

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

F>Так отлично всё получалось ранее. А на фоне размера установленного W7 — ещё один фреймворк бы никто и не заметил.

Так или иначе, проблема с серверами для агентов сборки проекта решена и, в самое ближайшее время (как только настрою все необходимое окружение), ночные сборки будут осуществляться для всех комбинаций поддерживаемых версий студии и фреймворка.

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

F> Я читал, что они задумали in-place обновление ради уменьшения размера инсталлятора.

Бха!!!! И это делают люди, выкатывающие 3-гиговые исошки для SQL сервера! (где какое-то м**о засунуло и х86, и х64 версии) Оригиналы....