[ANN] Tabax 0.1 -- панель задач для Axapta

[gl00mie]

Цитата:

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

блин, чета не получается у меня решить задачу с использованием SysFileDeployer. В общем у меня проблема такая - DAX4.0
при отладке дохожу при проверке версии файла (даты модификации) до info.add(), в нем _txt = «Сбой запроса на разрешение типа "FileIOPermission". кстати, в метод info.add() курсор каким-то чудом переходит сразу после кода в методе WinAPIServer.createfile

В данном случае «чудо» - это исключение, которое ловится в блоке try цикла проверки классов-наследников SysFileDeployment.

Цитата:

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

данный кусок я закомментировал и только после этого вроде как при входе аксапта спрашивает "В клиентской установке отсутствуют файлы, необходимые для работы Microsoft Dynamics"

А вот это зря лучше вернуть, как было...

Цитата:

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

при подтверждении установки возникает ошибка. уже не знаю куда дальше копать...

Копать, разумеется, следует в сторону документа Writing Secure X++ Code. Если его почитать и сопоставить с тем, что творится в SysFileDeployment* в AX4, то выяснится, что разработчики там.. как бы помягче сказать.. накосячили Видимо, недаром из SysFileDeployer.filesToDeploy() вытерли все ссылки на соотв. классы - чтобы просто не делать свои же косяки заметными сразу при установке.
Теперь ведь в AX4 использовать для работы на сервере «опасные API» просто так нельзя - надо явно запрашивать разрешения на это

Цитата:

Implementing Code Access Security
Code access security must be implemented by the dangerous API owner and all consumers of the dangerous API.
1. The owner secures the dangerous API by implementing a specific type of permission class and calling the demand() method on that class
2. Each API consumer must explicitly request permission to invoke a secured dangerous API by calling the assert() method on the permission class.
Application code will break unless both of these steps are completed.

И в части вызовов demand() в новоиспеченном WinAPIServer все в порядке. А вот в классах SysFileDeployment* требования по вызову assert() соблюдены не везде - видимо, не хватило времени дотестировать. Если конкретно, то:

• в SysFileDeploymentFile.serverVersion() нет соотв. вызова assert() перед вызовом WinAPIServer::getFileModifiedDate();
• в SysFileDeployment.getServerFileTimeAccessed()/Modified()/Created() нет соотв. вызова assert() перед вызовом WinAPIServer::getFileTime();
• в SysFileDeployment.isNameValid() полный путь к файлу разбивается с помощью fileNameSplit() на составляющие, после чего между именем и расширением вставляется лишняя точка (fileNameSplit() и так возвращает расширение с начальной точкой) - в результате isNameValid() всегда возвращает false, из-за чего опять-таки не происходя соотв. вызовы assert();
• ну и, наконец, SysFileDeployment.sourcePath() по умолчанию возвращает xInfo::directory(DirectoryType::Include), а как нам известно, результат этого вызова сильно различается в зависимости от того, происходит ли он на клиенте или на сервере; разумеется, по закону подлости работа SysFileDeploy* построена так, что SysFileDeployment.sourcePath() вызывается в обоих контекстах и, соотв., выдает разные результаты, что окончательно рушит логику работы.

Во вложении - небольшие модификации, с помощью которых удалось заставить работать SysFileDeployer с тестовым классом-наследником SysFileDeploymentFile.