Sunday, July 13, 2008

Dynamics AX Performance issue. Cross object references drawbacks.

Recently I'm working on framework for Dynamics AX 4.0. Project includes form tree control data viewing.

Basically tree framework includes class representing the whole tree and each tree node.
At first each tree node class instance (let's call it TreeItemClass) is associated with particular FormTreeItem storing reference to it (parmFormTreeItem()). Then reference to this instance is being stored in FormTreeItem.data() property.




The issue appeared when tree was built and I was trying to expand it's node containing a lot of sub nodes. Each time I expanded a new node, expanding time increased.
After throughly debugging I discovered that there were huge delays in object assignment.
Probably the problem was in garbage collector, which tried to calculate references.

Anyway, problem was solved by removing FormTreeItem reference from TreeItemClass and changing it to TreeItemIdx.

So be careful with cross object refernces in your code and try to avoid it.

Wednesday, July 2, 2008

CLR Interoperbility. Problem with Assembly Versions

If you're using CLR interoperability to access external logic, you can perform construct objectes two possible ways:

1. Add Reference and then construct needed object
Microsoft.Office.Interop.Outlook._Apllication appl = new Microsoft.Office.Interop.Outlook.ApllicationClass();

2. Also you can use
CLRObject appl = new CLRObject("Microsoft.Office.Interop.Outlook.ApllicationClass") ;

Using th first approach you're strictly tied to certain version of assembly. So, for instance, if user doesn't have Office 2007, assembly reference in DAX 4.0 will not be compiled, since certain 12th version is specified on it. So to be sure user will not receive this problem it's preferable to use second approach. How ever then you don't have an option to use .NET intelisence.

I'm looking forward fixing this issue in DAX 2009