Есть пара библиотечек на .нет — некое API для того чтоб клиенты девелопили с его помощью свои приложения.
Не могу решить, как оптимально их поставлять, а именно:
— использовать ли GAC.
Если GAC не использовать, то кажется все просто, но вроде как не по правилам.
Кроме того, API может обновляться по запросу.
Если оно лежит в GAC — могут быть проблемы с версиями. (Т.е юзер как использовал версию на которой собрался в первый раз, так и продолжает, даже когда там уже лежит новая).
Кажется мне что без GAC лучше и проще, но чувствую что не совсем прав...Кто поможет аргументами за и против?
Здравствуйте, flamin, Вы писали:
F>Есть пара библиотечек на .нет — некое API для того чтоб клиенты девелопили с его помощью свои приложения.
... F>Кажется мне что без GAC лучше и проще, но чувствую что не совсем прав...Кто поможет аргументами за и против?
Скорее так: "чуствую, что без GAC лучше и проще, но кажется мне, что не совсем прав". Интуиция здесь права.
GAC, реестр стараюсь не использовать — предпочитаю чтобы все лежало в единственном месте. А если будет несколько копий — так это копейки из-за которых не стоит даже наклоняться чтобы поднять.
В книге тов. Рихтера есть замечательная глава касательно развёртывания приложений через GAC & XCopy — почитайте, возможно вы найдёте ответы на свои вопросы.
Здравствуйте, flamin, Вы писали:
F>Кажется мне что без GAC лучше и проще, но чувствую что не совсем прав...Кто поможет аргументами за и против?
Если бибилиотека будет постоянно меняться и при этом нужно чтобы всегда бралась свежая верси, но иногда приходится использовать более сарые версии, то лучше обойтись без ГАК-а.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, flamin, Вы писали:
F>Есть пара библиотечек на .нет — некое API для того чтоб клиенты девелопили с его помощью свои приложения. F>Не могу решить, как оптимально их поставлять, а именно: F>- использовать ли GAC.
F>Если GAC не использовать, то кажется все просто, но вроде как не по правилам. F>Кроме того, API может обновляться по запросу. F>Если оно лежит в GAC — могут быть проблемы с версиями. (Т.е юзер как использовал версию на которой собрался в первый раз, так и продолжает, даже когда там уже лежит новая).
F>Кажется мне что без GAC лучше и проще, но чувствую что не совсем прав...Кто поможет аргументами за и против?
Если вы хотите облегчить жизнь разработчикам, которые будут использовать вашу библиотеку, то вам следует придерживаться правил принятых для designtime размещения .Net библиотек.
— следует подписать свои библиотеки и нумеровать их версии.
— размещать библиотеки следует в двух местах: в GAC и в designtime папку, путь к которой следует указать в отдельном ключе реестра в ветке HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\AssemblyFolders. Студия просматривает эту ветку, когда формирует список доступных сборок для своего диалога "Add reference".
При обновлении библиотеки можно предерживаться двух стратегий:
— замещать старую версию сборок новой и в GAC и в designtime папке. При этом после перекомпиляции приложения будут автоматом использовать новую версию сборок вашей библиотеки. Но необходимо помнить о том, что без перекомпиляции клиентские приложения будут падать.
— выкладывать новую версию сборок в новой designtime папке и в GAC рядом со старой версией. При этом ранее скомпилированные приложения будут продолжать работать и без перекомпиляции. Но для того, чтобы приложения использовали новую версию библиотеки придется в проектах в ручную менять references.
Производители .Net компонент используют обе стратегии. Первую обычно при поставке патчей и хотфиксов, а вторую при выпуске новых версий.
S>Если вы хотите облегчить жизнь разработчикам, которые будут использовать вашу библиотеку.....
S>При обновлении библиотеки можно предерживаться двух стратегий:
.... S> — выкладывать новую версию сборок в новой designtime папке и в GAC рядом со старой версией. При этом ранее скомпилированные приложения будут продолжать работать и без перекомпиляции. Но для того, чтобы приложения использовали новую версию библиотеки придется в проектах в ручную менять references. S>Производители .Net компонент используют обе стратегии. Первую обычно при поставке патчей и хотфиксов, а вторую при выпуске новых версий.
Разъясните плс, как необходимость обновлять референсы руками облегчает жизнь разработчикам??
Какие плюсы кроме версионирования у схемы номер 2?
Здравствуйте, flamin, Вы писали:
F>Разъясните плс, как необходимость обновлять референсы руками облегчает жизнь разработчикам?? F>Какие плюсы кроме версионирования у схемы номер 2?
Объясняю.
У меня на машине стоит две версии компонентов DevExpress и две версии компонентов Infragistics. Мне нужны все четыре, потому что у меня есть проекты использующие каждую из этих версий.
Обновление вериий руками происходит очень редко, когда проекты переползают с одной верии компонент на другую, и обычно это лишь малая толика работы, которую приходится при этом проделать, поскольку интерфейсы обычно меняются весьма значительно и приходится править большую кучу кода.
Облегчение жизни, собственно, состоит в возможности использовать одновременно несколько версий компонент.
S>Облегчение жизни, собственно, состоит в возможности использовать одновременно несколько версий компонент.
Хм, а я наоборот вижу здесь главный головняк...
Как правило пользователю нужна просто последняя версия и есть большая опасность что он будет запускать не глядя какую-нить из старых
Здравствуйте, flamin, Вы писали:
F>Здравствуйте, stump, Вы писали:
S>>Облегчение жизни, собственно, состоит в возможности использовать одновременно несколько версий компонент. F>Хм, а я наоборот вижу здесь главный головняк... F>Как правило пользователю нужна просто последняя версия и есть большая опасность что он будет запускать не глядя какую-нить из старых
Это "как правило" вы на основании чего вывели? Собственный опыт?
У нас в разработке и на саппорте полдюжины проектов и всем разработчикам нужны одновременно все 4 версии компонент, потому что, разные проекты используют разные версии компонент.
Если библиотека компонент не позволяет использовать несколько своих версий одновременно, такая библиотека сразу идет лесом, для серьезного использования она не пригодна.
F>>Как правило пользователю нужна просто последняя версия и есть большая опасность что он будет запускать не глядя какую-нить из старых S>Это "как правило" вы на основании чего вывели? Собственный опыт?
В общем, да. Как только сторонние компоненты выпускают новую версию — сразу стараемся обновиться и мигрироват, а старую забыть навсегда.
S>У нас в разработке и на саппорте полдюжины проектов и всем разработчикам нужны одновременно все 4 версии компонент, потому что, разные проекты используют разные версии компонент. S>Если библиотека компонент не позволяет использовать несколько своих версий одновременно, такая библиотека сразу идет лесом, для серьезного использования она не пригодна.
4 версии — это хвосты тянутся, я так понимаю? Это политика такая — поддерживать 4 поколения софта, вместо того, чтобы один раз мигрировать?
Имхо это не есть образец для подражания...
F>>>Как правило пользователю нужна просто последняя версия и есть большая опасность что он будет запускать не глядя какую-нить из старых S>>Это "как правило" вы на основании чего вывели? Собственный опыт? F>В общем, да. Как только сторонние компоненты выпускают новую версию — сразу стараемся обновиться и мигрироват, а старую забыть навсегда.
S>>У нас в разработке и на саппорте полдюжины проектов и всем разработчикам нужны одновременно все 4 версии компонент, потому что, разные проекты используют разные версии компонент. S>>Если библиотека компонент не позволяет использовать несколько своих версий одновременно, такая библиотека сразу идет лесом, для серьезного использования она не пригодна.
F>4 версии — это хвосты тянутся, я так понимаю? Это политика такая — поддерживать 4 поколения софта, вместо того, чтобы один раз мигрировать? F>Имхо это не есть образец для подражания...
Вы свою библиотеку продавать собираетесь, так? Будете убеждать пользователей в своем имхо, что они все должны подпрыгнуть и быстренько переписать все свои сисетмы под новую версию вашей библиотеки. удачи вам
Здравствуйте, stump, Вы писали:
S>Вы свою библиотеку продавать собираетесь, так? Будете убеждать пользователей в своем имхо, что они все должны подпрыгнуть и быстренько переписать все свои сисетмы под новую версию вашей библиотеки. удачи вам
Вообще говоря, существующий фидбек, говорит о том, что большинтсво пользователей хочет новых фич, и ради этого готово послушно обновляться и пересобираться...
Кроме того, почему речь идет о "переписать свои системы"?
В 99 % случаев достаточно пересобрать, у нас тщательно следят за обратной совместимостью по коду...
Здравствуйте, flamin, Вы писали:
F>Здравствуйте, stump, Вы писали:
S>>Вы свою библиотеку продавать собираетесь, так? Будете убеждать пользователей в своем имхо, что они все должны подпрыгнуть и быстренько переписать все свои системы под новую версию вашей библиотеки. удачи вам
F>Вообще говоря, существующий фидбек, говорит о том, что большинтсво пользователей хочет новых фич, и ради этого готово послушно обновляться и пересобираться...
Вы знаете сколько живут Enterprise системы? Десятилетиями. А .Net-у всего восемь лет. Если на разработку ситемы затрачено 20-30 человеко лет, то перевод на новую версию Framework занимает 2-3 человеко года. Никто не будет тратить такие деньги просто чтоб угнаться за новыми версиями. Системы, собранные на предыдущих версиях будут жить еще многие годы, новые же системы разрабатываются на новых серсиях framework. Соответственно производители компонент заинтересованы чтобы их компоненты поддерживали side-by-side версионность, если не хотят терять своих клиентов.
Здравствуйте, stump, Вы писали:
F>>Вообще говоря, существующий фидбек, говорит о том, что большинтсво пользователей хочет новых фич, и ради этого готово послушно обновляться и пересобираться... S>Вы знаете сколько живут Enterprise системы? Десятилетиями. А .Net-у всего восемь лет. Если на разработку ситемы затрачено 20-30 человеко лет, то перевод на новую версию Framework занимает 2-3 человеко года. Никто не будет тратить такие деньги просто чтоб угнаться за новыми версиями. Системы, собранные на предыдущих версиях будут жить еще многие годы, новые же системы разрабатываются на новых серсиях framework. Соответственно производители компонент заинтересованы чтобы их компоненты поддерживали side-by-side версионность, если не хотят терять своих клиенто""
Это убедительно...я правда сомневаюсь что среди наши клиенты будут такого масштаба...
