views:

61

answers:

3

Hi,

I have an old .net 2005 web site that has some asp pages and having object reference problem accessing .net dll. The maintenance task was handed down to me and the original developer is nowhere to be found :( I started at .Net already so I don't really master handling this dll hell kind of problem.

On the arrow below is where I'm encourtering the "(0x80131500) Object reference not set to an instance of an object."

Set objCommon = Server.CreateObject("Wrapper.CommonFunctions")
  Dim machineBuilding
--->>>  If objCommon.IsMachineAccount(strLogin, machineBuilding) Then

I already followed these steps:

  1. regasm /tbl /codebase mycomdll.dll
  2. gacutil /i mycomdll.dll
  3. copy the mycomdll.dll to System32 directory
  4. From console, execute issreset
  5. If your dll is create in framework 2.0 create a "dllhost.exe.config" file in the system32 directory and put this:

<?xml version="1.0"?> <configuration> <startup> <supportedRuntime version="v2.0.50727"/> <requiredRuntime version="v2.0.50727"/> </startup> </configuration>

6.- Restart IIS with issreset command

and also these ones:

  1. Under project properties a. Under \application\assembly information i. Check “Make assembly Com-Visible”. b. Under build i. Check “Register for Com Interop”
  2. DO NOT sign it.
  3. Make sure that IUSR has full permissions to the file.
  4. Restart IIS via iisreset to flush any caches.

And still not successful running the application. Any more ideas what to check or do? Thanks!

Emir

A: 

I had a solution similar to yours but it is long gone. I still have some info on it however and I noticed that my regasm statement is different.

regasm mycomdll.dll /tlb :mycomdll.tlb

Yours references tbl instead of tlb - maybe that's the problem?

I also think you should double-check the parameter values and then call the method with those parameter values through a quick-and-dirty .NET client to see if the method throws an error.

I also want to confirm that my Classic ASP code matched yours...

set obj = server.CreateObject("mycomdll.myclass")
...
call obj.method(false)
...
myvar = obj.method2(param1, param2, param3)
Mayo
+1  A: 

The HRESULT value is very relevant. Note the 'facility code' in 0x80131500, 13 indicates the source of error is managed code. You already got the friendly translation for 1500.

In other words, the managed code threw an exception and it wasn't handled. That's not uncommon of course, managed code very commonly throws exceptions. Especially NullReferenceException, the one you triggered. Debugging this isn't that easy since you are running managed code in an unmanaged process. Not quite sure what the proper procedure is for IIS, normally it's done with Tools + Attach to Process. The best way to tackle this is to isolate the code, write some unit tests.

Other than that, the MachineBuilding variable strikes me as a good candidate for NRE. You didn't initialize it.

Btw: it has nothing to do with the registration. That produces a very different kind of error.

Hans Passant
Never occured to me that the information within the HRESULT can be broken down to isolate the error (vs. mapping the specific error to a specific problem). +1 simply for showing me something new. Also, if you have any links that give more information on HRESULT interpretation that would be fantastic.
Mayo
Found info at http://blogs.msdn.com/b/heaths/archive/2005/07/21/441391.aspx. The facility (bits 8-15 equal 19) is FACILITY_URT which I later found means Universal Runtime, an early name for the CLR. Very interesting stuff - I love learning new things. :)
Mayo
@Mayo: look in the SDK header file WinError.h for lots of details about this. c:\program files\microsoft sdks\windows\v6.0a\include for vs2008.
Hans Passant
A: 

The problem was the application is looking for a file that contains database hostname.

Emirage