Satya Srikant Mantha

A very intriguing issue came to me to debug .Net code called from X++ code in AX 2012. This was indeed a challenge to be nailed down. Luckily the tools and some concepts helped me to achieve this task. Here it goes...

We need to do a seamless debugging from AX debugger to Visual Studio back and forth. To enable this we need to first see if the dll to be debug is present in GAC then we might need to uninstall it from it due to the order of preference .NET loads the assemblies. The assemblies are first loaded from GAC and then the runtime checks for Public and Private Assemblies. Since the assembly in GAC is always compiled with runtime optimizations it is difficult to debug. We need to unhook this assembly from GAC and then move further relying on >NET assembly loading patterns.

Step 1: Remove the target assembly to debug from GAC. Before that stop all the AOS servers and close all the instances of programs which rely on AOT e.g. all clients and even visual studio now.

Step 2: Build your sample code which is present in AOT in debug mode and get the dll file along with PDB files.

Step 3: Place these files in the Server\..\Bin and Client\bin directories of AX installation.

Step 4: Configure Visual Studio:

Step 4.1: Configure Debugging Options. In Visual Studio Go to Debug -> Options and Settings -> Debug node -> General sub node and disable “Enable Just My Code (managed)”

Step 4.2: Specify the symbol loading directory options. Specify the locations for Client bin and server bin directories of the installation, remember to specify the correct instance of Server bin directory corresponding to your AOS.

Step 4.3: Configure the project for debugging

Step 5: Ready to go place your breakpoints in X++ and in .Net wherever necessary before this process...

Run the Visual studio project and it will invoke the AX client with your breakpoint hitting X++ code.. and when you do a step-in using F11 the Visual studio debugger will be active and from here onwards you would be able to debug the complete flow.

Debugging in seamless manner across debuggers is really very good feature and mostly underutilized, but by doing so we can have improved troubleshooting and saves a hell lot of time..

Stay tuned for more in Advanced Debugging..

http://dynamics-ax-dev.blogspot.com/2010/05/enterprise-portal-adding-ax-web-control.html

In our case the proxies were missing. This can be verified by going to AOT under static files a file with name Proxies is present. We need to make sure that all the entries are present here which are required by the web controls.

A very common scenario while performing TFS builds is to increment version number of the assemblies. There are quite a few approaches of which I would like to share two links:

Ewald Hofman’s Approach: http://www.ewaldhofman.nl/post/2010/05/13/Customize-Team-Build-2010-e28093-Part-5-Increase-AssemblyVersion.aspx#id_02e7b082-ce95-49a9-92e9-7dc88887b377

Richard Bank’s Approach : http://www.richard-banks.org/2010/07/how-to-versioning-builds-with-tfs-2010.html

Both these approaches work well, however there are scenarios where Editing and Checking–in the Assembly version information can create problems with Build Definitions meant for Continuous Integration, or gated Check-ins. You can suppress the Continuous Integration Builds while checking in the Assembly info file by just putting a comment “***NO_CI***” as specified by Ewald in his blog.

However, if you have Gated Checkin in place, this can turn out to be difficult to suppress, I myself tried to suppress the Build Trigger during the check in process but things doesn’t turn out well. That’s where Richard’s solution comes as handy.

Both the solutions have their own pros and cons, which I believe can only be experienced over a period of time. In case of Richard’s solution I believe that we don’t have any history of the Assembly Version Info file and when you take latest of the solution the information will be lost.

If you notice closely, that suppressing the Continuous Integration (the NO_CI approach in check in comments) is a workaround provided by Microsoft, however I didn’t find anything to suppress the gated Checkin so far. Suggestions or Findings are most welcome.

We are now successfully, able build Dynamics NAV solutions using the TFS Build workflow mechanisms. Lots of test builds were made, the builds can restore the NAV Database and start from a fresh solution, take latest of the NAV objects and then import it to Navision and call the compile method. The workflow is also able to generate FOB files as output which can be directly shipped to the customers.

I think this is the First in the world implementation of the TFS build concepts in conjunction with NAV. I think this is a time to change the thinking caps and try to approach ERP development and include the practises of ALM into ERP Product Development.

To cook this recipe you need the following ingredients:

1) An installation of TFS 2010 Team Build Service on a server

2) Visual Studio 2010 for cooking

3) Use the following Hints on the web:

a)  http://www.codeproject.com/KB/library/AutoupateNAV.aspx – use this wrapper to perform the basic tasks

b) http://www.richard-banks.org/2010/11/how-to-build-linux-code-with-tfs-2010.html – for ideas on how to customize the build templates

And finally lot of patience and luck, took me about 120 failed builds to get the first one right!!

Please feel free to ask questions, I would be happy to help!!

My organization is migrating to the new Team Foundation Server 2010, and we all are busy experimenting with ALM features. I find it very exciting and I foresee quite a lot of possibilities for TFS 2010 getting integrated with the Dynamics product line. I hope most of us know about the Version Control capabilities. However, I see a strong possibilities of having Team Builds and other automations, thanks to the technologies like workflow foundation in .net which is now being actively used in various TFS scenarios.

Lots of experiments so there is more to come!!

Cleared “Microsoft Dynamics Ax 2009 Installation & Configuration” exam.

Recently, one of my colleagues was experimenting with Reporting Server on DAX 2009, whenever he used to view a report in SQL Server Reporting Manager he was welcomed with an error:

“Error during processing Ax_CompanyName report parameter. (rsReportParameterProcessingError)”

The Event Log had the following entry:

Dynamics Adapter LogonAs failed.
Microsoft.Dynamics.Framework.BusinessConnector.Session.Exceptions.FatalSessionException
at
Microsoft.Dynamics.Framework.BusinessConnector.Session.DynamicsSession.HandleException(Stringmessage, Exception exception, HandleExceptionCallback callback)

We later found out that this was due to incorrect Business Connector account, with my past experience I noticed this as a very common mistake people make during EP and Reporting Installations. Remember that the reports need to connect to the Dynamics Ax server to run the AxQueries., which needs to pass through the .NET Business Connector. To ensure everything works fine please note the following settings:

1) Your Report Server Service Account should be same as .NET Business Connector proxy account.

2) Ensure on the server which has Reporting Services installed, the client configuration utility for Business Connector points to correct proxy account.

3) And finally, the AX instance you are connecting to has Service account specified for .NET business connector. (administration –> Service accounts –> .NET Business Connector)

These simple checkpoints can help in almost most of the Business Connector related  errors, which I believe is mostly due to incorrect configuration settings.

Happy DAXing!!

Microsoft’s Ax Demo VPC is basically configured for a static IP address 192.168.0.1, this is due to the fact that the VPC has Domain Controlller configured in it which requires a static IP. When we put this VPC on a network with a different subnet and change the IP you can observer that the site http://sharepoint and http://sharepoint/EP cease to function and show “Page Not Found” errors in the browser. This is mainly due to the DNS configuration which is not updated. Below is the screen shot of the changes that needs to be done to make the site functioning properly. Change the following entries in the Forward Lookup Zones of DNS management:

These websites default, SharePoint and projectserver are all mapped to a single port in the IIS i.e. port number 80. These websites are recognised with host headers. These host headers are configured in DNS with incorrect IP address entries in DNS when you change the IP address of the VPC. Just change these values to point to the Local Loop Adapter (127.0.0.1) and change the DNS to point to this address in the TCP/IP properties as shown below:

This will resolve the issue with the website rendering. Initially you may get time out errors while browsing these website. be patient and try again this would work.

While installing Dynamics Ax 2009 Roles Center and Enterprise Portal on Windows Server 2008 R2, there is a prerequisite for IIS Default components which fails to install. The error log file for IIS component installation points to an error while installing feature NET-XPS-VIEWER. This issue can be resolved by editing “ServerManagerCmdInputIIS.xml” file present in the support folder of the DAX 2009 installer. Edit the entry “<Feature Id="NET-XPS-Viewer" />” to “<Feature Id="XPS-VIEWER" />” and try reinstalling the installer should now continue uninterrupted.

The issue is due to the feature name which is now XPS-VIEWER in windows server 2008 R2.

Happy Installing!! :-)