Tuesday, November 24, 2015

Why you can't debug standard Visual Studio projects

I'm not a great Visual Studio expert so this took me some time to figure out, and I must warn you that not everything in this article may be 100% correct. But I hope my findings can be useful anyway, and I will update the article when someone points out where I'm wrong.

So, we had a problem debugging the standard C# project called Microsoft.Dynamics.Ax.Tms. No matter what we tried and how we tried it, we just couldn't get the debugger to load any symbols for the DLL and thus we couldn't get Visual Studio to hit any breakpoints for our debugging session.

The problem is somehow related to the fact that the location of the symbol file (.pdb) is stored within the standard C# project. So in this case Visual Studio is looking for the symbol file in what seems to be a path on some Microsoft internal development server. See the original location here:

You can see the above windows when you have attached the debugger to the AOS process and you activate the Debug / Windows / Modules window, and click on the Microsoft.Dynamics.Ax.Tms module. This is also where you can load the symbol file manually (which I'm about to try to do in the above screen shot - that approach didn't work however).

To get a new symbol file that matches the actual compiled DLL and that can be found in a folder on your system, you need to make a (any small) correction to the C# code, which triggers that you get a new symbol file during compilation. You need to deploy the newly compiled DLL with your change to the AOS, following the existing guide lines for that.

Now in the debug window of a new debug session, you can see that it has loaded the new DLL from the AOS together with the newly created symbol file of your Visual Studio project.

And now you can debug.

Monday, November 16, 2015

Changing labels from the regular UI, not the development environment

Even though it conflicts with what we use to consider as being good advice, I found a feature in AX 2012 that will allow a user to change the contents of SYS labels.

It is of course interesting to investigate how it is designed, even though we'd usually discourage changing SYS labels. You can find the feature under Product information management / Setup / Dimension groups / Product dimension groups:

The class behind the feature is EcoResProductDimensionRename.

This will not work from an application controlled with a Version Control System, as the code doesn't do anything to try a check-out.

So, why is this maybe not such a good idea? One of the main reasons is that the labels will change back to standard at the next major release upgrade. See for recommendations on not changing SYS labels.

Thursday, October 22, 2015

Preserve new and changed labels after undoing a label file check out

If you have to undo a label file check out, maybe due to unrecoverable synchronization problems with the version control system, you'll loose all your new labels and changes to existing labels.

All your new labels will get the new text "Label @$AAxxx was deleted due to undo check-out of AxXXXen-us.ald.", and all the changes to existing labels are just gone.

To keep a copy of your changed and new labels, you can grab a copy of the label files in your appl\standard folder before undoing the check-out . You should do a restart of the AOS first to make sure that all labels are flushed to the label files.

The label files could be in for example C:\Program Files\Microsoft Dynamics AX\60\Server\AX2012R3\bin\Application\Appl\Standard.

And with the safe copy of the label files, you can reapply your changed and new labels by some tedious copy 'n' paste work from these files.

If you just want to preserve your new labels, you can just change the \Classes\SysLabelFile\onUndoCheckOut method so it doesn't overwrite the content of your new labels.

Wednesday, October 7, 2015

New AX book: "Microsoft Dynamics AX Implementation Guide"

Packt Publishing has released a new book called "Microsoft Dynamics AX Implementation Guide".

I have been a reviewer of the book, so I will try to stay objective :-)

Here is what you will learn from the book:
  • Prepare for a great start with effective project management and planning from the beginning
  • Gather details early using effective requirement-gathering tools and techniques
  • Gain tools and techniques for effective infrastructure planning and hardware sizing
  • Get to grips with integration and data migration through planning and strategy
  • Familiarize yourself with the reporting and BI tools
  • Master functional and technical design to customize existing features and designs in your own projects
  • Manage your configuration and you’re your configuration from one environment to another
  • Learn industry’s best practices and recommendations on customization development and performance tuning

Monday, September 21, 2015

Huge transactionlogs when importing model stores

When you import a model store you'll notice that the SQL Server transactionlog file for the model store database will grow enormously.

You can avoid that by importing the model store to a new schema before applying it.

Check out Tommy Skaues article on how to do that:

Friday, August 21, 2015

OpenXML teaser

If you want to be able to create an Excel document from a batch job or on a machine where Excel is not installed, you can use the Open XML standard to create the file without ever opening the Excel application.

You would of course need some X++ wrappers, but I have learned today that these are actually already created for some Russian localizations.

Check this out:
static void OpenXML_Excel_Demo(Args _args)
    Counter                 c;
    XMLExcelDocument_RU     excelDocument;
    str                     templateFilename = @'F:\SomeTemplate.xlsx';
    str                     newFilename = @'F:\OpenXML_Excel_Demo.xlsx'; 

    // Create a new document
    // This implementation works with template files, so I have just created an empty spreadsheet to act
    // as template
    excelDocument = XMLExcelDocument_RU::newFromFile(templateFilename, newFilename);
    // Create some column headers
    for (c = 1; c != 10; c++)
            ComExcelDocument_RU::numToNameCell(c, 1), 
            strFmt("Column %1", c));

    // Close and save the document

Use the cross reference tool to see more usage of this in AX.

Wednesday, August 19, 2015

The important ViewUserLicense and MaintainUserlicense properties of menu items

These often overlooked properties are key to how Microsoft will determine the number and nature of required AX licenses during a license audit.

You need to map menu items to correct CAL type by specifying a value for ViewUserLicense and MaintainUserLicense. If nothing is provided for these properties of a menu item, the menu item will be categorized with the highest available CAL type, which is Enterprise CAL ($$$).

To determine the appropriate CAL's, you can refer to "Microsoft Dynamics AX 2012 R3 Licensing Guide" and follow the guidelines in that document.

In the "Inside Dynamics AX 2012 R3" book, you can find text instructing you to not fill these properties. That is wrong. Microsoft has confirmed with us (EG) that this is wrong, and the team behind the book is aware of the error.