Either the assembly is not accessible for AOS (e.g. it’s installed to client bin or to GAC on on the client machine only) or it’s been built for x86 architecture (which is OK with AX client but not with AOS). It may also mean that the problem is with something that your assembly references (I’m not sure if AX gives you a different error message.)
If it’s the former problem, you can let AX to deploy the file automatically. Nevertheless it’s sometimes necessary to restart AOS, even if hot-swapping is enabled.
But issue still persist… I have been googling the issue for a while and got your post on another blog. You wrote their that 32 bit code will not run in 64 bit server environment. In case of client it is OK but since batch job runs on a server, it may raise an issue.
Is this a some kind of bug in AX 2012 or Is there any suggested solution for this?
If possible, can you please write full process to consume web service in Visual studio and then using the same in a class extending Runbasebatch class to be further used in Batch job.
I have performed all the steps , but i might be missing something which is causing the error.
That 32-bit libraries can’t be used in 64-bit processes and vice versa is not related to AX, it’s how the whole architecture works. Nevertheless if you don’t have anything dependent on a particular processor architecture, you can build your assemblies for AnyCPU (which is the default option). JIT compiler in .NET framework then compiles CIL to the native code for the right processor architecture.
I had this issue again and this time the source was what Martin from above pointed out, the wrong processor build type.
Here’s a simple test:
Create a class with a single method that instantiates your class into an object.
What this means is not only declaring the variable, but setting the variable to " = new YOUR_.NET_CLASS()" because that instantiation is where this error is created.
Now, from a Job create an instance of your AX class and execute that method.
NOTE - this where the error message may happen. If it does, your DLL is likely to be set to be x64 CPU target.
If the error didn’t happen, change the class to “RunOn” to server. Compile the class and make sure you do an incremental CIL build
Re-run the same job.
NOTE - this is where the error message may happen. If it does, your DLL is likely to be set to be x86 CPU target. If this is the case, webservice and batch jobs using the DLL will get this same error.
Solution: as Martin pointed out, open the project in VS and set the Platform Target (on the Build tab of the project properties) to Any CPU. If you don’t have VS installed, export the project as an XPO, edit the XPO and search for something like this:
x86
and change it to this:
AnyCPU
Then re-import the project.
To get the DLL onto the client, ensure all clients are closed on the computer/server and the DLL will re-create when a new client application is opened.
To get the DLL onto the server, restart the AOS (hotswap might work… but there’s nothing like an AOS restart).