I have created a project using Visual studio to consume web service, and when running on a AX-client it works perfectly.
But when running same using batch job it gives error like:
Assembly containing type XXXX.XXXX.XXX.XXXX is not referenced.
Object ‘CLRObject’ could not be created.
Does anyone have a solution for this???
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.
AOS is already restarted .
How to let AX to deploy file Automatically.
what is hot-swapping in AX??
There is a property on the project in Visual Studio where you can say where it should be deployed. See How to: Configure Deployment of Managed Code Assemblies.
Hot-swapping should allow AOS to use updated assemblies without restart. See Hot-swapping of .NET Assemblies in the AOS.
Thanks for quick reply…
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 a similar issue.
My assembly works in job but not with the sysoperationFW.
Solution: Added the AOS account to the dll file.
Run a full CIL.
restarted my AOS.
I have similar issue. My assembly works in job but not in the batch class.
I have added AOS account to the dll file in server/VSassemblies folder.
Done a restart and a Full CIL.
It worked.
I had the same issue and adding the AOS user to the VSassemblies folder fixed it for me without a CIL compile.
This is the “Program Files\Microsoft Dynamics AX\60[YOUR AOS NAME]\bin\VSassemblies” folder.
Thank you for posting your solution as this saved us a lot of time.
Cheers,
Phil.
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:
and change it to this:
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).