Consumir una Asamblea .NET desde una página ASP clásico

Question

Tengo un sitio web .NET 2005 antiguo que tiene algunas páginas ASP y tener acceso a un problema referencia a un objeto .NET DLL. La tarea de mantenimiento se dictó a mí y el desarrollador original es por ningún lado :( Empecé en .Net ya, así que no realmente amo el manejo de este infierno DLL tipo de problema.

En la flecha de abajo es donde estoy encourtering la "(0x80131500) Referencia a objeto no establecida como una instancia de un objeto ".

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

Ya seguido estos pasos:

1. regasm / TBL / código base MyCOMDLL.dll
2. / i gacutil MyCOMDLL.dll
3. copiar el MyCOMDLL.dll al directorio System32
4. Desde la consola, ejecutar issreset
5. Si el archivo DLL es crear en el marco 2.0 crear un archivo "dllhost.exe.config" en el directorio system32 y poner esto:

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

6.- Reiniciar IIS con el comando issreset

y también éstos:

1. En las propiedades del proyecto a. Bajo \ aplicación de información \ assembly yo. Verificación “Hacer que el montaje Com-Visible”. si. bajo construcción yo. Marque “Registrar para interoperabilidad COM”
2. No firmar el documento.
3. Asegúrese de que IUSR tiene todos los permisos para el archivo.
4. Reiniciar IIS través iisreset para enjuagar cualquier caché.

Y todavía no tiene éxito se ejecuta la aplicación. Más ideas lo que permite comprobar o hacer? Gracias!

Emir

Answer 1

El problema fue la aplicación está buscando un archivo que contiene el nombre de host de base de datos.

Answer 2

El valor HRESULT es muy relevante. Tenga en cuenta el 'código de instalación' en 0x80131500, 13 indica la fuente de error es administrado código. Ya tienes la traducción amigable para 1500.

En otras palabras, el código administrado inició una excepción y no fue manejado. Eso no es raro que, por supuesto, el código administrado lanza muy comúnmente excepciones. Especialmente NullReferenceException, el que desencadenó. Depuración esto no es tan fácil, ya que se está ejecutando el código administrado en un proceso no administrado. No estoy seguro de lo que es el procedimiento adecuado para IIS, normalmente se hace con las herramientas + conectar con el proceso. La mejor manera de abordar esto es para aislar el código, escribir algunas pruebas unitarias.

Aparte de eso, la variable MACHINEBUILDING me parece un buen candidato para NRE. Usted no inicialice.

Por cierto: no tiene nada que ver con el registro. Eso produce un tipo muy diferente de error.

Answer 3

Yo tenía una solución similar a la suya, pero es cosa del pasado. Todavía tengo algo de información sobre el mismo y sin embargo me di cuenta de que mi declaración regasm es diferente.

regasm mycomdll.dll /tlb :mycomdll.tlb

El suyo referencias TBL en lugar de TLB - tal vez ese es el problema

También creo que debería comprueba los valores de los parámetros y luego llamar al método con esas valores de los parámetros a través de un cliente .NET rápido y sucio-para ver si el método genera un error.

También desea confirmar que el código ASP clásico suyo igualada ...

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