Dynamics AX – Object ‘CLRObject’ could not be created (Again?!)

Okay, this one jumped up and bit me on the kiester again.  (and it is really starting to IRRITATE ME!)  I was getting frustrated till my colleague, Corey Lasley, gave me a few ideas.


  1. I had other CLR objects working in AX (see my previous post).  
  2. The broken CLR Object was working, earlier in the week, but I made a bunch of changes and it stopped working. 
  3. I tried a bunch of things, such as: {restarting the AOS, recompiling, making a quick Job in AX to minimize the code for testing}. 
  4. No luck.

Technique:  I learned some new stuff about error handling in AX.  Namely, that there are a few different types of Exceptions and there is no global error handler.  So, if you don’t handle the correct error, you won’t catch it.  So, when calling a CLR object try some code like this:

    AxClrTest.One uno;
    System.Exception ex;
    str result;
    //… other prep code omitted
        uno = new AxClrTest.One();  //  <- This is where I got the error “Object ‘CLRObject’ could not be created”
        result = uno.Test();
    catch (Exception::CLRError)
        ex = CLRInterop::getLastException();
    catch (Exception::CodeAccessSecurity)
        info(“Code Access Security Error”);
    catch (Exception::Internal)  // This exception handler was the Magic Sauce!!
        ex = CLRInterop::getLastException();
        if (ex)
            info(“Internal Error”);
    catch (Exception::Error)
        info(“None of it worked (generic Exception)”);

The result of this block was these two error messages:
    (x) Object ‘CLRObject’ could not be created
    (i) System.Reflection.TargetInvocation: Exception has been thrown by the target of an invocation. —> System.IO.FileNotFoundException: Could not load file or assembly … 

So, basically, this was the result of a total bonehead move, on my part.  I had made a CLR object that depended on another object.  Then I GAC’d the new object, but didn’t GAC the (other) dependent object.

So, two lessons learned here:

  1. Make a test jig (exe/WinForm) to test your CLR object on the server, before you try to run it from AX.  Then, every time you make a change to your CLR stuff (and GAC your DLL on the AX server), do a quick regression test. It will help isolate GAC or CLR mistakes, so you don’t have to wrestle with AX as much.
  2. Better error handling in X++ will catch the right message.  Which will tell you what the ACTUAL problem is (which is not always caused by AX being fussy about AX-CLR interface compatibility, etc).

About Tim Golisch

I'm a geek. I do geeky things.
This entry was posted in .net, Dynamics AX, Errors. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s