In the previous parts we covered the installation and how to use the code upgrade tool. Now we will extend the error rules with our own rules. I’ll be explaining this with very simple example. We will be writing a very simple rule that will check for a method called testmethod1 and change it to testmethod2.

to do this we have to add 2 global functions:

static void testmethod1(str test)
{
info(test);
}

static void testmethod2(str test)
{
info(test);
}

And a class where these functions will be called.

class subjectclass
{
}

public void testoutmethod()
{
;
testmethod1("test");
}

Now we will create our own rule , first unzip the CodeUpgradeTool.Rules.Partner.zip This zip file contains a Visual Studio solution that contains an empty template.
Open the solution in Visual Studio and check that you have following references:

Paste following code in this method. What this code does is it will take in the current function, check that is called testmethod1 and that it has 1 parameter then it will create a second method called testmethod2 and attach the same parameters to it.

Next we build our solution and copy the DLL to the client/bin folder ( like we did in the first part). Then we can again load up the new rules in AX,check for code upgrade patterns and fix them.

This was a very simple example but Microsoft included the source for their original rules in the package(CodeUpgradeTool.Rules.zip). People who want to use this tool and write their own rules can check out these examples. There are lots of methods than can be overridden.

In the previous part we covered the installation and setup of the code upgrade tool. In this part we will check for code upgrade problems on some projects that Microsoft included in the Package.

So first import:

SharedProject_CUT_MutatorDemoClasses.xpo

SharedProject_CUT_SweeperDemoClasses.xpo

When importing these projects don’t mind the errors J

After the import restart your client because otherwise the tool might not pick up the code upgrade errors.

The CUT_MutatorDemoClasses project contains errors that the tool can identify and fix by its self. The CUT_SweeperDemoClasses project contains errors that the tool can identify but cannot fix by its self.

Last week I had to find out which Tables and fields are used when running the Inventory Closing Procedure in AX2009.

So … we could dive into the code and start debugging things. But when I comes to something as complicated as the Inventory Closing Procedure it’s easy to miss important pieces of code when you are debugging.

In the Trace properties, I chose save to file because later the files will be used by ClearTrace

Next I selected all Events on the events selection tab.

Click Run to start your trace.

Now go to AX and run the Inventory Closing Procedure. When the job is finished go back to the Profiler and stop the trace.

Next open up ClearTrace.

The first time you open Cleartrace you will need to set up a Database. When the database is created for the traces you can import the trace files.

This might take some time depending on the speed of your computer and the size of the trace files.

When the import is finished the program will give you an overview of the executed queries, how many times the queries where preformed , how many reads and writes, how long and how heavy it was for the CPU.