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.