ax-erp: Debug::assert() method calls in SYS layer triggering Dynamics AX 2012 debugger

[Blog bot]

Источник: http://microsoft-dynamics-ax-erp.blo...sys-layer.html
==============


’ve noticed a behavior in the RTM version (6.0.947.0) of Microsoft Dynamics AX 2012 that has been causing some problems for me lately. Specifically, there are some Debug::assert() method calls in the SYS layer that are being triggered in the application when running in a development environment with debugging enabled (client-side and/or server-side).

This issue does not appear to be entirely new because I’ve found blog postings related to this issue for Dynamics AX 2009:
http://kamalblogs.wordpress.com/2010...amics-ax-2009/
Symptoms

I’ve actually run into this issue while attempting to post purchase orders using the AX 2012 client in a development environment with debugging enabled. Everything works fine until I try to invoice update the purchase order. Then the following dialog appears, and the AX debugger is invoked automatically.

On the client side, here is where debugging is enabled/disabled:
Microsoft Dynamics AX 2012 (client) > Tools > Options > Development > Debug

On the server side, here is where debugging is enabled/disabled:
Start (Windows) > Administrative Tools > Microsoft Dynamics AX 2012 Server Configuration

This issue generally won’t occur in a production environment because debugging will be disabled there. However, if you’re a developer, turning off debugging is not an option in a development environment!
Resolution

I’ve dealt with this issue in my development environment by using the following technique:

1. Identify the specific Debug::assert() method calls which are causing the application to halt.
2. Comment out the offending Debug::assert() method calls.
3. Add a //TODO comment as a reminder of the Debug::assert() method calls which were disabled.
4. Add a “Temp” group to your project to hold any objects with disabled Debug::assert() method calls.
5. When deploying to production, re-enable the disabled Debug::assert() method calls.

Example:


Technically speaking, Step #5 above is not really necessary because the Debug::assert() method calls generally will not be triggered in a production environment. The intention of Step #5 is “house-keeping” to restore code originating from the SYS layer to its original behavior.
Conclusion

I am rather surprised that this issue occurs in the first place – especially with Sys layer objects. The Debug::assert statement is not intended as a run-time validation mechanism for catching invalid user-provided input. Instead, it’s a tool that developers use during coding and unit testing to expose pre-condition failures in their method calls. I’m puzzled as to why any of these pre-conditions would fail for code residing in the SYS layer of the AX 2012 RTM version.
In my particular situation, I was simply trying to post a purchase order using the AX client in my development environment when I encountered this issue. I assume that the assertion failed for some reason other than any modification(s) that I might have introduced into my development environment. However, I haven’t thoroughly tested that assumption by attempting to replicate the issue on a completely new installation of AX 2012 RTM. Accordingly, that assumption is unconfirmed.



Источник: http://microsoft-dynamics-ax-erp.blo...sys-layer.html