Могу ли я использовать рабочие библиотеки 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, это вообще не серьезно.

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