Поставил немерле для VS2008 из последнего инсталятора. При компиляции старого(созданного с предыдущей версией немерле) проекта выдаются сообщения:
C:\Windows\Microsoft.NET\Framework\v3.5\Microsoft.Common.targets(0,0):Warning MSB3245: Could not resolve this reference. Could not locate the assembly "ComputationExpressions, Version=1.0.0.9832, Culture=neutral, PublicKeyToken=null". Check to make sure the assembly exists on disk. If this reference is required by your code, you may get compilation errors.
C:\Program Files\Nemerle\Nemerle.MSBuild.targets(0,0):Warning MSB3245: Could not resolve this reference. Could not locate the assembly "ComputationExpressions.Macros, Version=1.0.0.9832, Culture=neutral, PublicKeyToken=null". Check to make sure the assembly exists on disk. If this reference is required by your code, you may get compilation errors.
При этом проект не компилируется и ругаетяс на синтаксис компутэйшн эксперссинов. Если удалить из референсов сборки ComputationExpressions.Macros и ComputationExpressions, а затем опять добавить из папки в которую установлен Немерле, то все работает. С чем это связанно?
Здравствуйте, Ka3a4oK, Вы писали:
KK>При этом проект не компилируется и ругаетяс на синтаксис компутэйшн эксперссинов. Если удалить из референсов сборки ComputationExpressions.Macros и ComputationExpressions, а затем опять добавить из папки в которую установлен Немерле, то все работает. С чем это связанно?
Старая версия проектов осталась?
Если — да, то покажи как были ссылки на эти сборки прописаны.
Скорее всего там была указана полная версия. В этом случае, имеет смысл открыть свойства ссылок на сборки и установить свойство Specific Version в false.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD>Если — да, то покажи как были ссылки на эти сборки прописаны.
Я просто делал ад референс. Затем выбирал папку с немерле, выбирал нужную сборку и нажимал ок.
VD>Скорее всего там была указана полная версия. В этом случае, имеет смысл открыть свойства ссылок на сборки и установить свойство Specific Version в false.
Здравствуйте, Ka3a4oK, Вы писали:
KK>Я просто делал ад референс. Затем выбирал папку с немерле, выбирал нужную сборку и нажимал ок.
Ну, так и погляди что в файле проекта получилось.
VD>>Скорее всего там была указана полная версия. В этом случае, имеет смысл открыть свойства ссылок на сборки и установить свойство Specific Version в false.
KK>Нет такого свойства.
Возможно мы эту фичу только для VS2010 реализовали. Или это не поддерживалось в старой версии.
Тогда ссылки можно поправить только прямы редактированием проектного файла. Убери все что относится к версиям и пропиши пути через $(Nemerle).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Ka3a4oK, Вы писали:
KK>>Я просто делал ад референс. Затем выбирал папку с немерле, выбирал нужную сборку и нажимал ок.
VD>Ну, так и погляди что в файле проекта получилось.
Здравствуйте, VladD2, Вы писали:
VD>А можно узнать с чем товарищ, поставивший минус, не согласен?
Я минус не ставил, но меня тоже напрягает использование немерла в продакшене тем, что сборки постоянно меняют версию. По сути необходимо всем разработчикам держать одну и ту же версию и обновляться синхронно. Если что, твои доводы по поводу dll hell мне знакомы. Только я получаю dll hell именно в текущем раскладе.
Едиственный воркэраунд который я нашел — включение компилятора и необходимых сборок прямо в проект. Но с nrails и этот способ не катит.
Здравствуйте, Ziaw, Вы писали:
Z>Я минус не ставил, но меня тоже напрягает использование немерла в продакшене тем, что сборки постоянно меняют версию. По сути необходимо всем разработчикам держать одну и ту же версию и обновляться синхронно. Если что, твои доводы по поводу dll hell мне знакомы. Только я получаю dll hell именно в текущем раскладе.
Все что нужно — это не указывать в ссылке на сборку ее версию. В старой версии интеграции, к сожалению, это делалось автоматом и изменить поведение было нельзя. В новой версии есть свойство Specific Version регулирующее это дело. Причем по умолчанию оно ставится в false. Так что в новой версии проблем вообще не будет. А в старой проблема решается ручной правкой проектного файла.
Z>Едиственный воркэраунд который я нашел — включение компилятора и необходимых сборок прямо в проект. Но с nrails и этот способ не катит.
Ты профильтровал все мои слова и снова гнешь свою, в корне ошибочную, линию. Я просто таки поражен!
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Ты профильтровал все мои слова и снова гнешь свою, в корне ошибочную, линию. Я просто таки поражен!
Я тебе описываю свои личные проблемы в продакшене. Тебе бы прислушаться, ан нет.
Естественно я знаю про specific version. Это влияет только на процесс сборки. После компиляции, ссылка на сборку становится строгой (именно на ту версию с которой была скомпилирована), ее уже не заменишь так просто (только директивы в app.config).
Соответственно, чтобы подключать те же миграции из нрельс, надо либо тащить нрельсы с исходником либо держать у всех разработчиков одну версию немерла и апдейтить ее одновременно. При этом апдейте перекомпилировать бинарные зависимости.
Я сейчас тупо тащу сборку nrails вместе с немерлом которым она была собрана и собираю сами миграции им же. Даже если у разработчика не та версия или вообще нет немерла, сборка проходит успешно, хоть и проект не открывается в студии.
Текущая политика в корне обрубает возможности распространения скомпиленных сборок. Шансов, что у получателя будет ровно та же версия Nemerle очень мало. Сейчас она остро не стоит просто потому, что почти все публичные сборки которые написаны на nemerle поставляются вместе с компилятором. Деплоить же какой-то пакет в тот же nuget совершенно бессмысленно.
Здравствуйте, Ziaw, Вы писали:
Z>Здравствуйте, VladD2, Вы писали:
VD>>Ты профильтровал все мои слова и снова гнешь свою, в корне ошибочную, линию. Я просто таки поражен!
Z>Я тебе описываю свои личные проблемы в продакшене. Тебе бы прислушаться, ан нет.
К чему прислушаться то? У меня нет ни малейшего сомнения, что ты не прав. Версия сборки обязана отражать ее содержимое. Если публичный интерфейс изменился, то мы обязаны менять версию сборки. Иначе глюки будут такими, что твои проблемы покажутся детским лепетом.
Это любой квалифицированный специалист в области разработки ПО должен понимать. И я просто фигею с того, что ты это не понимаешь. Вроде же весьма продвинутый программист же.
"Проблемы" же твои решаются банальным вычищением информации о версиях сборки. В интеграции C# по умолчанию так и делается. По этому ты и не испытываешь проблем.
В новой версии мы так же реализовали эту фичи. Так что впредь проблем не будет.
Так что обсуждать в общем-то нечего.
Z>Естественно я знаю про specific version. Это влияет только на процесс сборки. После компиляции, ссылка на сборку становится строгой (именно на ту версию с которой была скомпилирована), ее уже не заменишь так просто (только директивы в app.config).
Естественно! И это благо! Приложение должно работать со сборками проверенными на стадии компиляции. Иначе, рано или поздно, ты нарвешься на дикие и не объяснимые проблемы.
Хочешь химичить с версиями? Рисуй кофиги и описывай в них, что твоя сборка может работать с любой версии сборок. Но ты хотя бы будешь знать об этом.
Ты же предлагаешь сделать так, чтобы никто даже не смог узнать, что его приложение потенциально не работоспособно.
Это совершенно не корректно и я на такое пойти не могу.
Z>Соответственно, чтобы подключать те же миграции из нрельс, надо либо тащить нрельсы с исходником либо держать у всех разработчиков одну версию немерла и апдейтить ее одновременно. При этом апдейте перекомпилировать бинарные зависимости.
Ты можешь:
1. Тупо деражть исходники НРельсов и пересобирать их.
2. Можешь описать конфиги котоыре позволят обойти версионность и полагатьс на свой страх и риск.
3. Создать каталог зависимостей и положить туда нужные сборки (держать компилятор, как ты это называешь).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
Z>>Я тебе описываю свои личные проблемы в продакшене. Тебе бы прислушаться, ан нет.
VD>К чему прислушаться то? У меня нет ни малейшего сомнения, что ты не прав.
В чем я не прав-то? Я всего лишь озвучил проблемы. Ты их не имеешь, ибо у тебя один проект на немерле и этот проект последняя версия компилятора. У тебя там нет и не может быть никаких конфликтов.
VD>Версия сборки обязана отражать ее содержимое. Если публичный интерфейс изменился, то мы обязаны менять версию сборки. Иначе глюки будут такими, что твои проблемы покажутся детским лепетом.
Совершенно верно. Публичный контракт. Сейчас версия отражает номер комита в репозитарии. Эту пролему я и предлагаю решать.
VD>Это любой квалифицированный специалист в области разработки ПО должен понимать. И я просто фигею с того, что ты это не понимаешь. Вроде же весьма продвинутый программист же.
У тебя неприятная черта, выставлять идиотом любого несогласного с тобой человека, вместо того, чтобы попытаться понять его точку зрения.
VD>"Проблемы" же твои решаются банальным вычищением информации о версиях сборки. В интеграции C# по умолчанию так и делается. По этому ты и не испытываешь проблем.
Не прикидывайся наивнее чем ты есть, ты прекрасно понял, в чем проблема и она не решается так. Ни в Nemerle ни в C#.
Z>>Соответственно, чтобы подключать те же миграции из нрельс, надо либо тащить нрельсы с исходником либо держать у всех разработчиков одну версию немерла и апдейтить ее одновременно. При этом апдейте перекомпилировать бинарные зависимости.
VD>Ты можешь: VD>1. Тупо деражть исходники НРельсов и пересобирать их.
Это банально неудобно.
VD>2. Можешь описать конфиги котоыре позволят обойти версионность и полагатьс на свой страх и риск.
Это багодром и вообще, конфиги приложений это не то место где должны решаться вопросы зависимостей.
VD>3. Создать каталог зависимостей и положить туда нужные сборки (держать компилятор, как ты это называешь).
Так и делаю. Только тоже неудобно. С какой целью ты привел мне в ответ все три моих-же костыльных решения проблемы? Я их описал постом выше, а ты мне тут же их выдаешь под соусом откровения: нет никаких проблем, есть целых три решения.
Глобальная проблема то в том, что нельзя распространять бинарники приложений. И ее надо как-то решать.
Здравствуйте, Ziaw, Вы писали:
Z>Здравствуйте, VladD2, Вы писали:
VD>>А можно узнать с чем товарищ, поставивший минус, не согласен?
Z>Я минус не ставил, но меня тоже напрягает использование немерла в продакшене тем, что сборки постоянно меняют версию. По сути необходимо всем разработчикам держать одну и ту же версию и обновляться синхронно. Если что, твои доводы по поводу dll hell мне знакомы. Только я получаю dll hell именно в текущем раскладе.
Z>Едиственный воркэраунд который я нашел — включение компилятора и необходимых сборок прямо в проект. Но с nrails и этот способ не катит.
Здравствуйте, Ziaw, Вы писали:
VD>>Ты можешь: VD>>1. Тупо деражть исходники НРельсов и пересобирать их.
Z>Это банально неудобно.
Это нормально и безопасно. Что там неудобного я понять не могу.
VD>>2. Можешь описать конфиги котоыре позволят обойти версионность и полагатьс на свой страх и риск.
Z>Это багодром и вообще, конфиги приложений это не то место где должны решаться вопросы зависимостей.
Конечно багодром! Но локальный. А ты предлагаешь сделать его глобальным. Чтобы уж никто и никогда не смог понять, почему у него ни черта не работает.
Z>Глобальная проблема то в том, что нельзя распространять бинарники приложений. И ее надо как-то решать.
Да причем тут распространение приложений? С приложением должны идти те версии библиотек с которыми они были собраны. Для немерла по умолчанию это всего лишь Nemerle.dll.
Давай, как ты опишешь свою ситуацию и по подробнее. А то, может быть, я просто не ее понимаю.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>>>1. Тупо деражть исходники НРельсов и пересобирать их.
Z>>Это банально неудобно.
VD>Это нормально и безопасно. Что там неудобного я понять не могу.
То же, что и включать любую другую либу в исходниках. Попробуй засунуть исходники nunit в каждый снипет который его использует и тебе сразу станет понятно.
VD>>>2. Можешь описать конфиги котоыре позволят обойти версионность и полагатьс на свой страх и риск.
Z>>Это багодром и вообще, конфиги приложений это не то место где должны решаться вопросы зависимостей.
VD>Конечно багодром! Но локальный. А ты предлагаешь сделать его глобальным. Чтобы уж никто и никогда не смог понять, почему у него ни черта не работает.
Не мог бы ты наконец озвучить то, что я по твоему мнению, предлагаю? Я пока просто описываю проблему и предлагаю подумать над ее решением. Оно врядли может быть чисто техническим.
Z>>Глобальная проблема то в том, что нельзя распространять бинарники приложений. И ее надо как-то решать.
VD>Да причем тут распространение приложений? С приложением должны идти те версии библиотек с которыми они были собраны. Для немерла по умолчанию это всего лишь Nemerle.dll.
Тут опечатка. Имелись ввиду бинарники бибилиотек.
VD>Давай, как ты опишешь свою ситуацию и по подробнее. А то, может быть, я просто не ее понимаю.
Ситуация простая. Вот у меня в проекте управление схемой бд с помощью миграций нрельсовых миграций. Выходит новая версия немерла и интеграции. И сборка с самими миграциями в проекте перестает собираться, ибо сборка NRails.Migrations ссылается на Nemerle.dll с которой были собраны NRails.Migrations, а сами миграции собираются уже с новой версией Nemerle.dll.
Мне приходится ребилдить NRails.Migrations в новой версии и засовывать ее в contrib своего проекта. После этого, солюшен перестает билдиться у моих коллег, которые не обновили немерл. И им приходится обновлять его тоже, что совсем не добавляет радости от его использования. Вдобавок я должен делиться с кем-то знанием где взять и как сбилдить nrails.
Сейчас я просто кладу весь немерл в контриб и билжу им. Что позволяет собрать проект мсбилдом без установки немерла и обойтись минимальными проблемами при более старой интеграции.
Здравствуйте, gandjustas, Вы писали:
Z>>Едиственный воркэраунд который я нашел — включение компилятора и необходимых сборок прямо в проект. Но с nrails и этот способ не катит.
G>А binding redirect не?
Здравствуйте, Ziaw, Вы писали:
Z>Здравствуйте, gandjustas, Вы писали:
Z>>>Едиственный воркэраунд который я нашел — включение компилятора и необходимых сборок прямо в проект. Но с nrails и этот способ не катит.
G>>А binding redirect не?
Z>Не. Тут не поможет.
Здравствуйте, Ziaw, Вы писали:
Z>То же, что и включать любую другую либу в исходниках. Попробуй засунуть исходники nunit в каждый снипет который его использует и тебе сразу станет понятно.
NUnit — это не только библиотека, но и приложение.
Его, конечно, удобнее включать в виде бинарников. Что мы и делаем.
Но ты почему-то не возмущаешься на счет того, что у в каждой новой версии NUnit версии сборок изменяются?
VD>>Конечно багодром! Но локальный. А ты предлагаешь сделать его глобальным. Чтобы уж никто и никогда не смог понять, почему у него ни черта не работает.
Z>Не мог бы ты наконец озвучить то, что я по твоему мнению, предлагаю?
Может быть лучше это сделаешь ты?
Как я понял, ты предлагаешь зафиксировать версии сборок. Причем без малейшей аргументации и плюя на реальные аргументы.
Z>Я пока просто описываю проблему и предлагаю подумать над ее решением. Оно врядли может быть чисто техническим.
Тебе предложили сразу три решения. Других решений нет. Почему-то когда речь идет о независимых библиотеках, ты спокойно выбираешь одно из них. А в нашем случае — нет.
Z>Тут опечатка. Имелись ввиду бинарники бибилиотек.
А в чем тут проблема то? Мешает зависимость от Nemerle.dll?
Не проще ли, в таком случае, просто отказаться от ее использования и вместо нее использовать исходники стандартной библиотеки, подключая их непосредственно к проекту?
Z>Ситуация простая. Вот у меня в проекте управление схемой бд с помощью миграций нрельсовых миграций. Выходит новая версия немерла и интеграции. И сборка с самими миграциями в проекте перестает собираться, ибо сборка NRails.Migrations ссылается на Nemerle.dll с которой были собраны NRails.Migrations, а сами миграции собираются уже с новой версией Nemerle.dll.
Z>Мне приходится ребилдить NRails.Migrations в новой версии и засовывать ее в contrib своего проекта. После этого, солюшен перестает билдиться у моих коллег, которые не обновили немерл. И им приходится обновлять его тоже, что совсем не добавляет радости от его использования. Вдобавок я должен делиться с кем-то знанием где взять и как сбилдить nrails.
Z>Сейчас я просто кладу весь немерл в контриб и билжу им. Что позволяет собрать проект мсбилдом без установки немерла и обойтись минимальными проблемами при более старой интеграции.
Давай начнем с включения нужных тебе исходников составляющих Nemerle.dll в твой проект. Мне кажется — это самое простое решение. Расплатой за это будет замедление компиляции проекта (на время компиляции исходников Nemerle.dll).
Зафиксировать версию Nemerle.dll мы не можем. Даже если мы не будем менять ее в случае отсутствия изменений в исходниках Nemerle.dll, то рано или поздно они изменятся и версия так же изменится.
Так же тебе стоило бы попробовать вариант с конфигами.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Но ты почему-то не возмущаешься на счет того, что у в каждой новой версии NUnit версии сборок изменяются?
Не возмущаюсь, потому, что менять приходится только ссылки на nunit. Если мне придется вдобавок менять окружение всей команде, я буду возмущаться.
Z>>Не мог бы ты наконец озвучить то, что я по твоему мнению, предлагаю?
VD>Может быть лучше это сделаешь ты?
В том то и дело, что я пока еще ничего не предлагал. А ты уже сделал выводы:
VD>Как я понял, ты предлагаешь зафиксировать версии сборок. Причем без малейшей аргументации и плюя на реальные аргументы.
Неверные выводы о моих предложениях на ровном месте.
Z>>Я пока просто описываю проблему и предлагаю подумать над ее решением. Оно врядли может быть чисто техническим.
VD>Тебе предложили сразу три решения. Других решений нет. Почему-то когда речь идет о независимых библиотеках, ты спокойно выбираешь одно из них. А в нашем случае — нет.
Да я и сам нашел все эти решения и их же озвучил. Не пойму зачем ты мне их предложил в ответ.
VD>А в чем тут проблема то? Мешает зависимость от Nemerle.dll?
И от Nemerle.Compiler.dll.
VD>Давай начнем с включения нужных тебе исходников составляющих Nemerle.dll в твой проект. Мне кажется — это самое простое решение. Расплатой за это будет замедление компиляции проекта (на время компиляции исходников Nemerle.dll).
Меня с трудом поняли коллеги, когда я притащил немерловые миграции. В солюшене появился проект с миграциями на другом языке. Надо всем донастраивать окружение. Неудобно, но вроде всем понятно, зачем этот проект. А теперь ты предлагаешь включить туда еще исходники nrails и стандартной библиотеки немерла. Что сравнимо с кодовой базой проекта вообще, а по времени компиляции, так и превосходит.
Да и вообще, как я включу исходники Nemerle.dll в nrails? Как их мейнтейнить? Как потом использовать nrails из немерловых проектов? Там же будут конфликты со стандартной либой. Абсолютно неработоспособное решение.
VD>Зафиксировать версию Nemerle.dll мы не можем. Даже если мы не будем менять ее в случае отсутствия изменений в исходниках Nemerle.dll, то рано или поздно они изменятся и версия так же изменится.
Ну так она не будет меняться на каждый комит и мне не придется ребилдить зависимости чаще чем это реально требуется. Лучшим выходом было бы фиксировать версию и публичный API на каждый минорный релиз. Обновлять все раз в полгода я не против. Если это сейчас невозможно, надо думать о том, как сделать так, чтобы стало возможно.
Пойми, пока не решена эта проблема, нет смысла патчить nuget для поддержки немерла. Ибо создавать либы на nemerle сейчас нет никакого смысла. Они могут быть использованы только с конкретной версией компилятора.
