Здравствуйте, Ka3a4oK, Вы писали:
KK>Я просто делал ад референс. Затем выбирал папку с немерле, выбирал нужную сборку и нажимал ок.
Ну, так и погляди что в файле проекта получилось.
VD>>Скорее всего там была указана полная версия. В этом случае, имеет смысл открыть свойства ссылок на сборки и установить свойство Specific Version в false.
KK>Нет такого свойства.
Возможно мы эту фичу только для VS2010 реализовали. Или это не поддерживалось в старой версии.
Тогда ссылки можно поправить только прямы редактированием проектного файла. Убери все что относится к версиям и пропиши пути через $(Nemerle).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Поставил немерле для 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.
Здравствуйте, 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 сейчас нет никакого смысла. Они могут быть использованы только с конкретной версией компилятора.
Здравствуйте, Ziaw, Вы писали:
Z>В том то и дело, что я пока еще ничего не предлагал. А ты уже сделал выводы:
VD>>Как я понял, ты предлагаешь зафиксировать версии сборок. Причем без малейшей аргументации и плюя на реальные аргументы.
О, как? А кто же предлагал зафиксировать версии немерловых сборок?
Z>Неверные выводы о моих предложениях на ровном месте.
А можно тогда описать свои предложения. Ну, так чтобы и до тупых вроде меня дошло?
VD>>А в чем тут проблема то? Мешает зависимость от Nemerle.dll?
Z>И от Nemerle.Compiler.dll.
Это как? От нее же только макросы должны зависеть.
Z>Меня с трудом поняли коллеги, когда я притащил немерловые миграции. В солюшене появился проект с миграциями на другом языке. Надо всем донастраивать окружение. Неудобно, но вроде всем понятно, зачем этот проект. А теперь ты предлагаешь включить туда еще исходники nrails и стандартной библиотеки немерла. Что сравнимо с кодовой базой проекта вообще, а по времени компиляции, так и превосходит.
Я нечего не понимаю. Зачем влючать исходники утилиты?
Z>Да и вообще, как я включу исходники Nemerle.dll в nrails?
Создаешь каталог, копируешь туда исходники и включаешь каталог в проект.
Z>Как их мейнтейнить?
Прости, что?
Z>Как потом использовать nrails из немерловых проектов? Там же будут конфликты со стандартной либой. Абсолютно неработоспособное решение.
Дык твоя библиотека и будет экспотировать все нужные функции.
Как вариант, можно простеньким макросом махнуть все public-и на internal и тогда все импортируемые типы будут локальны для проекта.
Z>Ну так она не будет меняться на каждый комит и мне не придется ребилдить зависимости чаще чем это реально требуется. Лучшим выходом было бы фиксировать версию и публичный API на каждый минорный релиз. Обновлять все раз в полгода я не против. Если это сейчас невозможно, надо думать о том, как сделать так, чтобы стало возможно.
Nemerle.Compiler.dll, о зависимости от которой ты писал выше, меняется чуть ли ни каждый день. Не всегда меняется публичный интерфейс, но как это определить?
И вообще, как ты себе видишь реализацию этой идеи? Как определить, что в сборке что-то изменилось и ей нужно менять ее версию?
Ты вручную предлагаешь это делать?
Z>Пойми, пока не решена эта проблема, нет смысла патчить nuget для поддержки немерла. Ибо создавать либы на nemerle сейчас нет никакого смысла. Они могут быть использованы только с конкретной версией компилятора.
Ну, придумай как программно определить, что изменился публичный интерфейс. Тогда можно будет менять версии только при его изменении.
Но, по-моему, проще включать исходники Nemerle.dll в состав таких библиотек.
Написать макрос который будет менять все public-и на internal-ы для конкретного каталога — это задача на пол часа.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>А можно тогда описать свои предложения. Ну, так чтобы и до тупых вроде меня дошло?
Для начала предлагаю признать, что проблема существует. А не отмахиваться кучей костылей, которые ее якобы решают.
VD>>>А в чем тут проблема то? Мешает зависимость от Nemerle.dll?
Z>>И от Nemerle.Compiler.dll.
VD>Это как? От нее же только макросы должны зависеть.
nrails умеет компилировать миграции и компилировать спарковские вьюхи. Макросы там, опять же, присутствуют.
Z>>Меня с трудом поняли коллеги, когда я притащил немерловые миграции. В солюшене появился проект с миграциями на другом языке. Надо всем донастраивать окружение. Неудобно, но вроде всем понятно, зачем этот проект. А теперь ты предлагаешь включить туда еще исходники nrails и стандартной библиотеки немерла. Что сравнимо с кодовой базой проекта вообще, а по времени компиляции, так и превосходит.
VD>Я нечего не понимаю. Зачем влючать исходники утилиты?
Какой утилиты? Миграции это сборка, исходники для которой активно правятся. Сборку надо собирать и запускать как вручную, так и из основного проекта, в процессе апгрейда версии. Эта сборка ссылается на nrails.dll, и использует nrails.macros.dll при компиляции. Те, в свою очередь ссылаются на Nemerle.dll и Nemerle.Macros.dll.
VD>Создаешь каталог, копируешь туда исходники и включаешь каталог в проект.
Z>>Как их мейнтейнить?
VD>Прости, что?
Поддерживать. Вот исправили какой-то баг в стандартной либе, я что должен делать? Но это даже не главное, о главном ниже.
VD>Дык твоя библиотека и будет экспотировать все нужные функции.
Так они будут несовместимы с Nemerle.dll. Вот отсюда я уже не получу свой list.
VD>Как вариант, можно простеньким макросом махнуть все public-и на internal и тогда все импортируемые типы будут локальны для проекта.
Но их невозможно будет использовать совместно с типами из Nemerle.dll. Мне нужна возможность писать на nemerle библиотеки/макросы, которые (в скомпилированном виде) можно использовать в других проектах более чем в одной версии компилятора.
VD>Nemerle.Compiler.dll, о зависимости от которой ты писал выше, меняется чуть ли ни каждый день. Не всегда меняется публичный интерфейс, но как это определить? VD>И вообще, как ты себе видишь реализацию этой идеи? Как определить, что в сборке что-то изменилось и ей нужно менять ее версию?
Слава богу, пошел конструктивный разговор. Как вариант — тест на эталонную сборку. Как только выходит минорная бэта, создается ветка для ее багфиксов, в нее кладутся выложенные сборки и включатеся тест, который сличает публичные интерфейсы. В билдскрипты ревизия прописыватеся жестко. В этой ветке правятся баги, она же регулярно мерджится в мастер. Релизы выкатываются из нее. В мастер же комитятся и мерджатся новые фичи. Это сырой вариант схемы, если в нем что-то не нравится, давай обсуждать.
Здравствуйте, Ziaw, Вы писали:
Z>Для начала предлагаю признать, что проблема существует. А не отмахиваться кучей костылей, которые ее якобы решают.
Да, я что против что ли? Такая проблема будет существовать с любой библиотечной сборкой дотнета используемой в нескольких проектах одновременно.
Звучит она просто — к одному приложению нельзя подключить две разные версии одной сборки (даже опосредованно).
Z>nrails умеет компилировать миграции и компилировать спарковские вьюхи. Макросы там, опять же, присутствуют.
Макросы не входят во внешние зависимости. По крайней мере не должны. Они же только для компиляции нужны.
Если у тебя есть импорт типов из макро-сборок, то это уже твоя вина. Подключи их как макро-референсы и избавься от зависимости по типам.
Z>>>Меня с трудом поняли коллеги, когда я притащил немерловые миграции. В солюшене появился проект с миграциями на другом языке. Надо всем донастраивать окружение. Неудобно, но вроде всем понятно, зачем этот проект. А теперь ты предлагаешь включить туда еще исходники nrails и стандартной библиотеки немерла. Что сравнимо с кодовой базой проекта вообще, а по времени компиляции, так и превосходит.
VD>>Я нечего не понимаю. Зачем влючать исходники утилиты?
Z>Какой утилиты? Миграции это сборка, исходники для которой активно правятся. Сборку надо собирать и запускать как вручную, так и из основного проекта, в процессе апгрейда версии. Эта сборка ссылается на nrails.dll, и использует nrails.macros.dll при компиляции. Те, в свою очередь ссылаются на Nemerle.dll и Nemerle.Macros.dll.
Ну, так получается, что все же от нее ничего не зависит. Так?
Тогда для нее можно иметь свои зависимости (сборки компилятора).
VD>>Создаешь каталог, копируешь туда исходники и включаешь каталог в проект. Z>>>Как их мейнтейнить? VD>>Прости, что?
Z>Поддерживать. Вот исправили какой-то баг в стандартной либе, я что должен делать? Но это даже не главное, о главном ниже.
Скопировать исходники из одного каталога в другой и пересобрать проект.
VD>>Дык твоя библиотека и будет экспотировать все нужные функции.
Z>Так они будут несовместимы с Nemerle.dll. Вот отсюда я уже не получу свой list.
Это — да. Придется и эти исходники включать к себе в проект.
Z>Слава богу, пошел конструктивный разговор. Как вариант — тест на эталонную сборку. Как только выходит минорная бэта, создается ветка для ее багфиксов, в нее кладутся выложенные сборки и включатеся тест, который сличает публичные интерфейсы. В билдскрипты ревизия прописыватеся жестко. В этой ветке правятся баги, она же регулярно мерджится в мастер. Релизы выкатываются из нее. В мастер же комитятся и мерджатся новые фичи. Это сырой вариант схемы, если в нем что-то не нравится, давай обсуждать.
Не, не не. Минорная, мажорная, ветка, закладывается и другая рукопашная фигня меня не устраивает. Я тебе уже много раз говорил — нужен автомат.
И я не вижу как это сделать. Закладываться на какое-то там рукопашное закладывание сборок и, тем более, ручную замену версий нельзя. Это неминуемо приведет к проблемам.
Чтобы твоя схема взлетела нам нужно иметь целый отряд который только реализами и будет заниматься. Мы не МС, так что отряда явно не будет. Так что нужно искать выход по проще.
Как вариант, можно рассмотреть следующее...
Компилируем Nemerle.dll в два прохода. После первого сравниваем (через рефлексию) публичный интерфейс новой сборки с той что лежит в boot-е. Если публичный интерфейс сходится, то просто копируем получившуюся сборку (со старой версией) в оутпут второго прохода. Если же публичный интерфейс изменился, производим повторную компиляцию этой сборки. При этом она получает новую версию (полученную путем икремента на единицу версии сборки из boot-а). Далее копируем полученную сборку в бут.
За одно это автоматизирует обновление бута.
В принципе тоже самое можно делать из с Nemerle.Compiler.dll. Но вот с библиотеками вроде Nemerle.Linq.dll Nemerle.Peg.dll ComputationExpressions.dll — это не прокатит, так как они не хранятся в буте.
Опять же кому-то нужно заняться реализацией — этого (не самого простого) алгоритма. Возьмешься?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Макросы не входят во внешние зависимости. По крайней мере не должны. Они же только для компиляции нужны.
VD>Если у тебя есть импорт типов из макро-сборок, то это уже твоя вина. Подключи их как макро-референсы и избавься от зависимости по типам.
Все кругом у тебя виноваты, лишь бы не лезли с проблемами. Макросборка использует типы из Nemerle.dll из той Nemerle.dll с которой она была собрана. А выполняется она компилятором, у которого своя Nemerle.dll.
VD>Это — да. Придется и эти исходники включать к себе в проект.
Я вижу ты уже понял основную проблему. Разработчик библиотеки просто в тупике. Либо включать весь немерл себе в проект в исходниках, и обязывать пользователей своей библотеки отключать стандартную библиотеку в их собственных приложениях. Либо распостранять свою либу в исходниках и требовать пользователей пересобирать ее при каждом апгрейде компилятора.
VD>Не, не не. Минорная, мажорная, ветка, закладывается и другая рукопашная фигня меня не устраивает. Я тебе уже много раз говорил — нужен автомат.
Здравствуйте, Ziaw, Вы писали:
Z>Все кругом у тебя виноваты, лишь бы не лезли с проблемами.
Справедливости ради, это проблема не только немерла, но и всех компиляторов под .нет. Но тут она усугубляется тем, что немерле чуть ли не раз в неделю обновляется (в отличии от, допустим, C#, который обновляется раз в два года), и макросами.
Здравствуйте, catbert, Вы писали:
C>Справедливости ради, это проблема не только немерла, но и всех компиляторов под .нет. Но тут она усугубляется тем, что немерле чуть ли не раз в неделю обновляется (в отличии от, допустим, C#, который обновляется раз в два года), и макросами.
Угу. Обновляется, а стабильной ветки, в которой только багфиксы, не имеет. Сервиспаки на фреймворк выходили между версиями. Но они не меняли версии сборок.
Здравствуйте, Ziaw, Вы писали:
C>>Справедливости ради, это проблема не только немерла, но и всех компиляторов под .нет. Но тут она усугубляется тем, что немерле чуть ли не раз в неделю обновляется (в отличии от, допустим, C#, который обновляется раз в два года), и макросами.
Z>Угу. Обновляется, а стабильной ветки, в которой только багфиксы, не имеет. Сервиспаки на фреймворк выходили между версиями. Но они не меняли версии сборок.
При любом сервис-паке приходится перекомпилировать проект. А при смене версий народ по году перейти между ними не может. Так что с немерлом все даже намного проще.
А то что что-то там обновляется раз в неделю, так ты не обязан эти изменения качать. Релизы у немерла тоже не часто бывают. Если среди изменений нет жизненно необходимых для тебя, так просто используй старую версию.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Ziaw, Вы писали:
Z>Здравствуйте, VladD2, Вы писали:
VD>>Макросы не входят во внешние зависимости. По крайней мере не должны. Они же только для компиляции нужны.
VD>>Если у тебя есть импорт типов из макро-сборок, то это уже твоя вина. Подключи их как макро-референсы и избавься от зависимости по типам.
Z>Все кругом у тебя виноваты, лишь бы не лезли с проблемами.
А ты хочешь чтобы я был виноват во всех внешних проблемах? Может ты меня и во внешней политике США обвинишь?
Z>Макросборка использует типы из Nemerle.dll из той Nemerle.dll с которой она была собрана.
Макра-сборка по любому должна быть той версии что и компилятор. Но твои конечные длл-и от этого никак не зависят.
Z>А выполняется она компилятором, у которого своя Nemerle.dll.
Ну, дык, а что ты хочешь то? Макросбрка плотно связана с компилятором. Она не может жить с другой версией стандартных библиотек.
VD>>Это — да. Придется и эти исходники включать к себе в проект.
Z>Я вижу ты уже понял основную проблему. Разработчик библиотеки просто в тупике. Либо включать весь немерл себе в проект в исходниках, и обязывать пользователей своей библотеки отключать стандартную библиотеку в их собственных приложениях. Либо распостранять свою либу в исходниках и требовать пользователей пересобирать ее при каждом апгрейде компилятора.
Мне кажется второй способ, в условиях постоянного обновления компилятора — это самый удобный и правильный выход из ситуации.
Второй разумный выход — не брать новую версию компилятора по утрам. Устраивает тебя текущая версия? Ну, так и используй ее. Будет официальный релиз (ну, хотя бы бэта официальная) — то и обновишь компилятор и перекомпилируешь все библиотеки.
VD>>Не, не не. Минорная, мажорная, ветка, закладывается и другая рукопашная фигня меня не устраивает. Я тебе уже много раз говорил — нужен автомат.
Z>
Я лучше слова понимаю. Что значит этот смайлик я не понимаю.
Я тебя прямо и ответственно заявляю, что никакой ручной работой по сборке и публикации я заниматься не буду. У меня и так времени ни на что не хватает, а здоровье уже дышит наладом, из-за того, что вместо сна я немерлом занимаюсь.
Кочеткову тоже времени не хватает. Он даже запланированные изменения не успевает сделать.
Так просто пойми — никто не против идеи менять версии сборок только при изменении публичного интерфейса. Но требуется чтобы это происходило автоматом. Раз эта задача тебе нужна больше чем остальным, то берись за нее. Продумай как все сделать просто и качественно и реализуй. Если найдутся помощники, то вообще прекрасно. Уверен, что с технической точки зрения задача решается. Вопрос только в усилиях по ее продумыванию и реализации.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
Z>>Угу. Обновляется, а стабильной ветки, в которой только багфиксы, не имеет. Сервиспаки на фреймворк выходили между версиями. Но они не меняли версии сборок.
VD>При любом сервис-паке приходится перекомпилировать проект. А при смене версий народ по году перейти между ними не может. Так что с немерлом все даже намного проще.
Не надо ничего перекомпилировать. Все отлично работает и без этого.
VD>А то что что-то там обновляется раз в неделю, так ты не обязан эти изменения качать. Релизы у немерла тоже не часто бывают. Если среди изменений нет жизненно необходимых для тебя, так просто используй старую версию.
Здравствуйте, VladD2, Вы писали:
Z>>Все кругом у тебя виноваты, лишь бы не лезли с проблемами.
VD>А ты хочешь чтобы я был виноват во всех внешних проблемах? Может ты меня и во внешней политике США обвинишь?
У тебя очень полярный взгляд на вещи.
VD>Макра-сборка по любому должна быть той версии что и компилятор. Но твои конечные длл-и от этого никак не зависят.
Тогда я не пойму, зачем ты их выделяешь из общего списка.
VD>Мне кажется второй способ, в условиях постоянного обновления компилятора — это самый удобный и правильный выход из ситуации.
VD>Второй разумный выход — не брать новую версию компилятора по утрам. Устраивает тебя текущая версия? Ну, так и используй ее. Будет официальный релиз (ну, хотя бы бэта официальная) — то и обновишь компилятор и перекомпилируешь все библиотеки.
Мысль ясна. В таком случае нет никакого смысла писать опенсорсные либы типа nrails. Подключать их в каждый проект в исходниках удовольствие ниже плинтуса.
Z>>
VD>Я лучше слова понимаю. Что значит этот смайлик я не понимаю.
Развожу руками, что мне остается?
VD>Так просто пойми — никто не против идеи менять версии сборок только при изменении публичного интерфейса. Но требуется чтобы это происходило автоматом. Раз эта задача тебе нужна больше чем остальным, то берись за нее. Продумай как все сделать просто и качественно и реализуй. Если найдутся помощники, то вообще прекрасно. Уверен, что с технической точки зрения задача решается. Вопрос только в усилиях по ее продумыванию и реализации.
Влад, это управление релизами. Его еще никто не смог автоматизировать. Нужно багфиксы делать в одной ветке, а фичи в другой. Никакая автоматизация этого не решит, все что она может, это сказать, что публичный интерфейс изменен. Я понимаю, что хочется просто писать код и ни о чем больше не думать.
Здравствуйте, Ziaw, Вы писали:
VD>>А ты хочешь чтобы я был виноват во всех внешних проблемах? Может ты меня и во внешней политике США обвинишь?
Z>У тебя очень полярный взгляд на вещи.
Что значит "полярный"?
VD>>Макра-сборка по любому должна быть той версии что и компилятор. Но твои конечные длл-и от этого никак не зависят.
Z>Тогда я не пойму, зачем ты их выделяешь из общего списка.
Из какого списка? Просто твои ДЛЛ-и не должны зависеть от версии Nemerle.Compiler.dll. От нее должны зависеть только макро-сборки.
VD>>Мне кажется второй способ, в условиях постоянного обновления компилятора — это самый удобный и правильный выход из ситуации.
VD>>Второй разумный выход — не брать новую версию компилятора по утрам. Устраивает тебя текущая версия? Ну, так и используй ее. Будет официальный релиз (ну, хотя бы бэта официальная) — то и обновишь компилятор и перекомпилируешь все библиотеки.
Z>Мысль ясна. В таком случае нет никакого смысла писать опенсорсные либы типа nrails. Подключать их в каждый проект в исходниках удовольствие ниже плинтуса.
Отличный вывод! Логика железная!
Z>Развожу руками, что мне остается?
Ну, можно взять и сделать как удобнее тебе и хорошо другим.
Идея тупо не менять версии — плохая. Надеюсь ты это понимаешь. Идея менять версии при изменении публичного интерфейса — хорошая, но требующая реализации.
Так почему бы вместо того чтобы обвинять меня в том, что я никогда не делал, не взяться за реализацию правильного решения?
VD>>Так просто пойми — никто не против идеи менять версии сборок только при изменении публичного интерфейса. Но требуется чтобы это происходило автоматом. Раз эта задача тебе нужна больше чем остальным, то берись за нее. Продумай как все сделать просто и качественно и реализуй. Если найдутся помощники, то вообще прекрасно. Уверен, что с технической точки зрения задача решается. Вопрос только в усилиях по ее продумыванию и реализации.
Z>Влад, это управление релизами. Его еще никто не смог автоматизировать.
Ерунду то не говори.
Z>Нужно багфиксы делать в одной ветке, а фичи в другой. Никакая автоматизация этого не решит, все что она может, это сказать, что публичный интерфейс изменен. Я понимаю, что хочется просто писать код и ни о чем больше не думать.
Ну, берись вручную управлять релизами. Будешь сам делать инсталляторы, следить за версиями и т.п. До тех пор пока ты этим будешь заниматься будем выпускать все вручную. Боюсь, что ты этим прозанимаешься примерно неделю. А дальше бросишь.
На себя я такие обязанности взваливать не собираюсь. Это займет 100% моего, и так недостаточного, времени.
Пойми — в наших условиях, некоммерческой разработки малыми силами, мы и так делаем больше чем можем. Чтобы при таких ресурсах обеспечивать надлежащее качество в приемлемые сроки мы обязаны автоматизировать все что возможно.
Выпуск реализов — это то что можно и нужно автоматизировать. Если мы будем делать их все время вручную, то в них банально не будет чего включать.
По сему чем критиковать, сам не знаешь чего, лучше помоги сделать добротную автоматизацию.
ЗЫ
Что касается Майкрософта... У них реализы равз в год, а то и реже. Любая новая версия вызывает не просто перекомпиляцию, а серьезнейшие проблемы у кучи народа. Многие годами не могут перейти на новый фрймворк, даже когда сам рантайм не изменялся (2.0, 3.0, 3.5 имеют один рантайм).
Мы можем пойти по тому же пути и тогда можно будет обеспечивать ручное управление выпусками. Но будет ли это преимуществом? Уверен, что нет. И большая часть людей предпочтет перекомпилировать свои библиотеки, но не ждать исправлений годами.
Так же уверен, что в МС есть система контроля изменения публичного интерфейса, которая и позволяет вести несущественные изменения. Плюс, скорее всего, при релизе там тупо дублируют репозиторий и ведут их отдельно, так как много раз видел как в новых версиях продуктов МС были те же ошибки, что были испрвлены в фиксах или сервиспаках к предыдущим версиям. Мы так делать не можем. Далеть же мерджи из одной ветки в другую можно до первого серьезного рефакторинга. Далее или нужно синхронизировать обе ветки (что убьет совместимость интерфейса), или полностью разделять репозитории.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
