Dynamics AX
  RSS Feed  LinkedIn  Twitter
Want to turn you're data into a true asset? Ready to break free from the report factory?
Ready to gain true insights that are action focused for truly data informed decisions?
Want to do all of this across mutliple companies, instances of Dynamics and your other investments?
Hillstar Business Intelligence is the answer then! (www.HillstarBI.com)

Hillstar Business Intelligence for Microsoft Dynamics AX and NAV on Mobile, Desktop, Tablet


Let us prove to you how we can take the complexity out of the schema and truly enable users to answer the needed questions to run your business! Visit Hillstar Business Solutions at: www.HillstarBI.com

Tuesday, September 12, 2006

Make use of DotNet Assemblies from DAX 4.0

As part of my AIF series of post, I thought that it would only be right to prepend and post about how to make native .Net assembly calls from DAX 4.0 X++ code.

This is a great addition to DAX, being able to take given .Net assemblies and create objects from classes, and make use of .Net code through native references and X++ code, rather than through COM.
With that said, let's jumpe right in and Talk about what it takes to make use of a .Net assembly from within Dynamics AX 4.0.

(1) First the given .Net assembly must be a signed one. Meaning that it must have a public token associated with it.
(2) Second the assembly needs to be installed into the GAC

Once you are for sure these two are done next is creating a reference within DAX. From the AOT you can go to close to the bottom and you will see references. From there right click and add a reference. The reference form will pop up and you will have to click on the browse button and select your .DLL .Net Assembly.

Once the reference is made, then you can move on to creating code that makes use of the given .Net assembly. I say start with a new job. ONce you have the new job created, add code that looks similar to this:

static void DotNetIntegration(Args _args)

{

DotNetAssembly.DNClass DNC;
str s;
CLRObject clrDNC;
;


clrDNC = new DotNetAssembly.DNClass();
DNC = clrDNC;
s = DNC.DNMethod("Test");
info(strfmt("%1",s));
}

Now to speak a little bit about this code. The first line DotNetAssembly.DNClass DNC; Is a declaration that makes use of the Referenced Assembly, and one of it's exposed classes. Next we have a standard str s declaration, and then what makes the interaction possible, the CLRObject declaration.

From there we move on to the execution of code, which shows the following line first: clrDNC = new DotNetAssembly.DNClass(); This line is very important, in that it creates a new instance of the clrDNC CLRObject class. What you have to realize at this point is that all .Net Assembly Classes are CLRObjects, and therefore must be created as so. Notice the next line is we set the newly created clrDNC object and make the DNC object equal to that. By doing this we get the look ahead ability to view the methods within the .Net assembly, for example the line of code: s = DNC.DNMethod("Test");

So you can take any .Net assembly, make sure the assembly is signed and installed into the GAC, and then make use of the CLRObjects you can interact with Dot Net with native X++ calls, without having to make use of COM.

Check back soon for more!

Find a job at: www.DynamicsAXJobs.com

5 Comments:

Blogger Scott Banwart said...

Hi,

I am having a problem getting this to work. I have signed my assembly and installed it in the GAC on the AOT server. When I try and run my code, I get the following errors:

"Clr object is not initialized"
"Object 'CLRObject' could not be created"

If I install the assembly into my local GAC, everything works, but other users get the error messages. Does the assembly have to be installed into the GAC of every client machine?

3:43 PM  
Blogger brandon said...

Sorry for the late reply. Anyway, for this to work in a 3-tier environment, the Assembly needs to be installed into the GAC (windows\assembly) on the given AOS.

Then from there, you will see your DotNet Assembly appear in the GRID for selection. Create the reference in the AOT using what is being displayed from the Grid. In doing so, you now have made it to where the DotNet Assembly will be executed from the AOS, instead of a client reference.

I hope this helps!

9:37 AM  
Blogger Scott Banwart said...

I figured out part of my problem. I'm using an X++ wrapper around my .NET assembly. The wrapper was being created on the client, and this was causing the error I was seeing. I changed the class properties to run on the server, and that fixed it.

However, I still have a related problem. The other developers in my group are getting a similar error when they are working against the AOS machine that has my .NET assembly included in the reference section. When they are editing code, they get the error when using the Intellisense features of the MorphX editor. I can also reproduce this on my machine. I fixed it on my machine by having putting my assembly into my local GAC. Is there a way to prevent this other than installing my assembly into the GAC on every developer machine?

2:41 PM  
Blogger krzak said...

Maybe I'm wrong but this integration doesn't allow use properties so many maaany classess in unusable, or we have to write wrappert around property to make it method.

Or I'm wrong ?

8:04 AM  
Blogger brandon said...

krzak,

This is correct you need to create an adatper in order to enable the use of some .Net functions.

For example to fill in or get properties, then you need to create wrapper get & set methods for doing this.

In the next release of DAX 5.0, this will not have to take place.

-Brandon

11:01 AM  

Post a Comment

Links to this post:

Create a Link

<< Home


Copyright 2005-2011, J. Brandon George - All rights Reserved