Laden...

[erledigt] COM DLL Abhängigkeitsprobleme lösen

Erstellt von Christoph Burgdorf vor 14 Jahren Letzter Beitrag vor 14 Jahren 9.037 Views
Christoph Burgdorf Themenstarter:in
365 Beiträge seit 2004
vor 14 Jahren
[erledigt] COM DLL Abhängigkeitsprobleme lösen

Hallo miteinander,

wir haben hier einige kleinere externe Access Anwendungen für Sage Office Line 4.0 entwickelt. Die Office Line stellt für die Steuerung durch externe Programme diverse COM DLLs bereit. Deren Nutzung unter Access haben mir bisher keine Probleme bereitet.

Nun wollte ich mal eine dieser Anwendungen auf .NET portieren und stehe vor dem Problem, dass offenbar unter den COM DLLs Abhängigkeiten bestehen, denen ich nicht Herr werde.

Ich erhalte folgenden Fehler:

"Die Abhängigkeiten des COM-Verweises "OLAbfBasic40" konnten nicht ermittelt werden. Fehler beim Laden der Typbibliothek/DLL. (Ausnahme von HRESULT: 0x80029C4A (TYPE_E_CANTLOADLIBRARY))"

Ich habe alle Verweise auf im System bereits vorhandenen COM DLLs so gesetzt, wie ich es auch in den Access Programmen gemacht habe.

Das wären:

*Visual Basic For Applications
*Microsoft Access 11.0 Object Library
*Microsoft DAO 3.6 Object Library
*Microsoft ActiveX Data Objects 2.1 Library
*OLE Automation
*Microsoft Windows Common Controls 6.0 (SP6)

Mag sein, dass es Quatsch ist einige hiervon meinem .NET Projekt hinzuzufügen. Ich dachte mir aber erstmal wäre es besser zu viel als zu wenig zu referenzieren 😉

Und dann habe ich noch die entsprechenden Office Line DLLs als Verweise hinzugefügt. Alles so wie auch in Access.

Die meisten Verweise scheinen auch keine Probleme zu machen. Lediglich 4 (von 9) referenzierten Office Line DLLs schmeißen entsprechende Fehler (siehe oben).

Nun bin ich bereits mit dem Tool Dependency Walker beigegangen und habe versucht zu ergründen, welche COM Abhängigkeiten möglicherweise noch bestehen. Daraus wurde ich aber auch nicht schlauer...

Kann mir jemand Tipps geben wie ich vorgehen sollte?

EDIT:

Ich sollte vielleicht nochmal erwähnen, dass ich auch bereits alle Office Line DLLs mit regsvr32 registriert habe...

Gruß

Christoph

383 Beiträge seit 2006
vor 14 Jahren

Entwickelst Du die .NET - Lösung auf der gleichen Maschine wie die Access-Lösung?

Christoph Burgdorf Themenstarter:in
365 Beiträge seit 2004
vor 14 Jahren

Hallo wakestar,

ich stehe kurz davor das zu tun 😉

Nein, im ernst. Damit hat es offenbar etwas zu tun. Ich habe gemerkt, dass das Access Programm auch nicht funktioniert, wenn ich es hier lokal auf meinem Entwicklungsrechner ausführe. Also fehlt mir hier in meiner Entwicklungsumgebung noch irgendwas. Nur wie finde ich denn jetzt raus, was mir fehlt?

Ich kann doch jetzt nicht beigehen und Visual Studio auf dem Terminalserver installieren und wohlmöglich alle User ausm Programm schmeißen, weil bei mir irgendwas im IDE abraucht 😉

Gruß

Christoph

383 Beiträge seit 2006
vor 14 Jahren

Nur wie finde ich denn jetzt raus, was mir fehlt?

Versuchs mal mit dem Process Monitor:
http://technet.microsoft.com/de-de/sysinternals/bb896645(en-us).aspx

einfach am Visual Studio anhängen und schauen was da File- und Registrymässig abläuft, bevor der Fehler gespuckt wird.

Christoph Burgdorf Themenstarter:in
365 Beiträge seit 2004
vor 14 Jahren

Hallo wakestar,

danke, ich wühle mich da gerade durch. Ich glaube ich habe schon ein paar interessante Zugriffe entdeckt.

Gruß

Christoph

383 Beiträge seit 2006
vor 14 Jahren

... ansonsten auf der "produktiven" Umgebung an der Access - Lösung anhängen und nach "OLAbfBasic40" suchen

Christoph Burgdorf Themenstarter:in
365 Beiträge seit 2004
vor 14 Jahren

Super! Problem gelöst. Vielen Dank für deine Hilfe!

Gruß

Christoph

1.274 Beiträge seit 2005
vor 14 Jahren

Remote- Debugging oder verstehe ich da was falsch?

"Das Problem kennen ist wichtiger, als die Lösung zu finden, denn die genaue Darstellung des Problems führt automatisch zur richtigen Lösung." Albert Einstein

Christoph Burgdorf Themenstarter:in
365 Beiträge seit 2004
vor 14 Jahren

Hallo LastGentleman,

was meinst du? Ich hatte COM DLLs eingebunden, die intern auf weitere COM DLLs verwiesen haben. Um herauszufinden um welche DLLs es sich dabei handelt habe ich den Process Monitor verwendet. Jetzt habe ich die fehlenden DLLs ebenfalls auf meinen Entwicklungsrechner kopiert und entsprechend mit regsvr32 registriert. Und nun fluppt alles 😃

Gruß

Christoph

1.274 Beiträge seit 2005
vor 14 Jahren

OK, danke Christoph. Du hast mir die Antwort damit gegeben.

lg
LastGentleman

"Das Problem kennen ist wichtiger, als die Lösung zu finden, denn die genaue Darstellung des Problems führt automatisch zur richtigen Lösung." Albert Einstein