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

IT>Кто не спрятался, тот не виноват.

4.5 не ставится под WinXP ни под каким соусом, а заказчики совместимость всё ещё повсеместно требуют.

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

K>Посмотрите в сторону dnlib. Это такой Cecil на стероидах, на его основе сейчас работают de4dot, ConfuserEx и ILRepack.

А, какие у него преимущества есть?

Я на CCI Metedata выбор остановил потому что он использован в Розлине и это реализация от Майкрософт. Есть вероятность, что его будут и дальше поддерживать и развивать. А, не будут, так хотя бы есть шанс выкорчевать его клон из Розлина и свалить на него.

Моно у меня доверия не вызывает. Была еще интересная реализация из IKVM, но боюсь, что его самостоятельно поддерживать придется.

В принципе, мы будем стараться все абстрагировать от конкретных сторонних библиотек. Можно будет сделать сколько угодно внешних бэкэндов на базе любых библиотек. В том числе даже можно сделать бэкнды для Явы и LLVM. Вот только наших рук на это все не хватит. По сему мы сделаем референсную реализацию (скорее всего на CCI Metedata), а уж кто хочет, пусть делают свои на чем угодно.

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

K>И, пожалуйста, сразу всё с нормальной поддержкой NuGet. Оптимально чтобы через него подтягивался не только рантайм, но и сам компилятор.

NuGet мы уже используем в Нитре для плагинов к IDE. Учитывая, что проблем с SRE не будет, сделать NuGet-распространение для второго Немерла будет по проще. Но есть проблема даймонд-наследования, которую не ясно как решать. Ведь если кто-то собрал компоненты с разными версиями рантйм-библиотек, то собрать их в одном модуле уже не выйдет.

Сейчас эта проблема решается за счет того, что немерловый инсталлятор ставт в GAC специальную прокси-сборку, которая заставляет подавить версионирование сборок дотнета и использовать всеми одной копии Nemerle.dll.

Вроде как в 4.5+ фреймворках стратегия версионирвоания изменилась. Так что, возможно, получится обойтись без этих приседаний. Тогда с NuGet-распространение проблем быть не должно. Но, надо пробовать.

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

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

NuGet прописывает в таких случаях binding redirect в App.config, заставляя всех использовать ту самую последнюю версию.

Например, для JSON.NET очень часто появляется запись вида:

 <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-7.0.0.0" newVersion="7.0.0.0" />
      </dependentAssembly>
    </assemblyBinding>
  </runtime>

Насколько я знаю bindingRedirect поддерживается как минимум начиная с .NET 2.0.

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

K>NuGet прописывает в таких случаях binding redirect в App.config, заставляя всех использовать ту самую последнюю версию.

Это работает только для exe-шников. А, есть еще DLL-и и сама студия. У студии тоже можно прописать редиректы, но это в разы сложнее и NuGet-ом, наверняка, не делается.

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

VD>Это работает только для exe-шников.

Если dll-ка подключается через NuGet, то у неё в зависимостях прописан Nemerle конкретной версии. Что и является основанием для прописывания binding redirect. Для студии всё вроде как лечится посредством добавления обработчика AppDomain.AssemblyResolve. Опять же никто не мешает при сборке не указывать Specific Version.

Таки да

The event handler can return a different version of the assembly than the version that was requested.

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

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

IT>>Кто не спрятался, тот не виноват.

K>4.5 не ставится под WinXP ни под каким соусом, а заказчики совместимость всё ещё повсеместно требуют.

Софт под чугунные промышенные железки пишете?

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

С>Софт под чугунные промышенные железки пишете?

Да даже когда под обычные офисные. Оборудование устаревает, а менять его никто не торопится. 2007-ой Word с файрфоксом работают, всех всё устраивает.
Не говоря уже о случаях, когда к компьютеру подключена какая-нибудь стоящая пару десятков килобаксов древняя железяка, драйверов для которой на что-то кроме Win2K/XP нет и уже не предвидится.
Со вторым столкнулся когда начали делать софт для автосервисов, занимающихся в том числе прошивками мозгов автомобилей. Там не то что драйвера, там сами железки для старых моделей уже не выпускают, а народ на них до сих пор катается.

В итоге городятся костыли типа вот этого.

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

С>Софт под чугунные промышенные железки пишете?
У нас требуется поддержка XP, клиенты только вот на 7-ку переползают.
Могу сказать, что клиенты у нас довольно крупные и серьёзные компании, а посему всем там ясно, что просто так менять рабочую систему не имеет большого смысла.
Более того, у нас даже требование даже .NET 3.5 потому что он с 7-кой идет из коробки.

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

K>Таки да
K>

K>The event handler can return a different version of the assembly than the version that was requested.

Это очень ненадежный путь. Обработчик может быть перехвачен кем угодно.

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

K>4.5 не ставится под WinXP ни под каким соусом, а заказчики совместимость всё ещё повсеместно требуют.

Ограничений на целевую платформу (т.е. на то где может выполняться скомпилированная сборка) не будет. Речь только о рантайме на котором может работать сам Nemerle 2.

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

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

IT>>Тогда я бы не парился. 4.5 это вроде как VS 2012, т.е. уже три года. Кто не спрятался, тот не виноват.

VD>А, если минимальной будет 2015-я и, соответственно, 4.6-й фреймворк? (учитывая, что релиз не завтра будет)
Это решение снизит количество желающих попробовать немерле. Ставить 15 студию, специально вряд ли кто будет. У меня знакомый до сих пор в 2005 работает. Для привлечения народа, нужно снизить сложность вхождения. Что бы немерл в 3 щелчка подключался к текущим проектам. С этой точки зрения, желательно поддерживать все версии начиная с 2008. Хотя я сам за 15. Как я понял, это понизит сложность и немерл в релиз быстрее выйдет

_>Это решение снизит количество желающих попробовать немерле. Ставить 15 студию, специально вряд ли кто будет. У меня знакомый до сих пор в 2005 работает. Для привлечения народа, нужно снизить сложность вхождения. Что бы немерл в 3 щелчка подключался к текущим проектам. С этой точки зрения, желательно поддерживать все версии начиная с 2008. Хотя я сам за 15. Как я понял, это понизит сложность и немерл в релиз быстрее выйдет

Человек который работает в 2005-й студии и не имеет, ни дома ни на офисе 2015-й, хотя бы для личного развития, — не перейдёт на другой язык ни при каких обстоятельствах. Будут любые отмазы чтобы остаться "в зоне комфорта". Предыдущее поколение таких людей пилит вечность на Delphi 7.

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

VD>Ограничений на целевую платформу (т.е. на то где может выполняться скомпилированная сборка) не будет. Речь только о рантайме на котором может работать сам Nemerle 2.

Насколько я понимаю одно из применений Nemerle 2 это встраиваемые языки , а значит язык по месту использования, т.е. нужен сам рантайм то бишь Nemerle 2.
Такой сценарий очевидно не будет поддерживаться.

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

_NN>Насколько я понимаю одно из применений Nemerle 2 это встраиваемые языки , а значит язык по месту использования, т.е. нужен сам рантайм то бишь Nemerle 2.
_NN>Такой сценарий очевидно не будет поддерживаться.

Любой язык созданные на основе Nitra может быть встроен в другой Nitra-язык. Nemerle не исключение. Сама Nitra использует Nemerle как встроенный язык. Сейчас мы просто используем Nemerle как компонент. В будущем будем заменим его на собственную версию Nemerle 2.

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

_>Что бы немерл в 3 щелчка подключался к текущим проектам. С этой точки зрения, желательно поддерживать все версии начиная с 2008. Хотя я сам за 15. Как я понял, это понизит сложность и немерл в релиз быстрее выйдет

Думаю, что это уравнение с несколькими параметрами. Учитывая, что силы у нас ограниченные мы можем или потратить больше сил на совместимость с VS 200x, или потратить эти силы на создание более качественной поддержки VS 2013+.

Учитывая, что я скорее согласен с hi_octane

Автор: hi_octane
Дата: 12.08.15

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