Custom functoids are very useful for extending the standard mapper toolkit with functionality you always wanted.
For the ad hoc problems, there is the scripting functoid which allows you to write an inline script, that will be included in the map's XSLT. The problem here is that the script needs to be repeated for each map link where it is required.
Therefore, I decided to write the reusable logic in a custom functoid. There are some excellent blog posts on setting up custom functoids, that I used to find out how this is done. See here and here. Custom functoids are set up as separate .Net projects and can be added to the mapping toolkit, and used in the maps.
What I discovered when we deployed a BizTalk solution containing (generic) custom functoids to a non-development server is that the custom functoids are not installed along with the installer I generated for my solution.
What is the case?
- The custom functoids and the solution using them are (in our case) different BizTalk solutions.
- On the development machine, the BizTalk engine can find the functioids after they have been published. This is because we've added the custom functoid assembly (dll) to the GAC using a batch file that calls GACUtil (installed with Visual Studio)
- On the non-development machines, the BizTalk installer does not add the custom functoids assembly to the GAC. Manual addition using GACUtil is not possible: since we only have Visual Studio installed on the development machine, we don't have the GACUtil tool available on the other servers.
How did we solve this? What follows is a horrifying story of a few manual actions taken to get it done. As far as I can see now, it is the approach that is advised in other blogs as well:
- Thanks to this blog post, I found the solution for accessing the GAC, even without GACUtil available. See also the documentation by Microsoft.
- I tweaked the registry of the server so that the GAC displays as a folder in Windows Explorer
- I created a folder and subfolder for my custom functoids assembly, exacltly following the strtucture and names on the development machine's GAC
- In this folder, I added the dll of the custom functoids assembly
That did the trick. Wonder what the auditors will think about this.
This is what I am going to look for now: a construct to be added to the installer of and BizTalk solution using the custom functoids, that:
- Installs the correct version of the custom functoids assembly as part of this solution (this is the simple part, as the installer includes all references dll's in the package)
- Adds the custom functoids assembly dll to the GAC as part of the installation process.