Dll registreringsproblem

bruger du andre komponenter i din dll som han ikke har registreret på sin server? Eller bruger du evt. andre versioner (fx nyere) af komponenter i din dll som han ikke har registreret?

/nuno

Det kan godt vaere. Jeg har flg. dll refereret i mit projekt:
3 VB application, procedues referencer
OLE Automation
Active DS Automation
EXOLEDB Typelibrary
Active X Data objects 2.5
CDO for Exchange Library
CDO for Exchange Management Library

Jeg har ikke styr paa de forskellige versioner, men har laest noget om at man kan saette en parameter om hvorledes dll\'en skal haandtere forskellige versioner, er det denne der skal pilles ved i mit projekt. Hvordan undgaar man kompatibilitets problemer ved distribution af sine dll\'er ?

Deres setup er at Exchange serveren er paa en maskine, mens deres AD domain controller er paa en anden. Mit setup er begge paa samme server. ER det her problemet er, da jeg har en reference til Active DS Automation?

Her er et screen dump af fejl meddelelsen

http://www.angelfire.com/tx5/mjanum/New%20Folder/COMError.jpg

Jeg har proevet at fjerne Active DS referencen, men sidder stadig fast :-(

Linket virker naar du udskifter %20 med et space i browserens URL :-)

Prøv at registrere filen med enten:

Clireg32.exe
eller
Regsvr32.exe

Begge filer medfølger på VB\'cden.

Hej Johs
Det har jeg sikret mig er gjort paa serveren.

Hej mjanum. Jeg kan ikke finde billedet på den adresse du har givet, men...

Jeg har siddet med lignende problemer og jeg løste det ved at lave et installationsprogram med vb\'s \"Package and Deployment Wizard\". Den kan finde ud af hvad det kræver at kører dit program og så kan den gøre nogle ting \'behinde the sceens\' som vist ikke er helt dokumenteret ;).

Hvis det ikke virker så kan du prøve at fjerne de direkte referancer til exchange og lave en createobject(<dit exchange object>) i stedet. Problemet med direkte referancer (early binding) er at den kræver en specifik version af de dll\'er der bruges, og det gøre createobject (Late binding) ikke.

Jeg loeste det :-). Efter at have laest adskillelige newsgroups igennem, fandt jeg en gut, som havde haft samme problem. Han Loeste det ved at lave en export af COM+ Applicationen til en .msi fil, naar denne koeres paa en anden server, registrerer den dll\'erne og laver COM+ Applicationen automatisk, uden fejl af en eller anden aarsag.

Oswald tak for indlaegget, rart at vide at der er noget MS der er udokumenteret..hehe. Og nice to know about late / early bindings :-)

Ikke for at være nøjeregnende, men var det ikke det jeg forslog, bare i en opdateret version?

Maaske, jeg troede du mente VB\'s deploy wizard, istedet laver jeg en Export fra COM+ MMC\'en.

Det er ikke nøjaktigt det samme, men en MSI fil er en \'MicroSoft Installer\' fil, altså et installations program. Men jeg er ikke bitter ;)