none
DLL kann unter 64bit-Windows nicht geladen werden - Fehler 429

    Frage

  • Hallo,

    zum soundsovielten Mal Fehler 429. Leider habe ich für meine Situation nichts passendes gefunden.

    So ist die Situation:

    Meine DLL wurde unter VB 6.0 (Sp6) entwickelt und besorgt eigentlich nur die Verwaltung von einigen Einstellungen  zu einer Anwendung. Die Einstellungen werden in eine XML-Datei gespeichert und der Zugriff erfolgt über MSXML6. Keine Datenbankzugriffe,  - nur Lesen und Schreiben in eine XML-Datei. Es sind allerdings werden noch für zwei Properties  API-Funktionen benötigt.

    Die DLL arbeitet anstandslos in einer 32-Bit-Umgebung. Nun wollte ich diese DLL auch unter Windows 7 x64 testen. Dort konnte ich sie nur mir regsv32 aus syswow64 registrieren. Danach lies sie sich probelmlos in eine Access-mdb einbinden; der Objekt-Explorer und Intellisense präsentierten sämtliche Klassen mit allen Methoden und Eigenschaften einwandfrei. Leider kommt es dann beim Zugriff auf eine Klassen aus dieser DLL sofort zum Fehler 429.

    Ich beschäftige mich noch nicht lange mit der x64-Welt. Allerdings würden die API-Funktionen in x64-Access die PtrSafe Deklaration erfordern. Könnte dort die Ursache liegen? Und wie könnte man dies umgehen?


    Grüße aus Köln am Rhein - Klaus Trapp

    Donnerstag, 10. Mai 2012 17:42

Antworten

Alle Antworten

  • Danach lies sie sich probelmlos in eine Access-mdb einbinden; der Objekt-Explorer und Intellisense präsentierten sämtliche Klassen mit allen Methoden und Eigenschaften einwandfrei. Leider kommt es dann beim Zugriff auf eine Klassen aus dieser DLL sofort zum Fehler 429.

    Hallo Klaus Trapp,

    Von welchem Access ist die Rede? Access 2003?

    Versuchen wir mal im Access Forum.

    Grüße,

    Robert


    Robert Breitenhofer, MICROSOFT  Twitter Facebook
    Bitte haben Sie Verständnis dafür, dass im Rahmen dieses Forums, welches auf dem Community-Prinzip „Entwickler helfen Entwickler“ beruht, kein technischer Support geleistet werden kann oder sonst welche garantierten Maßnahmen seitens Microsoft zugesichert werden können.

    Dienstag, 15. Mai 2012 14:09
    Besitzer
  • Hallo!

    Falls du Office/Access in 64 bit verwendest, kannst du keine 32-bit-dll nutzen.
    Du kannst aber ein 32-bit-Office in einem 64-bit-Windows installieren, dann kannst du auch wieder die 32-bit-dll verwenden.

    Aufgrund von "der Objekt-Explorer und Intellisense präsentierten sämtliche Klassen" wirst du aber vermutlich eine 32-bit-Version von Access verwenden. Zumindest hoffe ich, dass bei einem 64-bit-Access keine 32-bit-dlls angezeigt werden. ;-)

    /edit: gerade ausprobiert: 32-bit-dlls werden in Office 64-bit auch angezeigt, obwohl sie nicht verwendet werden können.

    mfg
    Josef


    Code-Bibliothek für Access-Entwickler
    AccUnit - Testen von Access-Anwendungen
    Virtueller Access-Stammtisch



    Dienstag, 15. Mai 2012 15:55
  • ****************************************************************************************************************
    Dieser Thread wurde mangels weiterer Beteiligung des Fragestellenden ohne bestätigte Lösung abgeschlossen.
    Neue Rückfragen oder Ergänzungen zu diesem Thread bleiben weiterhin möglich.
    ****************************************************************************************************************

    Robert Breitenhofer, MICROSOFT  Twitter Facebook
    Bitte haben Sie Verständnis dafür, dass im Rahmen dieses Forums, welches auf dem Community-Prinzip „Entwickler helfen Entwickler“ beruht, kein technischer Support geleistet werden kann oder sonst welche garantierten Maßnahmen seitens Microsoft zugesichert werden können.

    Montag, 21. Mai 2012 16:48
    Besitzer
  • Hallo Josef, in der Tat handelt es sich im vorliegenden Fall um 64-bit Access (2010), wo, wie Du bereits festgestellt hast, der Objekt-Explorer die Funktionalität der DLL anzeigt  und auch sonst nichts beim Verweis oder beim Kompilieren auf einen Fehler hindeutet. Der Fehler meldet sich erst zur Laufzeit.

    Okay, es geht nun mal so nicht. Nun möchte ich aber nicht auf 32-bit Office umsteigen. Was kann man da tun? VB 6.0 bietet schließlich keine 64-bit-Variante an. Ich nehme mal an, dass eine Reihe ähnlicher Fälle gegeben hat. Gibt es da soetwas wie eine allgemeine Strategie? Wo wäre die zu finden? 


    Grüße aus Köln am Rhein - Klaus Trapp

    Dienstag, 22. Mai 2012 12:43
  • Hallo!

    Die allgemeine Strategie ist, die 32-bit- statt der 64-bit-Version zu installieren. ;-)
    Welchen Vorteil siehst du bei der 64-Bit-Version? Benötigst du die Möglichkeit in Excel mehr Spalten/Zeilen zu verwenden?

    Das Problem bei der 64-Bit-Version ist vor allem, dass gängige Add-Ins nicht laufen, weil viele in VB6 erstellt wurden.

    Du kannst natürlich auch die COM-dll mit VB.net erzeugen. Dann hättest du die Möglichkeit diese auch mit der 64-Bit-Version zu verwenden.

    mfg
    Josef


    Code-Bibliothek für Access-Entwickler
    AccUnit - Testen von Access-Anwendungen
    Virtueller Access-Stammtisch

    Dienstag, 22. Mai 2012 12:51
  • Hallo,

    es ist zwar schon eine Weile her, aber nun ist es mir endlich gelungen meine DLL unter VB.NET (2010) nachzubauen (u.a. mit einigen inhaltlichen Änderungen - insbesondere werden jetzt Einstellungen in einer XML-Datei statt in der Registry gespeichert).

    Mein Access ist nach wie vor die 64-bit-Ausgabe 2010.

    Nun habe ich die DLL erstellt und in den Projektoptionen wird mir unter Plattform 'Aktiv (Any CPU)' angezeigt, was ich so interpretiere, dass sie auch für 64-Bit-Anwendungen nutzbar ist. Leider aber verweigert mein Access die Nutzung der DLL mit der Meldung: Verweis auf angegebene Datei kann nicht hinzugefügt werden.

    Ich hatte zwischendurch die Option 'Für COM-Interop regististriern' aktiviert - ohne Erfolg.
    Was muss ich sonst noch beachten?

    Okay, es wird nicht mehr lange dauern und ich ersetzte die 64-Bit-Office Version durch die 32-Bittige, aber ich fände es ganz toll, wenn es mit der 64er-Version funktionieren würde.


    Grüße aus Köln am Rhein - Klaus Trapp

    Freitag, 22. Februar 2013 12:43
  • Am 22.02.2013 schrieb Klaus Trapp:

    Ich hatte zwischendurch die Option 'Für COM-Interop regististriern' aktiviert - ohne Erfolg.
    Was muss ich sonst noch beachten?

    Ich weiß nicht, ob ich vollkommen daneben liege, aber schau dir doch
    diesen Thread an. Das ging in die von dir gewünschte Richtung:
    http://social.msdn.microsoft.com/Forums/de-DE/accessde/thread/2bca8a20-d551-45fb-925e-f7bacb356f7b

    Servus
    Winfried


    Connect2WSUS: http://www.grurili.de/tools/Connect2WSUS.exe
    GPO's: http://www.gruppenrichtlinien.de
    Community Forums NNTP Bridge: http://communitybridge.codeplex.com/

    Freitag, 22. Februar 2013 16:25
  • Hallo Winfried,

    danke, das ging schon mal in die gewünschte Richtung, aber noch nicht bis zum Ziel. Mir würde ja ein 'registrierter' Zugriff auf die DLL reichen. Habe diese also (als Admin) mit der COM-Interop-Option und 'Assembly-COM-sichtbar machen' neu erstellt und mit regasm registriert (Types  registered successfully).

    Dennoch findet sich unter den Verweisen in Access kein entsprechender Eintrag (was ich auch nicht so ganz erwartet habe) und bei der direkten Auswahl der DLL kommt wieder die Meldung, dass der Verweis auf diese Datei nicht hinzugefügt werden kann - wie bereits gehabt.

    Ganz schlau bin ich aus dem o.a. Thread und den dort verlinkten Threads auch nicht geworden. Ich denke auch, es fehlt jetzt nicht mehr viel, oder?


    Grüße aus Köln am Rhein - Klaus Trapp

    Freitag, 22. Februar 2013 23:40
  • Am 23.02.2013 schrieb Klaus Trapp:

    danke, das ging schon mal in die gewünschte Richtung, aber noch nicht bis zum Ziel. Mir würde ja ein 'registrierter' Zugriff auf die DLL reichen. Habe diese also (als Admin) mit der COM-Interop-Option und 'Assembly-COM-sichtbar machen' neu erstellt und mit regasm registriert (Types  registered successfully).

    Dennoch findet sich unter den Verweisen in Access kein entsprechender Eintrag (was ich auch nicht so ganz erwartet habe) und bei der direkten Auswahl der DLL kommt wieder die Meldung, dass der Verweis auf diese Datei nicht hinzugefügt werden kann - wie bereits gehabt.

    Die TLB kannst Du in den Verweisen einbinden.
    http://access.joposol.com/know-how/com-activex/office-com-add-in-mit-visual-basic-2005-express-edition-erstellen.html
    In diesem Artikel wird das alles beschrieben.

    Such doch mal danach in obigen Artikel: 'Diese Klasse ist nun bereits
    in VBA verwendbar.' Das Posting von Jesef Pötzl vom 11.11.2012 09:11
    suchst Du.

    Servus
    Winfried


    Connect2WSUS: http://www.grurili.de/tools/Connect2WSUS.exe
    GPO's: http://www.gruppenrichtlinien.de
    Community Forums NNTP Bridge: http://communitybridge.codeplex.com/

    Samstag, 23. Februar 2013 15:39
  • Hallo Winfried, ich dachte schon, es geht voran ...

    Ist es mir doch wirklich geglückt, meine DLL aus VS2012 heraus odnungsgemäß zu registrieren. Warum es nun doch funktionierte,  ist mir nicht ganz klar, es war wieder mit Admin-Rechten und COM-Sichtbarkeit.

    Meine Freude war entsprechend groß, als ich dann auch in Access unter den Verweisen meine DLL entdeckt, übrigens anhand der Beschreibung aus den Assemblyinformationen, nicht mit dem dortigen Titel. Da die DLL auschließlich ehemals vorhandene Klassen aus Access (fast eins zu eins) enthält, war mein Access-Code rasch angeapasst. Debugging lief fehlerfrei. Etwas irritierend war, das Intellisense zwar die Klassen innehalb der DLL erkannte und anzeigte, nicht aber die Funktionen und Methoden. Aberwas kam beim Start: Fehler 429 - also wieder am Anfang.

    Ich habe dann noch ein paar Einstellungen für die Erstellung der DLL im Konfiguarationsmanager variiert: Relaese, statt Debug, sogar x64 statt Any CPU - ohne Erfolg.

    Ich habe mir dann mal in Access im Objektkatalog meine DLL angeschaut. Dort sind, wie das Intellisense-Verhalten auch vermuten lässt, alle Klassen angezeigt, aber alle ohne Fuktionalität. Das Einzige, was noch sichtbar ist, sind meine Enums.

    Nun bin über den Artikel Deines Link auf die Klasseneinstellungen:
    <System.Runtime.InteropServices.ComVisible(True)> _
    <Microsoft.VisualBasic.ComClass()> _
    gestossen.

    Dummerweise führen die zu Fehlern, wenn die Klasse eine Collection enthält. Gut, .NET-Collections sind vermutlich etwas völlig anderes als solche aus altem VB/VBA. Ich muss mal schaun, ob und wie ich das auf Arrays o.ä. umgestellt bekommen.

    Wenn ich die obige Spezifizierer in den Collection-Klassen weggelassen, dann kann ich meine DLL auch wieder erstellen und dann sind im Objektkatalog auch dort alle öffentlichen Eigenschaften und Methoden sichtbar. Wenn ich dann allerdings versuche, eine solche Klasse anzuspreche, ja was bekomme ich da? Fehler 429.

    Ich werde mich jetzt erstmal der Collection-Problematik widmen und melde mich dann wieder.

     

    Grüße aus Köln am Rhein - Klaus Trapp

    Montag, 25. Februar 2013 12:27
  • Am 25.02.2013 schrieb Klaus Trapp:

    Ist es mir doch wirklich geglückt, meine DLL aus VS2012 heraus odnungsgemäß zu registrieren. Warum es nun doch funktionierte,  ist mir nicht ganz klar, es war wieder mit Admin-Rechten und COM-Sichtbarkeit.

    Von einer TLB war in dem Artikel die Rede.

    Servus
    Winfried


    Connect2WSUS: http://www.grurili.de/tools/Connect2WSUS.exe
    GPO's: http://www.gruppenrichtlinien.de
    Community Forums NNTP Bridge: http://communitybridge.codeplex.com/

    Montag, 25. Februar 2013 18:06
  • Von einer TLB war in dem Artikel die Rede.

    Das meine ich ja auch; für mich gehört das zusammen, was beim 'Erstellen einer VB-Klassenbibliothek (.dll)', wie es in Visual Studio heißt, herauskommt.


    Grüße aus Köln am Rhein - Klaus Trapp

    Montag, 25. Februar 2013 19:09
  • Am 25.02.2013 schrieb Klaus Trapp:

    Von einer TLB war in dem Artikel die Rede.

    Das meine ich ja auch; für mich gehört das zusammen, was beim 'Erstellen einer VB-Klassenbibliothek (.dll)', wie es in Visual Studio heißt, herauskommt.

    Bei mir konnte ich die TLB in den Verweisen einbinden und vollständig
    nutzen.

    Servus
    Winfried


    Connect2WSUS: http://www.grurili.de/tools/Connect2WSUS.exe
    GPO's: http://www.gruppenrichtlinien.de
    Community Forums NNTP Bridge: http://communitybridge.codeplex.com/

    Montag, 25. Februar 2013 20:35
  • Wenn ich die obige Spezifizierer in den Collection-Klassen weggelassen, dann kann ich meine DLL auch wieder erstellen und dann sind im Objektkatalog auch dort alle öffentlichen Eigenschaften und Methoden sichtbar. Wenn ich dann allerdings versuche, eine solche Klasse anzuspreche, ja was bekomme ich da? Fehler 429.

    Mit den COMVISIBLE-Einstellungen stellt du u. a. ein, was über die tlb sichtbar werden soll.

    Du kannst in .NET ruhig die .NET-Collection verwenden, solange du keine solche Collection in VBA verwenden musst.
    Tipp: schalte nicht die ganze Klasse sondern nur die Methoden und Eigenschaften COM-sichtbar, die du in VBA benötigst.
    Falls du eine Methode mit Collection-Parametern COM-sichtbar machen willst, könntest du einstellen, dass statt Collection einfach nur Object COM-sichtbar wird.

    In C# würde das ungefähr so aussehen:

    void MachWas([MarshalAs(UnmanagedType.IDispatch)] out object CollectionParameter);

    Bezüglich der 64-Bit-Problematik:
    Ich probierte es selbst noch nicht aus, aber könnte das eventuell ein Problem mit regasm sein?
    Vielleicht gibt es vermutlich auch eine 32- und eine 64-bit-Variante wie bei resgsvr32... und ich kann mir vorstellen, dass die VisualStudio-Umgebung das 32-bit-Regasm verwendet. ;)
    Das autoamtische COM-Registrieren nach jedem Kompilieren würde ich übrigens nicht einschalten, da das zu sher vielen Versionen führen kann.

    Ich verwende dafür eine kleine Batch-Datei, die ich im Projektordner ablege und bei Bedarf als Administrator ausführe.

    mfg
    Josef


    Code-Bibliothek für Access-Entwickler
    AccUnit - Testen von Access-Anwendungen
    Virtueller Access-Stammtisch



    Dienstag, 26. Februar 2013 08:52
  • Hallo Winfried, hallo Josef,

    hier noch mal kurz der Stand der Dinge:

    Mein Projekt wurde zum Erstellen eine VB-Klassenbibiliothek (.dll) unter Visiual Studio 2010 angelegt.
    Im Projekt selbst werden einen Anzahl von Klassen, die zuvor in einem Access-Projekt genutzt wurden, zusammengefasst; im Access-Projekt wurden die entsprechenden Klassen entfernt.
    Sämtliche Klassen wurden deklariert mit
     <System.Runtime.InteropServices.ComVisible(True)> _
     <Microsoft.VisualBasic.ComClass()> _
     Public Class ...

    Der Fehler, der in Zusammenhang mit Collections auftrat, wurde dadurch behoben, dass einige durch Arrays ersetzt werden konnten und die restlichen als Friend deklariert wurden, also nach außen nicht sichtbar sind.

    '[Projektname] erstellen' lief nur als Admin, liefert aber dann unter bin\Debug eine dll-, tlb-, xml und pdb-Datei. Hierbei war unter Kompilieren 'Debug' und 'Any CPU'  und 'Für COM-Interop registrieren' eingestellt. Unter den Assemblyinformationen war 'Assembly COM-sichtbar machen' aktiviert.
    RegAsm.exe wurde nicht zusätztlich bemüht.

    Unter Access 2010 (x64) fand ich in den Verweisen mein Projekt wieder und zwar mit der Bezeichnung wie im Feld Beschreibung der Assemblyinformationen eingetragen mit Verweis auf die tlb-Datei im bin\Debug-Verzeichnis. Nach Aktivierung des Verweises waren im Objektkatalog sehr schön alle Klassen mit Eigenschaften und Methoden sichtbar (offenbar dank der ComVisible(True)-Einstellung). Kompilieren des Access-Projekt lief fehlerfrei durch. Beim Starten des Projekt kam dann mit dem ersten externen Klasseaufruf wieder Fehler 429. Ich bin ratlos.

    Übrigens, der Versuch statt 'Any CPU' als Platform x64 zu nutzen brachte nichts - noch nicht einmal eine tlb-Datei.

     


    Grüße aus Köln am Rhein - Klaus Trapp

    Dienstag, 26. Februar 2013 14:39