X++ managed proxies allow you to invoke X++ code from managed code

Here is a brief recap on how to do that:

In Visual Studio, simply create a class library. In Solution Explorer, right click on the project and select ‘Add  a ClassLibrary to AOT’:

Then open the Application Explorer, right-click on the class you want to proxy and select ‘Add to Project’

This will add a proxy item to you project and give you full Intellisense on the proxied class from your managed code:

Now what if you want to use a kernel class such as the TreeNode? The toolset does not offer any simple gesture to add such a class to your project, but here is what you can do:

Start by adding a random X++ class as explained above. In the solution explorer, select the added proxy item and rename it by using the context menu or F2:

You can see that the actual name of the item is something like Class.<SomeClassName>.axproxy.

Now replace <SomeClassName> with the name of the class you want to proxy. For example, if you want to proxy the TreeNode class, you should rename the item to Class.TreeNode.axproxy.

That’s it! You can verify that it worked by checking that the class shows up in the Intellisense:

Download in High Res (avi - 47 MB)

Download in Med Res (MP4 - 19 MB)

This posting is provided "AS IS" with no warranties, and confers no rights.

At the breakout session on Wednesday at 7:30PM, you’ll be able to see the new X++ editor I blogged about.
I’ll be demo’ing the new Visual Studio tooling and managed development for AX at the breakout session 13 on the same day at 10:30AM.

See you there….

Check them out.

This posting is provided "AS IS" with no warranties, and confers no rights.

In a completion session, holding the ctrl key will make the drop-down dialog transparent, so you can see the code underneath:

The dorp down list is also filtered and your typing is displayed in the buffer:

Ctrl-Mouse wheel will allow you to zoom the code in and out:

This posting is provided "AS IS" with no warranties, and confers no rights.

Here is how it looks like:

The line numbering and the gradient marking are the first visible signs of a new UI. The rendering is WPF based, so that gives some opportunities for cool graphics.

Here is little more exiting view:

Things to notice, that are new relatively to the existing editor are:

• Support for multiple fonts and styles (comments are in a different font in italic).
•  Differentiated coloring of strings and numbers.
•  Operators coloring (in pink here, but don’t worry I’ll most likely change it before we release !).
•  Change tacking margin.

For other sneak previews at AX6, you might want to take a look at mfp's blog

This posting is provided "AS IS" with no warranties, and confers no rights.

From the markup

If you need to display an icon on your UI you would write something like that from the markup:
<Image Name="MyImage" Source="Resources/Icon1.ico" />

Beware, that by default, WPF resolves resources at run time, so you can refer to the icon file, provided you move it around with you app while preserving the relative directory structure. What you probably want to do, is to embed your resources in your assembly.
The markup above works fine, if you add the icon file to the project and marked it as resource. So far so good.

If the resource is part of the project, you can also set the image source from the property sheet.

Then notice something interesting, the image source end up looking something like that:
<Image Name="MyImage" Source="/WpfApplication1;component/Resources/Icon1.ico"/>

The weird path is actually a so called packed URI. This URI scheme provides a way to refer resources embedded in files. For more details on the pack URIs see Pack URIs in Windows Presentation Foundation in the MSDN documentation.

Icon files can contain several bitmaps, and by referencing the resource in this way, you cannot control which one is used. You might for example want to pick the 16x16 icon rather that the 32x32 for a better rendering.

This can be done in the code behind:

From the code behind

First you need to create the URI. The simplest syntax, if the resource is embedded in the running assembly is
Uri resourceUri = new Uri(@"Resources/Icon1.ico", UriKind.Relative);

Notice that you need to specified that the URI is relative. The syntax for the absolute path is 
Uri resourceUri = new Uri(@"/WpfApplication1;component/Resources/Icon1.ico");

But you'll notice that the name of the assembly is included in the URI. A more portable version is
Uri resourceUri = new Uri(@"pack://application:,,/Resources/icon1.ico");

Anyway, once you have the Uri, the way to access the resource is to get hold of the corresponding stream:
StreamResourceInfo resourceInfo = Application.GetResourceStream(resourceUri);
Stream resourceStream = resourceInfo.Stream;

To iterate through the bitmaps in this stream, we can use the IconBitmapDecoder helper class and look for the one which is 16x16:
// Look for the 16x16 icon
if (iconBitmapDecoder.Frames.Count > 1)
{
    foreach (BitmapFrame bitmapFrame in iconBitmapDecoder.Frames) 
    { 
        if (bitmapFrame.Height == 16 && bitmapFrame.Width == 16) 
        { 
            MyImage.Source = bitmapFrame; 
            break; 
        } 
    }
}

That's it! I buy you beer if you can do the same thing directly from the markup.

With AX2009 you are now able to do SSRS reports in Visual Studio. The typical process for designing a report consist in creating a query and bind to it, code some business logic (BL) specific to the report and design the visual part.

This post will focus on debugging the report business logic. For more information on designing reports in general, see the msdn documentation

There is also an excellent post on Channel 9 from my friend Manoj here.

Debugging

Let say you've designed a fancy report in VS and in order to make it do cool stuff, you had to write some pretty complex business logic. Unfortunately, your business logic does not do what you think it should be doing. You know that you've been working too late on too much caffeine, so you suspect that there might be a bug there and you need to do some debugging.

The 'attach-to-the-server-process' approach

One approach to debug your business logic consist of the following steps

· Rebuild the report in VS in debug mode

· Save it back to the AOD

· Redeploy the report

· Set a breakpoint at a strategic location in your business logic code

· Attach to the server process

· Invoke your report

· Hit the breakpoint and start debugging

While being perfectly valid, this approach has a rather long turn-around-time, especially considering the fact that during a debugging session, you will most likely need to ride the modify-code-rebuild-test carrousel several times.

Also you are an agile programmer and you know about the values of Test Driven Development (TDD), so you are thinking: 'Damn, I wish I had developed this report using the good TDD methods and wrote some unit test for my business logic'. Well, don't despair, Visual Studio (professional edition and above) comes with several cool features that can help you do TDD and debugging on your reports. Let's see how.

Creating unit test for SSRS based reports business logic

Let's assume that you have created your report solution with its related report project

For the sake of simplicity, let's pretend that you have written the following dull BL method

public static DataTable MyMethod()
{ 
        DataTable result = new DataTable(); 
        result.Columns.Add("Col1"); 
        result.Columns.Add("Col2"); 
       result.Columns.Add("Col3"); 
        result.Columns.Add("Col4"); 

        return result;
}

Now we are going to create a unit test for this method. But before doing so, we need to help Visual Studio a bit to resolve certain assemblies. In the business logic project, go the reference node, select the Microsoft.Dynamics.Framework.Reports assembly and set the property 'Copy Local' to 'True'.

Then, right-click in the editor and choose 'Create unit test...'. Browse to the folder where the business logic assembly is built (for example <...>\DynamicsReportsLibrary1\DynamicsReportsLibrary1\BusinessLogic\bin\debug\)

and select the DynamicsReportsLibrary1.BusinessLogic.dll assembly. Unfold the tree node and select the method you want to debug as shown below:

You'll notice that Visual Studio will create test project for you if you don't have one. Alternatively, you can create one by right clicking on the solution and choosing 'Add project' and then select the test project template:

Then you can target this project when creating a unit test.

Visual Studio has generated the following unit test method :

[TestMethod()]
public void MyMethodTest()
{
      DataTable expected = null; // TODO: Initialize to an appropriate value
      DataTable actual;
      actual = Report1.MyMethod();
      Assert.AreEqual(expected, actual);
      Assert.Inconclusive("Verify the correctness of this test method.");
}

In our example, as we use the DataTable type, we'll also need to add references to System.Data and System.xml in order to get your test project to build. Once you've done that, you should be able to build your solution and run the test. You can either do this from the test toolbar:

or from the test view, where you can select each unit test individually.

Now you can start rewriting the auto-generated test and do some real testing. For the sake of simplicity, I'll write a simple test, which checks that the created data table actually has 4 columns.

public void MyMethodTest()
{
      DataTable dataTable = Report1.MyMethod();
      Assert.AreEqual(dataTable.Columns.Count, 4, "The data table must have 4 colums");
}

Running this test provides the following output:

What about Debugging?

That's what we initially wanted to achieve, wasn't it?. Well, that's just a few clicks away. Put a breakpoint at the beginning of your BL method and from the test view window, right-click on the test method and select 'Debug Selection'.

Next thing you know, you are hitting your breakpoint and you can start, debugging your business logic:

Code coverage

As a freebie, you can get Visual Studio to calculate the code coverage for you. Simply edit the test configuration (Tools -> Edit Test Run Configuration -> Local Test Run) to enable the code coverage instrumentation on your BL assembly

Then re-run the test, and click on the 'Show Code Coverage Results' icon in the toolbar of the Test Results window, which will give you the nice view below for free:

Conclusion

The technique described above shows how to debug business logic for SSRS based AX 2009 reports with a quick turn-around time, following the Test Driven Development methodology and providing code coverage measurement on the side. Beware that there might be some scenarios where attaching to the server process is the only way to track a specific bug. Some bugs might only show there ugly faces when the report in running in its deployment context on the server. But if you follow the good principles of TDD and use this local debugging approach, you might not need to go to these extends and you'll likely catch most of the errors at an early stage. Happy debugging :-).