[SOAP]DLL werkt alleen onder Visual Basic?

[FitNiX]

Probleem is als volgt:

Ik heb in VB een applicatie gemaakt die en SOAP request doet naar een dll. Dit werkt op zich allemaal prima als ik hem onder visual Basic run. Daarmee bedoel ik, ik draai de DLL-code in VB, evenals de EXE.

de EXE file.


de response:


* FitNiX Het stomme is dat dit alleen werkt terwijl de DLL runt onder Visual Basic.
Het werkt niet als ik de DLL bouw en registreer in Windows.

OS: Win 2000 Server @ SP2
Alle benodigde zooi geinstalleerd zoals SOAP toolkit etc.
Het werkt namelijk wel, maar alleen als de DLL wordt gedraaid onder Visual Basic.

[ Voor 0% gewijzigd door FitNiX op 19-09-2002 14:21 . Reden: typo's ]

[whoami]

Het werkt niet als je het niet runt vanuit VB.... Een beetje duidelijker graag... We zijn niet helderziend

krijg je een foutmelding? Zoja welke?
Zonee, wat gebeurt er dan precies?

[FitNiX]

Ik bedoel ik heb een project voor het formulier zeg maar, en een project voor de DLL code. Als ik die DLL run onder Visual Basic (F5) dan werkt alles prima. Maar zodra ik hem stop, en de request nogmaals doe,

dan krijg ik deze error als ik de gebouwde EXE draai:


en deze error als ik de EXE draai onder Visual Basic.


Ik draai de DLL dan niet (onder VB)

[FitNiX]

Met runnen bedoel ik gewoon zeg maar runnen
Testen zeg maar.



Weet niet hoe ik het anders moet uitleggen

[whoami]

Ik snap ondertussen wel wat je bedoeld hoort.

[FitNiX]

whoami schreef op 19 september 2002 @ 14:40:
Ik snap ondertussen wel wat je bedoeld hoor.

ok

Heb je zoiets ook weleens gehad? en misschien ook opgelost?

[Pooh]

Ik snap er niks van. Hoe 'run' je een DLL? Wat zegt je soap 'trace utility'?

[FitNiX]

Poohbear schreef op 19 september 2002 @ 14:44:
Ik snap er niks van. Hoe 'run' je een DLL? Wat zegt je soap 'trace utility'?

Als jij software bouw, dan test je het toch door het te runnen zeg maar?
dat kan dus ook als je een DLL bout, die registreer je dan.

Dat doet ie dus wel goed onder VB maar niet als we het in windows doen.

in windows:

[mulder]

Je moet ook z'n dik gedrukte woorden beter lezen. . Sorry. Maar ik snap em ook niet helemaal. Doet ie het als gecompileerde DLL niet, en als EXE wel? OF een project met een EXE en DLL? Of een EXE die zo'n DLL gebruikt

[Pooh]

Kermit schreef op 19 september 2002 @ 14:47:
[...]

Als jij software bouw, dan test je het toch door het te runnen zeg maar?
dat kan dus ook als je een DLL bout, die registreer je dan.
Dat doet ie dus wel goed onder VB maar niet als we het in windows doen.

Ik snap dat je een DLL kunt bouwen, en kunt registreren. Maar 'runnen' kan echt niet. Dan moet je een .exe hebben die 'm aanroept, maar dat werkt niet zeg je... Dus begrijp ik 't niet meer. Wanneer werkt 't wel, wat doe je dan precies, en wanneer werkt 't niet? Is je DLL goed geregistreerd?

[FitNiX]

Don Facundo schreef op 19 september 2002 @ 14:48:
Je moet ook z'n dik gedrukte woorden beter lezen. . Sorry. Maar ik snap em ook niet helemaal. Doet ie het als gecompileerde DLL niet, en als EXE wel? OF een project met een EXE en DLL? Of een EXE die zo'n DLL gebruikt

Het laatste.
Heb een EXE en een DLL.
Beide gebouwt in VB
als ik die DLL run in VB dan doet ie het.
als ik hem bouw en registreer, dan doet ie het niet meer, dan krijg ik eerder genoemde errors.

[whoami]

Maar de eerste keer werkt het wel zeg je? Het is pas vanaf de 2de keer dat het fout loopt?

Ben je wel zeker dat je niet vergeet van één of andere functie aan te roepen die één of ander dinges vrijgeeft of sluit?

[FitNiX]

Poohbear schreef op 19 september 2002 @ 14:49:
[...]


Ik snap dat je een DLL kunt bouwen, en kunt registreren. Maar 'runnen' kan echt niet. Dan moet je een .exe hebben die 'm aanroept, maar dat werkt niet zeg je... Dus begrijp ik 't niet meer. Wanneer werkt 't wel, wat doe je dan precies, en wanneer werkt 't niet? Is je DLL goed geregistreerd?

als je in VB die dll "runt", dan doet ie in feite ook nix anders dan hem bouwen en registreren. maar daar ziet de programmeur niets van. die drukt alleen op zo'n mooie play knop.

[FitNiX]

whoami schreef op 19 september 2002 @ 14:51:
Maar de eerste keer werkt het wel zeg je? Het is pas vanaf de 2de keer dat het fout loopt?

Ben je wel zeker dat je niet vergeet van één of andere functie aan te roepen die één of ander dinges vrijgeeft of sluit?

Nier perse de eerste keer, hij doet het alleen als ie hem bouwt en registreert in VB.

Normaal als je dan klaar bent met het programmeren, dan bouw je de DLL, en dan kan je hem registeren. maar als ik dan opnieuw de EXE start, dan doet ie het niet.

[ Voor 0% gewijzigd door FitNiX op 19-09-2002 14:54 . Reden: typo's ]

[Verwijderd]

MISCHIEN ligt het probleem bij de runtime/designtime licensekey

http://msdn.microsoft.com...gissuesforolecontrols.asp

[Pooh]

Kermit schreef op 19 september 2002 @ 14:53:
[...]
Nier perse de eerste keer, hij doet het alleen als ie hem bouwt en registreert in VB.

Normaal als je dan klaar bent met het programmeren, dan bouw je de DLL, en dan kan je hem registeren. maar als ik dan opnieuw de EXE start, dan doet ie het niet.

Maar een gebouwde en geregistreerde DLL "doet" toch nog niks?

[FitNiX]

Verwijderd schreef op 19 september 2002 @ 14:58:
MISCHIEN ligt het probleem bij de runtime/designtime licensekey

http://msdn.microsoft.com...gissuesforolecontrols.asp

Maar ik heb zowiezo niet die license support toegevoegd, dus daar kan het niet aan liggen...

[FitNiX]

Poohbear schreef op 19 september 2002 @ 14:58:
[...]

Maar een gebouwde en geregistreerde DLL "doet" toch nog niks?

Maar het lijkt wel of ie hem gewoon niet registreert, hij doet het namelijk wel onder VB, maar niet als ik hem op de normale manier registreer in windows.

(hij geeft wel de melding dat ie hem succesvol heeft geregistreerd als ik dat doe.)

[Verwijderd]

Het probleem dat je beschrijft komt me bekent voor. Een oplossing is: Bouw de dll. Als je 'm verplaatst moet je deze opnieuw registreren met regsvr32. Voeg daarna in het project van de .exe de dll als reference toe. Bouw de exe. De foutmelding zou nu verdwenen moeten zijn. Het is zowiezo verstandig om je project van je .dll binair compatible te maken met je eerder gecompileerde .dll. Daarmee voorkom je problemen. Je kunt 'm ook Project compatible maken, maar dan moet je elke keer je .exe hercompileren als je je .dll aangepast hebt.

Succes.

[FitNiX]

Verwijderd schreef op 19 september 2002 @ 15:19:
Het probleem dat je beschrijft komt me bekent voor. Een oplossing is: Bouw de dll. Als je 'm verplaatst moet je deze opnieuw registreren met regsvr32. Voeg daarna in het project van de .exe de dll als reference toe. Bouw de exe. De foutmelding zou nu verdwenen moeten zijn. Het is zowiezo verstandig om je project van je .dll binair compatible te maken met je eerder gecompileerde .dll. Daarmee voorkom je problemen. Je kunt 'm ook Project compatible maken, maar dan moet je elke keer je .exe hercompileren als je je .dll aangepast hebt.

Succes.

Okay, het werkt bijna. Door die reference toe te voegen werkt het programma op zich goed, alleen krijg ik nu geen waardes meer uit de database terug . Het is alsof de koppeling er niet meer is.

[Verwijderd]

Tijd om je component te debuggen.

Met de volgende code kan je Events in je event log schrijven, zodat je precies kan zien wat er gebeurt in je component terwijl die draait.

code:

'informatie event
App.LogEven("Hier wat informatie", vbLogEventTypeInformation)  
'warning event
App.LogEven("Hier wat informatie", vbLogEventTypeWarning)  
'error event
App.LogEven("Hier wat informatie", vbLogEventTypeError)

Verder kan je InProc DLLs debuggen door een ProjectGroup aan te maken binnen dezelfde development environment. OutOfProc COM componenten kun je debuggen door 2 development environments te gebruiken, 1 met de aanroepende code en de tweede met de code van je COM component.

Succes

[FitNiX]

Verwijderd schreef op 20 september 2002 @ 11:41:
Tijd om je component te debuggen.

Met de volgende code kan je Events in je event log schrijven, zodat je precies kan zien wat er gebeurt in je component terwijl die draait.

code:

'informatie event
App.LogEven("Hier wat informatie", vbLogEventTypeInformation)  
'warning event
App.LogEven("Hier wat informatie", vbLogEventTypeWarning)  
'error event
App.LogEven("Hier wat informatie", vbLogEventTypeError)

Verder kan je InProc DLLs debuggen door een ProjectGroup aan te maken binnen dezelfde development environment. OutOfProc COM componenten kun je debuggen door 2 development environments te gebruiken, 1 met de aanroepende code en de tweede met de code van je COM component.

Succes

We hebben het iets anders opgelost. We hebben de DLL direct contact laten maken met de database (ASP manier zeg maar).
Hij doet het nu perfect, en draait als een zonnet.... euh SOAP request