In Dynamics AX it's often necessary to install some custom files such as ActiveX components, DLLs, templates, etc (that are not part of the installation package) on each client computer. There's a couple of handy classes to accomplish this task: SysFileDeployer and SysFileDeployment (and it's descendant SysFileDeploymentFile). Unfortunately this mechanism has been completely broken in AX4 due to Code Access Security covering «dangerous API» usage on the server tier, see
Writing Secure X++ Code.
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.
And everything is ok with the
demand() calls in the WinAPIServer class whereas SysFileDeployment* classes lack the
assert() calls. Probably they were not tested thoroughly or something… To be precise, here is what I've found:
SysFileDeploymentFile.serverVersion() lacks corresponding assert() call before WinAPIServer::getFileModifiedDate();SysFileDeployment.getServerFileTimeAccessed()/Modified()/Created() lack corresponding assert() calls before WinAPIServer::getFileTime();SysFileDeployment.isNameValid() splits full file name via fileNameSplit() and after that adds a redundant dot between the name and the extension (fileNameSplit() already returns file extension with a leading dot) - as a result isNameValid() always returns false which in its place causes corresponding assert() calls not to happen;- Finally,
SysFileDeployment.sourcePath() returns xInfo::directory(DirectoryType::Include) by default and the latter is known to return different results depending on which (client or server) tier it is called. Of course, SysFileDeploy* classes work in such a way that SysFileDeployment.sourcePath() is called on both tiers - and that completely ruins all the program logic
You can download a small fix from
axaptapedia.com to make SysFileDeployment work again. Microsoft claims there's already a
hot fix with a description "File deployment error FileIOPermission failed", so there's a hope we will see this fixed in AX4 SP2...
