WN

WN (https://www.wn.se/forum/index.php)
-   Serversidans teknologier (https://www.wn.se/forum/forumdisplay.php?f=4)
-   -   .NEt komponent får 80070002 i klassisk ASP (https://www.wn.se/forum/showthread.php?t=1061316)

fiend 2014-03-27 16:28

Citat:

Ursprungligen postat av ConnyWesth (Inlägg 20489043)
Har du glömt att registrera den ny COM-DLLen med regsvr32 (om det är en 32-bitars app du skapar?

Har du gjort ett installationsprogram för att installera programet eller kör du br i utvecklingsmiljön?

Har du kollat att referensen till DLLen är med i EXE-filsprojektet?

Du kanske ska prova att kopiera projektfilerna för XXX-projektet till en helt ny katalog som du kallar XYZ och sen byter du ut de enskilda filerna i projektet till de från YYY-projektet. Det kan ju vara så att själva projektfilerna i YYY-projektet har fel inställningar.

Funkar inte det så skapa ett helt nytt projekt och lägg in källkodsfilerna från YYY för ibland kan projektfilerna vara fel om man meckat mycket med dem.

Den nya DLLen är samma eftersom det är i samma projekt :)
Själva itextsharp-dllen går inte registrera och jag gissar att den inte ska registreras med regsvr32?

Jag har både testat göra installationsprogram, men i övrigt reggar jag via regasm och gacutil.

exe-filsprojektet?

Ska testa att lägga ut allt i ett helt nytt projekt, kompilera om det projektet och se ifall det funkar bättre. :)

Conny Westh 2014-03-28 11:13

Citat:

Ursprungligen postat av fiend (Inlägg 20489079)
Den nya DLLen är samma eftersom det är i samma projekt :)
Själva itextsharp-dllen går inte registrera och jag gissar att den inte ska registreras med regsvr32?

Jag har både testat göra installationsprogram, men i övrigt reggar jag via regasm och gacutil.

exe-filsprojektet?

Ska testa att lägga ut allt i ett helt nytt projekt, kompilera om det projektet och se ifall det funkar bättre. :)

Du kör ju ASP kom jag tt tänk på.... då har man ju ingen exe-fil...

Men vad jag menar är att du ska börja med att bygga ett exe-filsprojekt som använder COM i stället för NET för att få bättre debuggingmöjligheter.

När du väl får COM-DLLen tt fungera med en EXE-fil så vet du tt det inte är fel på DLLen, utan då är det något annat fel.

Reager 2014-03-31 13:24

Värt att tänka på är också att om du kör 64-bits Windows att ställa om din applikationpool så att den kör i 32-bitars-läget. Annars kommer det inte att fungera. (är min erfarenhet ivf)

fiend 2014-04-02 15:09

Citat:

Ursprungligen postat av ConnyWesth (Inlägg 20489121)
Du kör ju ASP kom jag tt tänk på.... då har man ju ingen exe-fil...

Men vad jag menar är att du ska börja med att bygga ett exe-filsprojekt som använder COM i stället för NET för att få bättre debuggingmöjligheter.

När du väl får COM-DLLen tt fungera med en EXE-fil så vet du tt det inte är fel på DLLen, utan då är det något annat fel.

Har inte riktigt de erfarenheterna av att varken skapa .exe-filer eller att debugga dem tyvärr :/

fiend 2014-04-02 15:11

Citat:

Ursprungligen postat av Reager (Inlägg 20489386)
Värt att tänka på är också att om du kör 64-bits Windows att ställa om din applikationpool så att den kör i 32-bitars-läget. Annars kommer det inte att fungera. (är min erfarenhet ivf)

Applikationspoolen är inställd på att kunna köra 32bitars applikationer japp. Det har jag kollat och det har den alltid varit :) tack iaf!

fiend 2014-04-02 15:12

Har nu lagt över hela koden i klassen i ett helt nytt projekt och registrerat en helt ny DLL.
Funkar utmärkt att anropa via ASPn på min utvecklingsserver http://localhost/ men på den skarpa servern så blir det precis exakt samma felmeddelande som i mitt huvudprojekt :/
Argh, funkade inte att separera ut hela koden i ett eget projekt heller..

fiend 2014-04-08 09:40

Någon som har någon fler teori? :/ frustrerande detta.


Alla tider är GMT +2. Klockan är nu 09:34.

Programvara från: vBulletin® Version 3.8.2
Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
Svensk översättning av: Anders Pettersson