Differences between RTC and Classic Client

Probably the biggest headache when developing for Microsoft Dynamics NAV 2009 is when you find different behaviour between the same code executing in different clients. I have experienced this twice so far and both times took a little sorting out.

The first issue was when I tried to import a FOB file that referenced a DLL. The DLL had not been registered on the machine on which I made the import and, prior to NAV 2009, this was not a problem. If you did not have a particular DLL, you would not receive an error until you tried to access the DLL at run time or tried to recompile the object. The FOB files are shipped pre-compiled so there was no need to have the DLL registered on machine just to be able to import the objects.

What I found in NAV 2009 was that although the object imported without errors, an additional message reported that there were problems with one of the objects (can't remember the exact message) but basically what was happening was that once the objects had been imported, the system was attempting to create the C# code to be used by the Service Tier. Since the DLL being referenced could not be found, the C# code did not get created. As a result, when a part of the system tried to access some code in the Codeunit, a run time error occurred – but only on the RoleTailored client (since it relies upon the C# version of the code) the Classic client worked fine. As a solution, we made a point of ensuring that any DLLs required by the system were registered on a computer that was to be used for importing FOBs.

The second problem I came across was as a result of a slight difference in the handling of Option type fields. In the Classic client, if you were to delete the contents of an option field on a form (thus making it an empty string), the system would insert the first option value. Often the first option value is a single space. If you were to do the same on the RoleTailored client, you would get an error message telling you that blank is not a valid option and you would be reminded what the valid options were. This can be quite confusing and you need to remember to type a single space in order to "blank" the field. I've learnt to live with this, but at the end of the week I discovered that this problem can be quite confusing when you hit it from code. One of the programming samples in our book that we provided for download was the ability to use the Data Migration tool to import Dimensions as well data. This has proved quite useful, but I found that when I was extending the tool to work with Document Dimensions (so I could import documents and not just master data) was getting a strange error that I did not get in the classic client. The problem was that I had some code that was trying to pull an option value from an XML document and it was getting an empty string, since the node could not be found. You can probably guess where this is going. The evaluation of the empty string resulted in perfect execution in the classic client but a run time error in the RoleTailored client telling me that the option was not valid. Since this problem only occurred on the RoleTailored client, I was forced to try out the debugging on the service tier (I followed the instruction Vjeko wrote in our book) and it helped me to track down exactly what was going on. It was then fairly straight forward to only evaluate the field value if the text from the XML node actually contained a value. I quite enjoyed debugging in Visual Studio. It was nice to have a debugger that allowed me to step into, over and out of code, as well as being reliable and predictable.