Office: Regfree COM / Side-by-Side

Hallo!

Sind es native COM-dlls (VB6 bzw. C++) oder wurden die möglicherweise mit .net erstellt?

mfg
Josef

 

Hallo Josef,
ich habe bisher nur mit Deiner DB ActCtxTest.accdb getestet, da sie ja funktionieren sollte.

Die dlls für die endültigen Anwendungen sind native COM-dlls, ob sie jetzt in VB6 oder C++ erstellt wurden, weiß ich nicht. Ich habe jedoch die Genehmigung des Erstellers zur Weitergabe. Mein Problem ist nur, das ich keine Erlaunis habe, sie auf dem Zielsystem zu registrieren.

Gruß

Bernd

 

Hallo!

Kannst du die dll auf deinem Entwicklungs-PC mit regsvr32 registrieren??

mfg
Josef

 

Hallo Josef,
Deine DB nutzt zum Testen eine 'ComClassLibrary.dll', manuell kann ich sie problemlos registrieren und deregistrieren.

Code:

Das bedeuted doch, dass ein acTCtx-Objekt nicht erstellt werden konnte, bevor es überhaupt Zugriff auf die ComClassLibrary.dll nimmt oder verstehe ich das falsch?

Gruß

Bernd

 

Hallo!

Das mit ActCtx hatte ich schon abgehakt. Wenn das über CreateObject nicht erzeugbar ist, brauchst du meiner Ansicht nach diesen Weg gar nicht weiterverfolgen.

Interessant ist, dass auch DirectCOM nicht funktioniert. Daher fragte ich nach, ob die COM-dll überhaupt mit regsvr32 registriert werden kann.
Oder kannst du auch meine Beispiel-dll nicht mit DirectCOM verwenden?

Anm.: Alternativ zu DirectCOM gibt es auch noch eine reine VB/VBA-Variante.

mfg
Josef

 

Hallo Josef,
verstehe das hab ich dann mißverstanden. Ich hab nach Anleitung von Olaf versucht, beliebige, auch System-COM-Dlls (scrrun.dll), die ich einfach an einen anderen Speicherplatz kopiert habe) zu laden, war das Ergebnis immer ..."Auf Einsprungpunkt '..' in DirectCom.dll kann nicht zugeriffen werden".

Das pre-Loadiing mit LoadLibrary hat noch funktioniert, aber sobald ich versucht habe, auf die Funktionen von DirectCOM zuzugreifen, kam oben genannter Fehler (Nur auf WIN2003/CITRIX), XPSP3 funktioniert).
Ich geh davon aus, dass es an einer Sicherheitseinstellung auf dem CITRIX-Server liegt, daher hatte ich gehofft, die Aktivierungskontext-Methode nutzen zu können, die laut MS ab WIN2003 standardmäßig dabei ist.

Gruß

Bernd

 

Hallo!

Du könntest noch die Variante ohne "Hilfs-Dll" ausprobieren.
modDirectCOM.bas

mfg
Josef

 

Hallo Josef,
ich hatte jetzt wieder die Möglichkeit, Deine TestDB auf dem Zielrechner auszuführen.
Code:

Dort gibt es also das Activation Context Objekt, nur scheint wieder das Berechtigungskonzept zuzuschlagen und mir nicht zu erlauben, irgendwelche Einträge vorzunehmen.
Das stimmt mich jedoch hoffnungsfroh, doch über diese Schiene weiterzukommen, sofern ich ActCtx auf meiner XP-Umgebung zum Laufen kriege.

Hat dazu Irgendjemand eine Idee, Google hilft mir hier nicht wirklich.

Gruß

Bernd

 

Hallo zusammen,

dieser Beitrag ist zwar schon älter, aber ich habe exakt das selbe Problem was CptChaos beschreibt.

Ich habe eine .net com-dll, und diese wird folgendermaßen registriert:
regasm.exe" "C:\Programme....\test.dll" /codebase "C:\Programme....\test.dll" \s

in mdb wird Verweis auf die test.tlb gesetzt. Passt alles, funktioniert

Nun auf einem 64 Bit rechner, dll wird wieder mit batch auf gleiche weise registriert, aber eben unter c:\program files (x86)...
Nur in der mdb wird anschließen der Verweis auf die test.tlb nicht gefunden. Klickt man auf den Verweis, so wird der Pfad der tlb mit c:\programme... angezeigt. Was ich nicht verstehe, woher kommt dieser Pfad, sollte das nicht aus der registry über die entsprechende guid kommen?

Wäre klasse, wenn hier einer helfen könnte. Ich habe zusätzlich CptChaos per email angeschrieben. Für den Fall das er sein damaliges Problem lösen könnte.

beste Grüße
BabOOn

 

Hi,

du musst halt in der neuen Umgebung den Verweis neu einbinden, das passiert nicht von allein.

 

Hallo Anne,

selbstverständlich ist mir klar, dass ich manuell einfach in der mdb den Verweis neu setzen kann. *wink.gif*

Aber genau das ist eben nicht gewünscht und auch gar nicht immer möglich, zb. wenn es eine mde ist...

Ich hab es nun allerdings schon selbst rausgefunden. Ich schreibs hier mal hin, weil ich es zum kotzen finde, wenn ich zwar Probleme die ich selber habe in Foren finde, aber am Ende des Threads heisst es dann:
"hat sich erledigt, funktioniert jetzt..." Ohne weitere Erklärung wie denn nun die Lösung aussieht. Bei sowas könnt ich... *mad.gif*

Also das ganze funktioniert so, dass ich nun in meiner batch die dll mit regasm registriere wie gewohnt, ich danach aber zusätzlich noch die tlb registriere. Dafür gibt es das Tool regtlibv12.exe im entsprechenden Framework-Verzeichnis.

Das wars auch schon, der Verweis in der mdb auf die tlb ist danach auf das richtige Verzeichnis umgebogen. Wenn die tlb nicht extra manuell zuvor mit regtlibv12 in Typelib registriert wird. So Scheint Access den Pfad auf die tlb aus der mdb selbst zu beziehen, woher genau da hab ich keine Ahnung... Spielt aber auch keine Rolle *grins

 

regasm kann mit dem Schalter /tlb auch selbst eine entsprechende tlb erstellen.
Das sollte an sich ausreichen und die Nutzung regtlibv12.exe erübrigen.