Verbrauchen Sie eine .NET Assembly von einer klassischen ASP-Seite

Question

Ich habe eine alte .net 2005 Website, die einige ASP-Seiten und mit Objektverweis Problem beim Zugriff auf .net dll hat. Die Wartungsaufgabe wurde mir überliefert und der ursprüngliche Entwickler ist nirgends zu finden :( ich .Net bereits damit begonnen, so dass ich Meister nicht wirklich Art von Problem, diese DLL-Hölle Handhabung.

Auf dem Pfeil unten ist, wo ich bin encourtering die „(0x80131500) Der Objektverweis wurde nicht auf eine Instanz eines Objekts festgelegt. "

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

Ich folgte bereits vor:

1. regasm / Tabl / Code-Basis MyCOMDLL.dll
2. gacutil / i MyCOMDLL.dll
3. Kopieren Sie die MyCOMDLL.dll zu System32-Verzeichnis
4. Von Konsole ausführen issreset
5. Wenn Ihr dll im Rahmen 2.0 erstellen „dllhost.exe.config“ Datei im Verzeichnis system32 erstellen und setzen diese:

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

6.- Restart IIS mit issreset Befehl

und auch diese hier:

1. Unter Projekteigenschaften ein. Unter \ application \ assembly Informationen ich. Prüfen „Make Montage Com-Visible“. b. unter Build ich. Check „Register für COM-Interop“
2. Sie es nicht unterschreiben.
3. Stellen Sie sicher, dass IUSR volle Berechtigungen für die Datei hat.
4. Starten Sie IIS neu über Iisreset alle Caches zu leeren.

Und immer noch nicht erfolgreich läuft die Anwendung. Noch weitere Ideen, was zu überprüfen oder zu tun? Dank!

Emir

Answer 1

Das Problem wurde die Anwendung sucht nach einer Datei, die Datenbank-Hostnamen enthält.

Answer 2

Der HRESULT-Wert ist sehr relevant. Beachten Sie die ‚Einrichtungscode‘ in 0x80131500, 13 zeigt die Fehlerquelle Code verwaltet wird. Sie haben bereits die freundliche Übersetzung für 1500.

Mit anderen Worten warf der verwalteten Code eine Ausnahme, und es wurde nicht behandelt. Das ist nicht ungewöhnlich, natürlich verwalteten Code sehr häufig wirft Ausnahmen. Besonders Nullreferenceexception, diejenige, die Sie ausgelöst. Debuggen dies ist nicht so einfach, da Sie laufen verwalteten Code in einem nicht verwalteten Prozess. Nicht ganz sicher, was das richtige Verfahren für IIS ist, in der Regel ist es mit Werkzeugen durchgeführt + zu Prozess anhängen. Der beste Weg, dies zu bekämpfen ist, den Code zu isolieren, einige Unit-Tests schreiben.

Other than that, die MachineBuilding Variable scheint mir ein guter Kandidat für NRE. Sie haben es nicht initialisiert werden.

BTW: es hat nichts mit der Registrierung zu tun. Das erzeugt eine ganz andere Art von Fehlern.

Answer 3

Ich hatte eine Lösung ähnlich wie bei Ihnen, aber es ist lange vorbei. Ich habe noch einige Informationen über sie jedoch, und ich bemerkte, dass meine regasm Aussage anders ist.

regasm mycomdll.dll /tlb :mycomdll.tlb

Ihre Referenzen Tabl statt TLB - vielleicht, das ist das Problem

Ich denke auch, sollten Sie die Parameterwerte doppelt überprüfen und dann rufen Sie die Methode mit den Parameterwerten durch ein schnelles und unsauberes .NET-Client zu sehen, ob die Methode einen Fehler wirft.

Ich mag auch, um zu bestätigen, dass mein klassischen ASP-Code Sie abgestimmt ...

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