Consommez un assemblage .NET à partir d'une page ASP classique

Question

J'ai un ancien site Web .net 2005 qui contient des pages ASP et qui rencontre un problème de référence d'objet lors de l'accès à .net dll. La tâche de maintenance m'a été transmise et le développeur d'origine est introuvable :(J'ai déjà commencé à .Net, donc je ne maîtrise pas vraiment la gestion de ce type de problème.)

Sur la flèche ci-dessous est où J'encourtering la "(0x80131500) référence d'objet non définie à une instance d'un objet."

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

je l'ai déjà suivi ces étapes:

1. regasm/TBL/codebase MyCOMDLL.dll
2. gacutil/i MyCOMDLL.dll
3. copier le MyCOMDLL.dll dans le répertoire System32
4. A partir de la console, exécutez issreset
5. Si votre dll est de créer dans le cadre 2.0 créer un fichier "dllhost.exe.config" dans la system32 et de mettre ceci:

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

6.- Redémarrez IIS avec issreset commande

et également o nda:

1. Sous-propriétés du projet a. Sous \ application \ information d'assemblage i. Cochez la case "Rendre l'assemblage Com-Visible". b. Sous construction i. Cochez «S'inscrire à Com Interop»
2. NE PAS le signer.
3. Assurez-vous que IUSR dispose des autorisations complètes sur le fichier.
4. Redémarrez IIS via iisreset pour vider les caches.

Et toujours pas réussi à exécuter l'application. D'autres idées sur ce qu'il faut vérifier ou faire? Merci!

Emir

Answer 1

Le problème était que l'application recherchait un fichier contenant le nom d'hôte de la base de données.

Answer 2

J'ai eu une solution similaire à la vôtre, mais il est révolue depuis longtemps. J'ai encore quelques infos à ce sujet et j'ai remarqué que ma déclaration regasm est différente.

regasm mycomdll.dll /tlb :mycomdll.tlb 

Vôtre références tbl au lieu de tlb - peut-être que c'est le problème?

Je pense aussi que vous devriez revérifier les valeurs des paramètres, puis appeler la méthode avec ces valeurs de paramètres via un client .NET rapide et corrompu pour voir si la méthode renvoie une erreur.

Je veux aussi confirmer que mon code ASP classique adapté à vous ...

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

Answer 3

La valeur HRESULT est très pertinente. Notez le «code d'installation» dans 0x80131500, 13 indique que la source d'erreur est le code managé. Vous avez déjà obtenu la traduction amicale pour 1500.En d'autres termes, le code managé a généré une exception et n'a pas été traité. Ce n'est pas rare, bien sûr, le code managé jette très souvent des exceptions. Notamment NullReferenceException, celui que vous avez déclenché. Le débogage n'est pas si simple car vous exécutez du code managé dans un processus non géré. Je ne suis pas sûr de la procédure à suivre pour IIS, normalement avec Outils + Attach to Process. La meilleure façon d'y remédier est d'isoler le code, d'écrire des tests unitaires. En dehors de cela, la variable MachineBuilding me semble être un bon candidat pour NRE. Vous ne l'avez pas initialisé.

Btw: cela n'a rien à voir avec l'enregistrement. Cela produit un type d'erreur très différent.