I’ve encountered a particular “Method not found” error in Microsoft Dynamics AX 2012 which I’d like to share. In my case, the error appears to be related to the quirky X++ dangling semicolon. With the release of AX 2012, the syntax requirement to include a dangling semicolon within X++ methods had been dropped from AX development best practices. However, there appears to be at least one situation where it’s still required.

Symptoms

On an intermittent basis, I had been getting various compiler warnings related to an X++ method that referenced a .NET assembly which I developed in Visual Studio 2010. Here is an example of the most common warning that occurred:

Warning	Message (06:42:38 pm)	
Method 'System.Object.mapCurrencyCode' not found.

Specifically, the warning occurred on a line where I made a call to a static method of a .NET class. In the warning above, mapCurrencyCode was the name of the static method that I attempted to call. It appeared as though the compiler was having difficulty resolving the type of the .NET class in the assembly and therefore the associated static method could not be referenced.

At design-time, warnings appeared sporadically in the MorphX IDE when compiling X++ and/or CIL. However, at run-time, errors appeared consistently when the problem code was executed.

Resolution

As it turns out, there is a note on MSDN which actually identifies this issue.

Caution
Starting in Microsoft Dynamics AX 2012 you rarely need to include a semicolon before the first statement in your X++ methods. However, you need the semi-colon in X++ methods that call static methods in the .NET Framework.

For the full article, refer to:

How to: Access Static and Instance Members of .NET Framework Classes from X++ [AX 2012]

My situation matched this particular case, so I added the dangling semicolon back to my X++ method that called the static method of the .NET class. After doing so, I no longer received compiler warnings or run-time errors!

Conclusion

I’m a bit disappointed that the dangling semicolon still is needed for this specific case. Initially, I was excited when I heard the news that Microsoft eliminated the dangling semicolon syntax requirement from X++ for AX 2012. However, the existence of this exception detracts me from taking advantage of this new feature. Furthermore, Microsoft generally is encouraging more .NET development within the AX ecosystem, so the chances of encountering this particular case will likely increase over time.

When adopting a new coding practice, I’d like to be assured that it works well across the board. This might seem like an unreasonable expectation at first, but consider this:

Do you really want to be forced to keep exceptions like this at the forefront of your mind while coding?

Other than aesthetics, there appears to be no penalty for continuing to use the dangling semicolon. Accordingly, I’ll keep using it in my X++ code for now. At least I can rely on it to work in all cases. If Microsoft resolves this issue in a future release, I’d gladly bid farewell to the dangling semicolon.