palleagermark: Creating code for a dll that might or might not be on the system

[Blog bot]

Источник: http://www.agermark.com/2016/01/crea...-might-or.html
==============

We are working on a vertical solution where parts of it requires integration with an external .net dll. Not all customers are interested in using the part that requires the external dll, and thus they are not interested in installing the dll.

So how can we write our code so it will compile and run regardless of this dll being there or not.

Well, one way is to create a proxy class in AX to wrap all operations for the external dll. The proxy class need to call the dll through CLRObjects which makes it possible to compile the code even if the dll is not present. Secondly the proxy class needs to runtime deal with the fact that the dll is not there.

The following job shows how the proxy class could be constructed. The example works with a random standard dll I choose.

static void TestCLR(Args _args)
{
CLRObject /*Microsoft.Dynamics.AX.Framework.Tools.DMF.CrossInstanceProxy.InstanceProxy*/ dllObject;

str nameOK = 'Microsoft.Dynamics.AX.Framework.Tools.DMF.CrossInstanceProxy.InstanceProxy';
str nameNotOK = 'xMicrosoft.Dynamics.AX.Framework.Tools.DMF.CrossInstanceProxy.InstanceProxy';

str proxyStr = nameNotOk; // Switch name here to test with the dll being alright and the opposite

try
{
dllObject = new CLRObject(proxyStr);
}

catch (Exception::Internal)
{
// Clear the info log of CLR errors
infolog.clear(infologLine() - 2);

// Register that the dll couldn't be instantiated
print "Could not make an instance of the dll";
}

if (dllObject)
{
print "Got the object";
}
else
{
print "No instance";
}
pause;
}

It is a pest working against just the CLRObject and not with the direct access you could get if you could be sure that the dll would be there. That's a another reason for wrapping all your calls to the dll into an X++ proxy class.

Источник: http://www.agermark.com/2016/01/crea...-might-or.html