I’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:
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:
On the server side, here is where debugging is enabled/disabled:
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:
- Identify the specific Debug::assert() method calls which are causing the application to halt.
- Comment out the offending Debug::assert() method calls.
- Add a //TODO comment as a reminder of the Debug::assert() method calls which were disabled.
- Add a “Temp” group to your project to hold any objects with disabled Debug::assert() method calls.
- 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.
Corbitech 
if you check XReference – Used By for this method you’ll find it is called in many places in the same class.
IMHO it is simpler for developer to use on Debug::assert( “is record NULL” ) than to provide dozens of If-Case scenarious in the calling methods, esp. if it is supposed by Application logic that the returned record must not be NULL.
LikeLike