When creating add-ins for the newest version of Microsoft Dynamics AX, you may also want to set up a build definition for your project. And as you go along, you will most likely run into one of these 2 problems:
- First, you will see warnings in your build log that assemblies could not be resolved
- Second, you will see error that a registry key does not exist followed by the error text : Rainier tools not installed
Resolving assembly references
Though I am not fully sure as to why this is an issue. (Believe me it would take me about 3 posts telling you about the csproj files and the <import> tags to import targets that point to assembly locations, the Dynamics AX tooling not being in the same fixed location and so on). But there is an easy and quick solution that will help you out to get your build result. (Read: there might be a more elegant and elaborate way of doing this, but this solution serves its purpose.
Install the assemblies located in the Dynamics AX Visual Studio extension folder into the GAC. (Look for the assemblies on the file system and you will quickly find where they are installed and pick the ones that you use in your addin because there are quite a lot).
On my system they were installed in the following path:
"C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\Extensions\0ueyjx1c.4xo\
Running the following command installs one of the assemblies I needed: (The GACUtil.exe command utility can be found on the file system if the Windows SDK is installed)
gacutil /i "C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\Extensions\0ueyjx1c.4xo\Microsoft.Dynamics.Framework.Tools.Core.dll"
This will make sure your MSBuild will be able to resolve the needed references. Do this for all of the references you need.
Resolving ‘Rainier tools not installed’
To resolve this one, we need to take a look at the post-build event that is put in your project properties when creating a Microsoft Dynamics AX Developer Tools Addin project. My previous post already talked about this script. But if we take a closer look we can see that the script checks for the presence of a registry key that tells us that the Dynamics AX Developer Tools are installed. And the problem lies in the fact that it is looking at the HKEY Current User branch. This key is only available for the user that was deploying the Dynamics AX Developer Tools and not for MSBuild running the build process.
The good news is that it can be easily solved. The post-build event is used to copy your assemblies to the right Visual Studio folders to install the add-in. But when the source code is built using an automated build process, the post-build event can be skipped. To do this, we modify the Visual Studio Build step and pass in the following arguments to MSBuild:
Update: Beware of the following. When using this solution you must separate your build machine from your development machine. This will make sure MSBuild finds the references but it also causes Visual Studio not to show all of the add-ins available for Dynamics AX. I haven’t got to the bottom of that side effect but I suspect because it loads them from another location and the MEF extension doesn’t allow those when loading the extensions from the file system.