Running a .Net reference code in the Server in Dynamics AX 2009 - dll

Question

We have an integration scenario, where we have done the following activities in mentioned sequence:
Created a custom C# DLL (built using .NET Framework 3.5)
Signed/strong-named using VS signing feature
Registered/published the DLL in the server GAC using GACUtil.exe
Placed the DLL in Server\Bin directory
In Dynamics AX 2009, added the reference of the DLL (it appeared in the form without browsing in file explorer, as already registered in GAC)
Restarted AOS services
We can see the DLL reference in the AX client (AOT -> Reference) installed on terminals.
Also, in the AOS, we can see the IntelliSense and code compiles without any error if we access some method in the referenced DLL.
Problem: AX client installed on terminals, is unable to read this DLL and throws a compilation error that the object does not exist.
Tried full compilation, RunOn = Server property but the issue persists.
P.S. Issue resolves if we place the DLL in Client\Bin directory but this is not an option as we have over 300 terminals and to place/update DLL in each of them is not a practical approach.
Edited:
Now, I'm running the code on the server after placing the DLL in the Client\Bin folder in the batch server which is different from the AOS server. Code executes fine on the batch server but on AOS and the terminal machines it gives an error that says:
"Object 'CLRObject' could not be created"
Please guide what am I missing. The code in the test job is pasted below:
static server void IntConCheck(Args _args)
{
AxIntegration.Integration integrationClass;
AxIntegration.ATPIntegrationRequestContract req;
;
new InteropPermission(InteropKind::CLRInterop).assert();
integrationClass = new AxIntegration.Integration();
req = new AxIntegration.ATPIntegrationRequestContract();
info(integrationClass.getATPValuesJSON(req));
}

Answer 1

Be aware that Dynamics AX 2009 is a 3 tier system, where business logic can be executed on the server or the client tier. For the question, the customization done for business logic executed on the client tier is relevant.
The question indicates that the .dll is called by code that is executed on the client tier, otherwise placing the .dll in the client's bin directory would not resolve the issue.
There are a several options to resolve this. The first two are related to operations (i.e. not programming related), so I will keep them short:
Automate maintenance The question mentions that deploying the .dll on 300 terminals is not a practical approach. I would question this statement. Surely there is other similar maintenance work being done on those terminals (e.g. installation or update of software). If not already in place, a solution to automate the maintenance work on those terminals should be implemented.
Use terminal servers Instead of having the Dynamics AX client installed on 300 terminals, install it on terminal servers. Depending on how many concurrent users of Dynamics AX there are, several of those might be required. But the total number should still be significantly lower than the number of terminals. It should then be a practical approach to deploy the .dll on those.
The third option is the programming option. This option depends on the nature of the .dll. If the functionality provided by it can be executed on the server tier, the code can be modified in such a way that the parts that use the .dll are always executed on the server tier. The question already mentions the RunOn property that allows to influence the executing tier. It is unclear why setting this property to Server did not resolve the issue. Reviewing How To: Run a Class on the AOS might help. To provide further guidance on this, a new question should be asked that shows with some example code what was tried to force execution on the server tier.
An alternative programming option is using Classes\SysFileDeployer to automatically deploy assemblies (client or server). See this thread discussion, this post, and this post.
PS: Be aware that as of April 12th, 2022 the extended support for Dynamics AX 2009 has ended. Components required by Dynamics AX 2009 (e.g. Windows or SQL Server) may also no longer be supported. This poses significant risk, especially from a security point of view, for any company still running this version of Dynamics. It is recommended to upgrade as soon as possible to the latest supported version.