Trouble with pass through sanScript

Here is another post about an interesting support incident.  I kind of like sharing these interesting cases with you in this format, so I think I will try to keep doing that. I hope you enjoy these cases.

This case came in as a problem when running pass through sanScript.  The error that was coming back was basically "Syntax error ;".  Now, if you have done a lot with pass through sanScript before, especially large blocks of code, it usually takes a few tries to get the syntax to the point where it compiles properly.  A missed semi colon or comma is all it takes to produce this message.  The message is usually what we have here, "Syntax error ;"  or sometimes it shows a comma instead of a semi colon. 

I called the developer and this got a little more complicated because what he had was some pass through sanScript and inside of that, he was doing a COM_CreateObject() to access a COM interop .net dll that they also had developed.  It's more complicated because we are using COM in Dexterity in pass through sanScript.  You can't step through that like you could in straight Dexterity code. 

So the first thing that we did was add in a warning statement so we could see the pass through code that was running.  We looked through that and it sure looked OK - of course there was a lot of code to look through.  We made a couple of minor changes but it still didn't work. 

There was a large amount of pass through code so then we started to narrow this down by taking out code in the pass through to see if we can pin point the problem.  Well, we got down to the local variables and the COM_CreateObject().  That wouldn't even run.  So we basically have one line of code that fails.  I checked and rechecked and the syntax was correct. 

There are a couple other details that I should mention here.  This code is failing on a VPC image, Dexterity is not installed on the VPC, but the dll that they are trying to use and GP and his third party are installed.  The developer had previously taken the full pass through code and put it into a plain Dexterity script on his development machine and it did compile fine. 

At this point, I had the developer send me the .dll, .tlb and .reg files that he was trying to integrate with and I loaded them on my machine.  The I created a quick plain Dexterity script to access the COM object.  It worked and compiled fine.  Then I took the same code and moved it into pass through sanScript code.  Again, it worked and compiled fine.  I sent him my exact script, and it wouldn't work for him.  Same error, "Syntax error ;".  So now I'm baffled, we are about an hour or two into this.  Now, it has to be something on the VPC environment, it has to be.  The error is pointing to a syntax error - but it can't be. 

We then changed the code to use the imports statement instead of the COM_CreateObject.  Just to see if that makes any difference.  Now the error comes back as "Bad import directive".  OK, so the message changed, so that's something.  I change my pass through code do use the imports statement and that works fine. 

So now, the problem is pointing to the dll.  Maybe dexterity can't find the dll on the VPC image, even though it is in the GP directory.  So we go to Process Monitor.  The VPC did have internet access so we downloaded process monitor and fired it up.  We ran the pass through sanScript and then turned it off again.  The developer sent me the log file. 

In the log, it appears that dexterity can find the dll, but we see a problem in the registry access section.  In the log, dexterity is trying to read the following key:

HKEY_CLASSES_ROOT\TypeLib\{GUIDNUMBERHERE}

The GUID number is the GUID for the Class that we are trying to import or create an instance on.  There is an error reading the key, it is coming back as "NOT FOUND".  I run the Process Monitor on my system that works and it can access that key fine.  So this has to be the problem, the dll isn't registered on the VPC image even though it is there. 

The developer checks the registry and that key is definitely not there.  They register the dll again using regasm, check the registry and now that key is there, and bingo, everything works. 

What was throwing me off the whole time was the syntax error that the pass through sanScript was returning.  Once we got the bad import directive, then we got pointed more in the right direction.  In hindsight I might have done some things differently, but we got it to work in the end. 

Best Regards,
Dave Dusek