Могу ли я использовать рабочие библиотеки ZennoLab?

[Dmitriy Ka]

Подскажите, можно ли как-то в свои проекты ZennoLab, напрямую подключить рабочие библиотеки из ZennoPoster Pro V7\7.7.11.0\Progs
Может есть файл конфигуратор который позволяет это сделать?

Пример:



Я хочу поработать с таблицами гугл, в Progrs уже лежат все нужные dll, но если я их подключу от туда через GAC, они все равно продублируются в папку ExternalAssemblies и если я продам свой шаблон, то пользователь должен будет самостоятельно их продублировать в ExternalAssemblies иначе проект не заведется.

Собственно вопрос, зачем мне дублировать уже имеющуюся dll, когда я бы хотел самостоятельно сконфигурировать файл, в котором будут прописаны все нужные мне библиотеки для подключения напрямую из Progs, которые так же имеются у всех пользователей.

 

[Yuriy Zymlex]

Тут ещё проблема с дублированием, конфликтами версия, привязкой к конкретной версии + привязка к зависимостям постера и конфликты с ними, которые чаще всего клиенты не могут/не хотят решать.
Вам стоит реализовать динамическую загрузку, так вы обойдёте эти проблемы.

 

[Dmitriy Ka]

Тут ещё проблема с дублированием, конфликтами версия, привязкой к конкретной версии + привязка к зависимостям постера и конфликты с ними, которые чаще всего клиенты не могут/не хотят решать.
Вам стоит реализовать динамическую загрузку, так вы обойдёте эти проблемы.

Можно по подробней, что за динамическая загрузка и как ее использовать в шаблонах ZP\ZD

 

[SellProduct_AD]

Тут ещё проблема с дублированием, конфликтами версия, привязкой к конкретной версии + привязка к зависимостям постера и конфликты с ними, которые чаще всего клиенты не могут/не хотят решать.
Вам стоит реализовать динамическую загрузку, так вы обойдёте эти проблемы.

Я бы тоже не отказался посмотреть пример динамической загрузки dll в зеннопостер.
Давно хочу этот метод освоить, но ИИ немного не справляется со специфическими особенностями Зеннопостера.

 

[Yuriy Zymlex]

Assembly.Load Method (System.Reflection) | Microsoft Learn

Loads an assembly.

learn.microsoft.com

How to: Load Assemblies into an Application Domain - .NET Framework | Microsoft Learn

Learn how to load assemblies into an application domain in .NET. The recommended way is to use the static (or Shared) Load method in System.Reflection.Assembly.

learn.microsoft.com

разумеется, придётся переписать конкретную dll (и её зависимости) под данный способ, чтобы она тоже поддерживала динамическую загрузку.

Решение, конечно, увлекательное, но скорее всего неуместное по объёму работы,
поэтому, опять же - самое простое будет вынести логику в отдельный exe, как уже упоминалось.

 

[Dmitriy Ka]

Решение, конечно, увлекательное, но скорее всего неуместное по объёму работы,
поэтому, опять же - самое простое будет вынести логику в отдельный exe, как уже упоминалось.

Я немного другое имел введу.
У нас есть папка Progs которая содержит много разных библиотек, которые используются для работы ZP\ZD.
Эти библиотеки бывают нужны для работы шаблона, но прямого доступа к ним из ZP\ZD мы не имеем. Мы их можем подключить только через GAC, но после подключения они дублируются в папку ExternalAssemblies и в работе шаблонов будут ссылаться через папку ExternalAssemblies, а не Progs.

Вопрос в том, что хотелось бы их не дублировать, так как эти библиотеке по умолчанию есть у всех пользователей.

Мое предложение\виденье, как от это реализовать:
Инструмент GAC строго завязан на одной папке ExternalAssemblies.
Я предлагаю к работе GAC, добавить еще проверку папки Progs.

Алгоритм работы GAC
1) Мы добавляем библиотеку через GAC из Progs
2) Потом при работе GAC проверят сначала папку ExternalAssemblies. - нужного файла нет
3) Дальше GAC дополнительно еще проверяет папку Progs - находит нужную DLL, которая есть у всех пользователей ZP\ZD
Профит: не дублируем DLL, которые и так использует ZP\ZD и которые есть у всех.

Возможно я конечно ошибаюсь, и в БЛ в работе GAC очень сложная и нельзя просто так добавить еще одну директорию для проверки. Но очень этого хотелось бы!

 

[SellProduct_AD]

Я немного другое имел введу.
У нас есть папка Progs которая содержит много разных библиотек, которые используются для работы ZP\ZD.
Эти библиотеки бывают нужны для работы шаблона, но прямого доступа к ним из ZP\ZD мы не имеем. Мы их можем подключить только через GAC, но после подключения они дублируются в папку ExternalAssemblies и в работе шаблонов будут ссылаться через папку ExternalAssemblies, а не Progs.

Вопрос в том, что хотелось бы их не дублировать, так как эти библиотеке по умолчанию есть у всех пользователей.

Мое предложение\виденье, как от это реализовать:
Инструмент GAC строго завязан на одной папке ExternalAssemblies.
Я предлагаю к работе GAC, добавить еще проверку папки Progs.

Алгоритм работы GAC
1) Мы добавляем библиотеку через GAC из Progs
2) Потом при работе GAC проверят сначала папку ExternalAssemblies. - нужного файла нет
3) Дальше GAC дополнительно еще проверяет папку Progs - находит нужную DLL, которая есть у всех пользователей ZP\ZD
Профит: не дублируем DLL, которые и так использует ZP\ZD и которые есть у всех.

Возможно я конечно ошибаюсь, и в БЛ в работе GAC очень сложная и нельзя просто так добавить еще одну директорию для проверки. Но очень этого хотелось бы!

Когда идет добавление в GAC, там привязывается не только имя файла dll , но и его версия. Это обязательная информация для компилятора C#
Ни у кого не получится в шаблоне привязать 2.0.0.0 из ExternalAssemblies , а работать на 1.0.0.0 из Progs.
Именно из за этой связки имя+версия и возникают конфликты между dll в ExternalAssemblies , Progs и прописанными в GAC.
- либо постоянно меняем GAC, под те dll, что есть в наличии
- либо постоянно меняем dll , которые приходят с новой версией программы , с изменением конфига программы.
- либо пишем сторонюю программу и подключаем все что угодно в ней.
- варианта, кинул dll и она по имени подхватилась в проекте, нет и не будет, так как c# заранее должен скомпилировать код и все связи.

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

В принципе вообще ничего нового для реальной практики, не было озвучено.

 

[Dmitriy Ka]

Когда идет добавление в GAC, там привязывается не только имя файла dll , но и его версия. Это обязательная информация для компилятора C#
Ни у кого не получится в шаблоне привязать 2.0.0.0 из ExternalAssemblies , а работать на 1.0.0.0 из Progs.

Да, вы правы, только я этого не предлагаю!

Я предлагаю не дублировать библиотеки из папки Progs в папку ExternalAssemblies, а дополнительно проверять папку Progs на наличие нужных библиотек.

Пример на практике:
Добавляю нужную мне библиотеку из Progs через GAC в работу шаблона, она сразу же дублируется в ExternalAssemblies. И там, и там у нас одинаковая версия, но шаблон будет заводится только тогда, когда она точно будет в ExternalAssemblies.

 

[SellProduct_AD]

Да, вы правы, только я этого не предлагаю!

Я предлагаю не дублировать библиотеки из папки Progs в папку ExternalAssemblies, а дополнительно проверять папку Progs на наличие нужных библиотек.

Пример на практике:
Добавляю нужную мне библиотеку из Progs через GAC в работу шаблона, она сразу же дублируется в ExternalAssemblies. И там, и там у нас одинаковая версия, но шаблон будет заводится только тогда, когда она точно будет в ExternalAssemblies.

В разных версиях Зеннопостера, разные версии dll.
Сейчас, если нет жестких ограничений на версии dll, то можно работать на своей dll в ExternalAssemblies , на большом количестве версий Зеннопостера. И дублирование очень удобно, что бы не искать повторно уже выбранную в окне GAC.
Если сделают как вы хотите, под каждую версию Зеннопостера надо будет менять GAC в проекте. И шаблон будет совместим только с определенной версией Зеннопостера. (ну или с узким диапазоном версий)

Вывод :
- Убрав дублирование dll, будет доставлено большое неудобство для всех пользователей Зеннопостера
- Ориентация на dll в папке Progs, поставит каждый шаблон в жесткую зависимость от используемой версии dll в самом Зеннопостере. Тут же перестанут работать многие проекты, почти у всех пользователей Зеннопостера.

Плюсов вообще нет.

 

[Dmitriy Ka]

В разных версиях Зеннопостера, разные версии dll.
Сейчас, если нет жестких ограничений на версии dll, то можно работать на своей dll в ExternalAssemblies , на большом количестве версий Зеннопостера. И дублирование очень удобно, что бы не искать повторно уже выбранную в окне GAC.
Если сделают как вы хотите, под каждую версию Зеннопостера надо будет менять GAC в проекте. И шаблон будет совместим только с определенной версией Зеннопостера. (ну или с узким диапазоном версий)

Вывод :
- Убрав дублирование dll, будет доставлено большое неудобство для всех пользователей Зеннопостера
- Ориентация на dll в папке Progs, поставит каждый шаблон в жесткую зависимость от используемой версии dll в самом Зеннопостере. Тут же перестанут работать многие проекты, почти у всех пользователей Зеннопостера.

Плюсов вообще нет.

Возможно вы и правы, но хотелось бы услышать позицию самих разработчиков.

При этом, даже если в папке Progs окажется неподходящая версия DLL, ничто не мешает нам, положить нужную версию в ExternalAssemblies — она всё равно будет использоваться первой, как это реализовано сейчас.

А вот если версия из Progs подходит — мы просто избавляемся от дублирования, без изменения логики работы шаблона. То есть, никакой жёсткой зависимости от Progs не появляется — это скорее оптимизация на совпадающих версиях.

 

[Yuriy Zymlex]

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

Вам стоит создать тему в предложениях. Голосование будет повышать приоритет.

А по предложению: тут возникает привязка шаблона к версии постера, так как dll рано или поздно обновляются.