подключение dll библиотек по произвольному пути

[NetBus]

Возможно ли подключение dll библиотеки по произвольному пути?
Т е что бы не надо было выкладывать созданную разработку ко всем клиентам
на рабочие места в строго определенные папки, а выложить на сервак, прописать путь и работать в свое удовольствие.

axapta 3.0 sp5

[mazzy]

семейство классов sysFileDeploy*
Поищите обсуждения по этому ключевому слову.

а также:
http://axapta.mazzy.ru/lib/sysfiledeployment/
http://forum.mazzy.ru/index.php?showtopic=2066

[mazzy]

Цитата:

Сообщение от NetBus

Т е что бы не надо было выкладывать созданную разработку ко всем клиентам

И еще.

Обратите внимание, что Аксапта может работать и в тонком режиме. В этом случае клиенту может быть не виден сервер, клиент может вообще находится вне сети, общаясь с АОСом только по порту.

Поэтому выкладываение "на сервер" не решит вашу проблему.
Пользуйтесь стандартными средствами копирования на клиента, уже предусмотренными в Аксапте, и не мучайтесь с выкладыванием "всем клиентам".

[vallys]

Добавлю .
Если у клиента файловая система ntfs с запретом на создание файлов в требуемом каталоге для пользователя, запустившего аксапту (клиентскую часть), то sysFileDeploy должен дать сбой. Придется первый раз запускать аксапту из под пользователя, который имеет такие права.
Это же касается и регистации библиотек (нужны права на изменение соответствующих веток реестра), если не вин 98.

[JeS]

DAX 4.0 SP2
Кто-нибудь решал проблему изложенную vallys? Из-за прав падает в классе SysFileDeployment здесь:

boolean copy()
{
....
    if (!binData.saveFile(this.destinationPath()+this.tempFilePrefix()+this.filename()))
        throw error(strfmt("@SYS19312", this.destinationPath()+this.tempFilePrefix()+this.filename()));
...
}

Можно как-нить подсунуть права другого пользователя при выполнении этой операции? или еще как? Расширять права пользователя не катит.

[someOne]

to JeS
На мой взгляд, тут есть три варианта решения:

1.Создать некий инсталлятор, (setup.exe) и использовать его для установки необходимых библиотек dll каждый раз после установки клиентской части Axapta администраторами . Сделать это придется каждый раз при добавлении новой dll в используемый код. Создать инсталлятор возможно, например, с помощью inno setup (http://www.innosetup.com/isinfo.php)
2.Там где это возможно, вызывать функции dll на серверной стороне, тогда dll не придется копировать на клиентские места.
3.Копировать необходимый dll не в системные папки (system32 и т.д) а в папки, в которые у пользователя есть полный доступ, например C:\Documents and Settings\user\Local Settings\Application Data\Axapta

[mazzy]

Цитата:

Сообщение от someOne

На мой взгляд, тут есть три варианта решения:

1.Создать некий инсталлятор, (setup.exe) и использовать его для установки необходимых библиотек dll каждый раз после установки клиентской части Axapta администраторами . Сделать это придется каждый раз при добавлении новой dll в используемый код. Создать инсталлятор возможно, например, с помощью inno setup (http://www.innosetup.com/isinfo.php)

Думайте дальше.
Библиотеки, код, и клиенты обновляются.
Как устанавливать обновленные версии библиотек ПОСЛЕ того, как установка клиента давно выполнена?
Как обновлять exe-шники клиента?

На эти вопросы и отвечает семейтво классов sysFileDeploy*

[JeS]

Цитата:

1.Создать некий инсталлятор, (setup.exe) и использовать его для установки необходимых библиотек dll каждый раз после установки клиентской части Axapta администраторами . Сделать это придется каждый раз при добавлении новой dll в используемый код. Создать инсталлятор возможно, например, с помощью inno setup (http://www.innosetup.com/isinfo.php)

- ну, тут Вам mazzy ответил, я с ним согласен. Не катит.

Цитата:

2.Там где это возможно, вызывать функции dll на серверной стороне, тогда dll не придется копировать на клиентские места.

- согласен, но пять же "там где это возможно", а там где невозможно?

Цитата:

3.Копировать необходимый dll не в системные папки (system32 и т.д) а в папки, в которые у пользователя есть полный доступ, например C:\Documents and Settings\user\Local Settings\Application Data\Axapta

- вариант рабочий, но не очень красивое решение. Получится, что одна и та же dll-ка размножится по кол-ву пользователей на этом компе, если делать по пути через ...user\Local settings..

В итоге, приходим к общей папке с правами для всех пользователей, так как на админов я положиться не могу, то решил создавать в папке Bin клиента подкаталог из Ахапки. Причем папку создать винда уже дает и сразу запихивает в нее полный доступ под текущего пользователя, далее я подразумеваю добавить туда права на всех пользователей на полный доступ. И уже в дальнейшем сохранять туда все новосозданные dll-ки. Вот только меня терзают смутные сомнения: то, что винда дает создать папку в каталоге, в котором не давала создать файл - это частное поведение системы (в зависимости от настроек политики безопасности) или общий случай? В админском деле я не силен.

P.S.: А вот регистрация dll уже непобедима, я так понимаю.

[mazzy]

Цитата:

Сообщение от JeS

P.S.: А вот регистрация dll уже непобедима, я так понимаю.

Опять же, и на эти вопросы отвечает семейство классов sysFileDeploy*
В частности метод SysFileDeploymentDLL.register()

[JeS]

Либо я Вас не понимаю, либо Вы меня. Я ведь и говорю о семействе классов SysFileDeploy*. Просто когда исполняется этот код, он работает с правами (я про виндовые права) текущего пользователя, и если у пользователя нет прав на создание файла в папке Bin клиентской части, то SysFileDeploy* - выкидывает что-то вроде "Unable to save .... в такую-то директорию", то же самое с реестром - ошибки не выбросит, но и не зарегит. Вопрос зародился отсюда :

Цитата:

Если у клиента файловая система ntfs с запретом на создание файлов в требуемом каталоге для пользователя, запустившего аксапту (клиентскую часть), то sysFileDeploy должен дать сбой. Придется первый раз запускать аксапту из под пользователя, который имеет такие права.
Это же касается и регистации библиотек (нужны права на изменение соответствующих веток реестра), если не вин 98.

[mazzy]

Цитата:

Сообщение от JeS

Либо я Вас не понимаю, либо Вы меня.

Конечно же я.

Теперь понял.
Фраза "А вот регистрация dll уже непобедима, я так понимаю."
означает "Регистрация dll без виндовых прав невозможна".
Согласен.

[gl00mie]

Цитата:

Сообщение от JeS

так как на админов я положиться не могу

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

Цитата:

Сообщение от JeS

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

Это все основано на допущении, что такая "вольница" будет на каждом компе, где запускается клиент Аксапты. Заметьте, что таким компом может оказаться и какой-нить терминальный сервер - сомнительно, чтобы при его настройке оставили пользователям подобную возможность (я бы не оставил ).

Цитата:

Сообщение от JeS

Вот только меня терзают смутные сомнения: то, что винда дает создать папку в каталоге, в котором не давала создать файл - это частное поведение системы (в зависимости от настроек политики безопасности) или общий случай?

Это поведение в зависимости от сочетания конкретных прав (DACLs), розданных на каталог, и привилегий, которыми с точки зрения виндов обладает тот или иной пользователь на данном компе.
В вашем конкретном случае такое поведение связано с тем, что:

1. клиент Аксапты, видимо, установлен в подкаталог %ProgramFiles%;
2. на %ProgramFiles% установлены штатные списки контроля доступа ("права"), включающие возможность для любого аутентифицированного пользователя создавать свои подкаталоги, в них - создавать/изменять/удалять подкаталоги и файлы и при этом иметь к созданным объектам (подкаталогам и файлам) полный доступ;
3. каталог, куда установлен клиент Аксапты, наследует права доступа от %ProgramFiles%.

Обратите внимание, что права доступа для "Creator Owner" заданы на подкаталоги и файлы. Т.е. если произвольный пользователь не является владельцем каталога %ProgramFiles%\Axapta\Client\Bin, то в этом каталоге он может лишь создать свои каталоги, при этом он становится их владельцем и получает полный доступ. Обратите также внимание, что свой подкаталог можно было бы создать и в каталоге %ProgramFiles%\Axapta\Client.
Однако, в общем случае ACE для Creator Owner может быть удален администраторами с %ProgramFiles%, в т.ч. на всех рабочих станциях в домене (например, с использованием secedit и шаблонов безопасности).

Цитата:

Сообщение от mazzy

Цитата:

Сообщение от JeS

А вот регистрация dll уже непобедима, я так понимаю.

Опять же, и на эти вопросы отвечает семейство классов sysFileDeploy*
В частности метод SysFileDeploymentDLL.register()

Тут вопрос не в том, как именно дернуть dll или ocx, чтобы они прописали регистрационную информацию в реестр, а в том, как под произвольным пользователем получить на клиентской машине возможность записать что-то в те ветки реестра, доступ на запись к которым есть отнюдь не у всех пользователей. На самом деле, штатное "обходное" решение есть, но для того, чтобы им воспользоваться, надо обновить клиентские машины до Vista или Windows 7. См. Registry Virtualization.

[JeS]

Благодарю за развернутый ответ! Вобщем, вывод такой: данной функциональностью нужно пользоваться при прямом участии админов, что вобщем-то логично. Соответственно, решение у каждого свое.