Office: Regfree COM / Side-by-Side

Hallo Thomas!

Der fehlgeschlagene VB6-COM-Test ist noch der Original-Code von mir oder bereits dein veränderter Code?

Bezüglich CreateActCtx: das kann ich mittlerweile ausführen. ActivateActCtx läuft auch noch. Aber es hilft nicht für die Erstellung einer Instanz mit CoCreateInstance. Außerdem kracht es regelmäßig bei ReleaseActCtx -amnchmal bereits bei ActivateActCtx.

Code-Auszug:
Code:

Anm.: Context = ACTCTX-Struktur
Code:

mfg
Josef

 

Hallo Josef,

ich habe den Test mit Deinen unveränderten Testklassen durchgeführt.

CU

 

Hallo!

Und es geht doch ... :-)
http://social.msdn.microsoft.com/For...e-b1e1d1194207

mfg
Josef

 

Danke Josef *top
Hab den Thread verfolgt und kann die Lösung evtl. sogar in nächster Zeit für ein Problem brauchen...

 

Hallo!

Man kann mit etwas Getrickse sogar Early-Binding auf die nicht registrierte .net-COM verwenden, um z. B. auf Ereignisse zu reagieren. *Smilie

mfg
Josef

 

Wo wir hier gerade bei so einem Thema sind, hätt ich mal eine Frage zu einem konkreten Fall.
Ist zwar nahezu OT, geht aber letztlich auch um COM und, vmtl., Registrierung.

Folgende Konstruktion:
VB6-Anwendung mit ner Handvoll DLLs
Word/Office welche Referenzen auf dies hält
Betriebssystem ist Vista 32bit
Referenz lautet auf C:\Program Files\Appl\Datei1.tlb

Änderung des Betriebssystems von Vista 32bit auf Win7 64bit.
Referenzen werden, offenbar automatisch, korrekt auf C:\Program Files (x86)\Appl\Datei1.tlb geändert und alles funktioniert.

Nun wurde die VB6-Anwendung auf .NET migriert und genau dieser Automatismus bzgl. der Referenzen läuft nicht mehr.
Was natürlich dazu führt, dass meine Anwendung nicht läuft solange die Referenzen nicht angepasst werden.

Könnt ihr mir einen Tip geben in welche Richtung ich suchen muss?
Ich vermute den Fehler an der Registrierung bzw. Installation der Anwendung...

Problem ist, dass ich keinen Zugriff auf den Code der Anwendung habe und nicht sehe was dort wirklich passiert... ich soll/muss sie nur in meiner VBA-Anwendung nutzen *frown.gif*

Workaround bzw. bessere Lösung die ich auch umsetzen werde ist natürlich LateBinding.
Dennoch interessiert es mich wieso dieser automatische Switch nicht mehr klappt...

Wenns zu OT ist, bitte kurze Info, dann mach ich ggf. einen eigenen Thread auf *wink.gif*

 

Registrierung .... ihhh *biggrin.gif* *biggrin.gif* *biggrin.gif*

Wie registrierst du die dll? Mit dem Schalter /codebase?

LG
Josef

 

Ich gar nicht... das macht ein anderer Entwickler.
Ich denke dass er per /codebase registriert, ja.

Zumindest haben wir das bisher mit der alten Version (VB6) so getan.

Zu: "Registrierung .... ihhh"
Seit heute morgen denke ich ähnlich darüber *wink.gif*

 

Hallo!

/codebase ist ein Schalter der regasm .. die für die Registrierung einer COM-dll zuständig ist.
Schau einmal in die Registry, ob dort im Schlüssel "InprocServer32" ein Wert "CodeBase" enthalten ist.

mfg
Josef

 

Wollte ich eben nachschaun, dann wurde mir die Testumgebung bzw. der Client unter den Händen weggerissen *frown.gif*
Ich melde mich wenn ich weitere Infos habe... Danke auf jeden Fall.

 

Hallo!

Eine Testanwendung steht nun für Ac2010 zur Verfügung.
https://svn.access-codelib.net/svn/R...st_Acc2010.zip

mdb (keine mde) im Acc2002/2003-Format: https://svn.access-codelib.net/svn/R...st_Acc2002.zip

Zum Testen: accde öffnen und am Anfang das Formular "frmLibRepair" starten , damit die Bibliotheken ins Anwendungverzeichnis erstellt werden. Das Formular schließt sich selbsttändig nach dem Speichern der Dateien.
Anschließend kann das Formular "TestFormular" zum Testen geöffnet werden.
Anm.: in einer richtigen Anwendung, würde man das Formular "frmLibRepair" (o.ä.) als Startformular verwenden.

mfg
Josef

 

Hallo!

Eines muss bei der .net-COM-dll beachtet werden:
Wenn man unterschiedliche Namespaces verwendet, so muss man die Klasse inkl. Namespace und nicht über die ProgID ansprechen. (So wie die Klassen von der CLR gesehen wird. - Irgendwie sogar logisch. *wink.gif*)

Beispiel-Code (C#)
Scenario:
Code:

Beispiel aus Test-Anwendung:
Code:

Würde die .net-dll registriert sein, könnte man diesen Aufruf verwenden:
Code:

=> Was ist am sinnvollsten?
In der .net-COM nur einen Namespace (=Lib-Name) einsetzen, oder die Namespaces dokumentieren? (Wenn man eine Manifestdatei erstellt, werden diese angezeigt.)

Beispiel-Eintrag in Manifest-Datei:

PHP:

         <clrClass clsid="{8363614A-E20E-4182-8A34-6B316D3BC24E}"
progid="NetComClassLibrary.SqlGenerator"
threadingModel="Both"
name="NetComClassLibrary.Data.SQL.SqlGenerator"
runtimeVersion="">
</clrClass>


 

Hallo,
Nach langem Suchen habe ich diesen Beitrag gefunden.

Ich soll eine Access2003-DB und ein Excel-Addon, die beide zwei Dritt-Hersteller-COM-DLLs benötigen, auf Windows-Terminalserver-Clients unter CITRIX auf einem modifizierten Windows Server 2003 Betriebssystem zum Laufen bekommen, ohne die DLLs zu zu registrieren.

Im Anhang ist ein Beispiel mit einer VB6-COM-dll.
Anm.: wenn man aus der COM-dll eine tlb erstellt, kann man sogar Early Binding verwenden.


Jetzt wäre es noch schön, wenn das auch mit einer .net-COM-dll klappen würde.

mfg
Josef

Wenn ich jedoch die diesem Beitrag anhängende DB ausführe, erhalte ich den Fehler 429 'Objekterstellung durch ActiveX-Komponente nicht möglich' bei der Zeile

Code:

Woran könnte das liegen, ich verwende XP SP3 zum testen, ist ActCtx hier eventuell nicht verfügbar?

Bitte um Hilfe.

Vielen Dank

Bernd

 

Hallo!

Das kann durchaus sein, dass ActCtx nicht verfügbar ist.
Solange du keine .net-COM verwendest, kommst du aber auch mit DirectCOM von Olaf Schmid aus.

mfg
Josef

 

Hallo Josef,
mit DirectCOM habe ich es schon probiert, funktioniert unter XP, aber leider nicht in der CITRIX-Umgebung. Olaf ist auch ratlos, ich habe intensiv mit ihm kommuniziert. Ich hatte gehofft, die Manifest-Methode würde auf WIN2003 funktionieren, aber auch da ging nix. Müssen in der DB Verweise auf ActCtx gesetzt werden? In der Download-DB habe ich keine gefunden.

Gruß

Bernd