I have an axmodel file that has a C Sharp project inside. I imported this model file to a different environment.
When I tried to compile x++ code that references the assembly from that project, it does not compile and gives me the error: Variable xyz has not been declared. I even tried to open up the project in Visual Studio, doing a deploy to both client and server, then restarting the AOS. Still it would not compile.
The only way which worked for me was to open the .NET project, then doing 'Add myproject to AOT'. It seems like something else is happening in the background when adding to AOT, and this is not being transferred with the model file.
Does this mean that if I deploy code to a client's environment, they will need to have Visual Studio installed?
If someone has had previous experience with doing something similar, please give me your thoughts.
There is a different story depending on wether you want the assemblies deployed server side or client side.
Read about it here:
It is not necessary to have Visual Studio installed in order to have client side assemblies deployed. Put in another words, you can have your server side assemblies deployed server side automatically when the AOS starts up, or have the client side automatically deployed when starting an AX client (given no other concurrent instance for same user is running).
Here is also a great article that helps understanding what happens and how you potentially trace and debug situations where your assemblies doesn't seem to load correctly:
Hope it helps.
Thanks for the links. However, it seems that the problem isn't that the assemblies aren't being loaded, but they aren't being referenced.
For example, I have a job which references a class in the assembly; specifically just one line which declares an instance of the class. If I clear out the client VSAssemblies folder and then restart the client and compile the job, the references get loaded into the VSAssemblies folder, but the compile still fails.
I reset the environment (it is a VM) and then imported the model file again. I previously said adding the project to the AOT again fixed it, but this time it did not. I did rebuild, deploy, add to AOT, and then restarted the AOS. Still it did not work so I'm trying to find out what I did last time to get it to work.
If I find out the solution I will post it here.
Ok. I would like you to check to see if the .Net dll you are referencing from within AX is either located in VSAssemblies under ../Server/bin (if you expect the assembly to be accessible in server side runtime) or locally where the client is installed under %AppData%\..\Local\Microsoft\Dynamics AX\VSAssemblies (if you expect the assembly to be accessible in client side runtime).
These are the spots AX will deploy. Otherwise you will have to manually put the dlls in the bin-folder (or by creating an installer).
If the file is not there, you will get compilation errors everywhere you have a reference to that assembly in your x++ code.
But you probably already knew this.
I see the assembly in:
C:\Program Files\Microsoft Dynamics AX\60\Server\AXDB\bin\VSAssemblies
I created a very small test case from the same VM, exported, restored the VM, then imported the model. It works correctly. I then realized what the difference is. The VM I am using is AX 2012 R2, but the main development environment I'm using is AX 2012 FP1 CU5. I assume this should work otherwise I would get an error message (which I do get when doing it the other way around and importing a model file from a newer version), but perhaps importing a model into R2 created from FP1 has some issues. I don't have any other environments to do further testing, although I won't worry about it too much since I will eventually update my development environment to R2.
If you are referring any of the Dynamics AX Framework assemblies from your own assembly, then this will not work. RTM and R2 uses two different versions of the Dynamics AX Framework assemblies, namely version 22.214.171.124 and 126.96.36.199.
Ah OK. It seems FP1 falls into the RTM category and also uses 188.8.131.52.
Thanks for the assistance.