views:

201

answers:

2

I have a .NET COM assembly I am attempting to deploy to a web server (IIS 6 Win 2003). We have successfully deployed this assembly to our test environment, but the production environment is not working.

The assembly is being called from a classic ASP page. Every time that page tries to initialize the assembly with “Set LTMRender = CreateObject("LTMRender.Render")”, I get an error “Error Type:, (0x80070002)”.

This error seems to indicate a permission denied, or file not found type problem.

I created a test app to see if the assembly works outside of the web page. The .exe initializes the assembly, and then makes a call designed to fail which in turn causes the assembly to produce a log file. It works if I run the .exe in the same folder as the assembly, but fails if I run it elsewhere.

For some reason, the assembly is not accessible from outside it’s folder.

I can’t figure out why this won’t work. Things I have confirmed:

  • The deployment folder has adequate permissions.
  • We have confirmed that the folder the assembly in installed in has the correct permissions for all the necessary user accounts.
  • The Assembly is signed with a strong name, and was registered with regasm.exe C:_WebSites\LTMRender\LTMRender.dll /codebase /tlb:C:_WebSites\LTMRender\LTMRender.tlb. Regasm reported success.
  • The Assembly has the attribute and relevant GUID’s set correctly.

Any tips?

EDIT

We ran filemon against my testapp.exe and it seems to have indicated what the problem is. When testapp.exe runs in D:_websites\DocWebV2\ or D:_websites\DocWebV2\ LTMRender\ folder, it succeeds and filemon is showing D:_websites\DocWebV2\LTMRender\pinPDF.dll SUCCESS

If I run my testapp.exe in the D:_websites\DocWebV2\Client – where my asp pages run, it shows D:_websites\DocWebV2\pinPDF.dll NAME NOT FOUND and then D:_websites\DocWebV2\pinPDF\pinPDF.dll FILE NOT FOUND

I’m not sure why it is not looking in the correct folder if it’s under this particular folder only.

A: 

If is File Not Found, not a permission problem. The 7 indicates a Windows error, 2 is ERROR_FILE_NOT_FOUND. The usual trouble with COM visible components is either Windows or the CLR not being able to find dependent DLLs. But that should generate a different error code. Look for trouble in your source code, trying to open files without using the full path name of the file. The working directory will be different on your server. Best way to solve this is to use a debugger.

Hans Passant
I can't run a debugger in production. I am confident this is not a problem with the .dll trying to write a file out or anything like that.My edit outlines my latest info on this. It seems that the .dll (according to Filemon) is being loaded, but the dependencies it uses are not. It's looking for the dependencies in the folder I run the testapp.exe from, not the folder my .dll resides in, which is where they are.
Bremer
Well, that's by design, as I mentioned. You can solve it by storing assemblies in the GAC or unmanaged DLLs in a directory on the PATH.
Hans Passant
A: 

Found the problem with this. Not completely sure I understand it, but I do have it working. Special Thanks to nobugz for getting me to focus on the path.

Filemon was showing a dependent (managed .NET) .dll being found in our test environment but not production.

The key was that in production our network team chose to deploy to a different folder then test, so we had:

PROD
D:_Websites\DocWebV2\LTMRender
TEST
D:_Websites\LTMRender

When I changed TEST to use the same folder structure as PROD, the problem was reproducible.

My assembly, being a COM .dll was found because it was registered. The dependent .dll was not registered, so windows was doing the whole check GAC, then the PATH folders, then the executing process folder and not finding it.

I always assumed that the “executing process folder” would be the .dll folder (as it calls the dependent .dll), but it looks like the web page is the executing process.

Now what I don’t understand is why D:_Websites\LTMRender gets checked. It’s not in our PATH. I am assuming IIS is doing something with this, as d:_WebSites is the root folder for all the web settings in there. I’m no expert on IIS, so I’ll just assume it’s controlling this somehow.

Bremer