Caveat in using Matlab DLL in ASP.Net

I was crafting another WCF Service using basicHttpBinding that used a Matlab NE Builder generated DLL and was keep getting System.TypeLoadException on the class' constructor. This problem was reported but there was no conclusive explanation other than ASP.Net page time out being set too short. But setting that to a long value did not help and certainly did not help me.

My unit test using the DLL directly proved that the DLL was working perfectly and hence it must be environmental. Not the person easily defeated by this kind of issue, I took this up as just another challenge. There must be an explanation.

Being certain that it was environmental, I began to investigate the ASP.Net runtime infrastructure. I know when the Matlab DLL, called a deployment DLL for all the right reasons, was first used, Matlab runtime will expand the embedded scripts, albeit compiled, into a runtime folder structure under the matlab_mcr folder. This folder structure replicates the same directory structure from the root directory when the deployment DLL was built. matlab_mcr is the folder created at a nominated directory.

So if when you build your deployment DLL in say

"C:\Documents and Settings\John\My Documents\My Matlab Project"

Matlab runtime will try to create a structure like this:

[TempDirBase]\matlab_mcr\Documents and Settings\John\My Documents\My Matlab Project

where [TempDirBase] is the base directory where your run time is going to use. If it is the %Temp%, then in XP it is

"C:\Documents and Settings\John\Local Settings\Temp"

If you are like me using very verbose and easy to remember project name organized in a meaningful directory structure and using long matlab function names, the path that Matlab replicates at run time can easily approach the maximum limit of a path name.

In fact the cause of the TypeLoadException by the matlab class was exactly what I encountered when I was using NUnit to unit test code that used a deployment DLL. In NUnit I simply changed the shadow copy directory.

In the ASP.Net situation, the length of the default ASP.Net temporary directory path coupled with my build location caused the operating system to fail to recreate the matlab run time structure because the path length exceeded the maximum permissible length.

Armed with prior experience and the ability to change the ASP.Net default temporary file directory to a different location, I used a 2-prong attack to ensure that matlab's silly recreation of the directory structure will not bother me anymore.

Here is my technique to fix this problem:
1) Build the deployment DLL in a extremely cryptic and shorten path.
Build the deployment DLL in a very cryptic and extremely short path like this c:\0\1 or c:\01. I choose this pattern because I am going to have several of these deployment DLLs and so each one can grab a different number as directory name. Since this is only for run time and it is totally meaningless human, they can be very cryptic. The aim is to make it as short and as flat as one can get and.spare no mercy to Matlab.

You can even use these numbers as your extra version identifier.

This recommendation does not mean that you need to store your project that way. You should store them in as meaningful directory as you can for easy of maintenance and team spirit. By default action, when Matlab replicates this at runtime, it discloses your project organization and if you store your project in the profile area, Matlab can disclose who you are. By using a cryptic and short build path, you prevent Matlab from disclosing such information.

Since I always build these deployment DLLs with a batch file for good technical reasons, it is only a matter of adding extra batch commands to create the build directory described above, and to copy all the .m, .prj, .cs, etc. to the build directory and kick the build from that build directory.

When the build is finished, you copy the output files back to a generated output directory in my solution. The batch file can include commands to remove the build directory.

2) As an extra measure to combat this Matlab bloated directory problem, you change the ASP.Net temporary file directory, which is conveniently applicable per application using the web.config.

This can be achieved by specifying your temporary directory to a very short path name in the tempDirectory attribute of the <compilation> element.

Arm with these and a very long "ASP Script timeout" for your application, changed via the IIS console, you should have no trouble with using Matlab deployment DLL in IIS.