none
Fehlermeldung "DLL-Registerserver Eingangspunkt wurde nicht gefunden"

    Question

  • Hallo miteinander, 

     

    ich habe in VS2010 eine DLL erstellt und versuche nun diese im System zu registrieren - mit einem Installer oder mit regsvr32.exe. In beiden Faellen bekomme ich eine Fehlermeldung, die besagt, dass der Eingangspunkt (entry point) fuer den DLL-Registerserver nicht gefunden wurde.

    In den Projekt-Einstellungen in VS2010 habe ich die Assembly auf COM-sichtbar gesetzt.

    Muss ich noch irgendwelche Einstellungen an der Projektkonfiguration vornehmen, damit die DLL registriert werden kann?

     

    Schoenen Gruss,

     

    Martin

    Monday, October 31, 2011 4:41 PM

Answers

  • Hallo Martin

    wenn du mit VB.NET entwickelst, entsteht keine 'native' DLL sondern eine Assembly, welche man mit anderen Tools/Massnahmen für COM-Interop registrieren muss  (also nicht  mit regsvr32 uä).
    Grundlagen

    Regasm.exe (Assembly Registration Tool)
    http://msdn.microsoft.com/en-us/library/tzat5yw6(v=VS.100).aspx

    Visual Studio (keine Express!),
    Setup Project, Register for COM interop
    http://msdn.microsoft.com/en-us/library/w29wacsy(v=VS.100).aspx

    wenn du andere (non-MS Studio) Installer anwendest, musst du dessen Anleitung/Hersteller fragen.

     

    Monday, October 31, 2011 4:51 PM
  • Martin,

    zum GAC: dies ist eine Ablage die primär erst zu Laufzeit auf dem Zielrechner ('beim Endanwender') eine Rolle spielt. Daher ja auch mein Hinweis zum Setup-Projekt (mind. bei Studio PRO), wo es die Registrierung im GAC mitintegriert gibt  (ohne manuelle gacutil-Übung).

    Zu Entwicklungs-/Design-Zeit hat der GAC da zuerst mal keine Rolle (daher sind eigene Assemblies auch nicht automatisch als Verweise für im Studio sichtbar!)

    Wenn deine eigene Lib-DLL auf längere Sicht stabil bleibt, dann kann die Lösung aus dem KB306149 ein Weg sein. (wobei dessen ursprüngliche Sinn AFAIK für Studio-extensions/tools war).
    [beachte, es gibt da neu auch den Key AssemblyFoldersEx, lies die Links unten]

    Ansonst ist die parallele Weiterentwicklung (Debugging) von DLL + EXE wie gesagt über die gemeinsame Projektmappe im Vorteil.

    http://msdn.microsoft.com/en-us/library/wkze6zky(v=VS.100).aspx

    http://msdn.microsoft.com/en-us/library/ez524kew(v=VS.100).aspx

    http://msmvps.com/blogs/p3net/pages/integrating-gac-assemblies-with-visual-studio.aspx

     

    Monday, November 07, 2011 6:56 PM
  • Hallo Thomas,

     

    danke fuer den Tipp zu den Assemblies und zum GAC. Das war der entscheidende Hinweis, der mich weitergebracht hat. Allerdings war die Loesung letztendlich viel einfacher.

    Um eine eigene DLL im GAC zu registerieren geht man vor wie hier beschreiben:

    http://support.microsoft.com/kb/315682/en-us

    Dazu braucht man die MS tools SN.exe und gacutil.exe. Ausserdem muss die Assembly einen starken Namen haben. Auf diese Weise habe ich meine DLL tatsaechlich im GAC sehen koennen. 

    Aber: In den Referenzen in VS tauchte sie trotzdem nicht auf. Diverse Forenbeitraege raten, die DLL direkt einzubinden, aber dann kann ich mir auch den Eintrag im GAC sparen.

    Die Loesung: Man muss einfach nur einen Registry-Key setzen, dessen Wert auf das Verzeichnis weist, in dem sich die DLL befindet. Dann werden die Klassen etc. auch ueber die Verweise in VS sichtbar. Das ganze ist hier beschrieben: 

    http://support.microsoft.com/default.aspx?scid=kb;en-us;306149

    Der Key ist folgender:

    [HKEY_CURRENT_USER\SOFTWARE\Microsoft\.NETFramework\AssemblyFolders\<var>MyAssemblies</var>]@="C:\\<var>MyAssemblies</var>"

    So einfach und doch so schwer....Zugegenerweise verzichtet man mit dieser Methode auf die Versionierung der DLL, die man bei GAC-Registrierung bekommt, aber das reicht im Moment.

     

    Schoenen Gruss,

     

    Martin

     

    • Marked as answer by mwunderlich2 Monday, November 07, 2011 8:45 AM
    Monday, November 07, 2011 8:45 AM

All replies

  • Hallo Martin

    wenn du mit VB.NET entwickelst, entsteht keine 'native' DLL sondern eine Assembly, welche man mit anderen Tools/Massnahmen für COM-Interop registrieren muss  (also nicht  mit regsvr32 uä).
    Grundlagen

    Regasm.exe (Assembly Registration Tool)
    http://msdn.microsoft.com/en-us/library/tzat5yw6(v=VS.100).aspx

    Visual Studio (keine Express!),
    Setup Project, Register for COM interop
    http://msdn.microsoft.com/en-us/library/w29wacsy(v=VS.100).aspx

    wenn du andere (non-MS Studio) Installer anwendest, musst du dessen Anleitung/Hersteller fragen.

     

    Monday, October 31, 2011 4:51 PM
  • Hallo Thomas,

     

    vielen Dank fuer die schnelle Antwort. Ich habe nun versucht, die DLL mit dem Regasm-Tool zu registrieren, was auch mit "Die Typen wurden registriert" bestaetigt wurde. Dies hat insofern funktioniert, als ich den Eintrag nun in der Liste mit den verfuegbaren COM-Verweisen sehe. Wenn ich diesen allerdings in ein Projekt einbinden will, bekomme ich eine Meldung (in VS2010), dass ich stattdessen doch bitte einen Verweis auf die .Net-Assembly setzen moechte. Leider ist meine DLL in der Liste der .Net-Verweise nicht enthalten.

    Woran koennte das liegen?

     

    Schoenen Gruss,

     

    Martin

    Tuesday, November 01, 2011 8:17 PM
  • Martin,

    es drängt sich jetzt eher die Frage auf, ob du wirklich eine DLL für alten native Code (also C++ Apps) erstellen willst, denn fast nur dazu ist COM-Interop (regasm, regsvr32) gedacht.

    Wenn es dagegen (hoffentlich) um eine managed-Code (.NET) Zielapplikation geht, dann erstellt man ganz normal eine Klassenbibliothek-Assembly (Datei heisst halt auch .DLL, hat aber nichts mehr mit COM zu tun), und arbeitet mit Verweisen:
    wenn (auf Entwickler-PC, im einfachsten Fall) der Sourcecode sowohl der App wie der Klassenbibliothek verfügbar ist, dann beide in dieselbe Projektmappe anlegen und mit einem Projektverweis arbeiten.
    Ein Visual Studio Setup-Projekt installiert dann sowohl EXE+DLL im selben Zielverzeichnis. Optional könnte man die DLL im GAC eintragen lassen und so dann systemweit verfügbar machen.

     

    Tuesday, November 01, 2011 10:13 PM
  • Hallo Thomas,

     

    danke fuer den Tipp zu den Assemblies und zum GAC. Das war der entscheidende Hinweis, der mich weitergebracht hat. Allerdings war die Loesung letztendlich viel einfacher.

    Um eine eigene DLL im GAC zu registerieren geht man vor wie hier beschreiben:

    http://support.microsoft.com/kb/315682/en-us

    Dazu braucht man die MS tools SN.exe und gacutil.exe. Ausserdem muss die Assembly einen starken Namen haben. Auf diese Weise habe ich meine DLL tatsaechlich im GAC sehen koennen. 

    Aber: In den Referenzen in VS tauchte sie trotzdem nicht auf. Diverse Forenbeitraege raten, die DLL direkt einzubinden, aber dann kann ich mir auch den Eintrag im GAC sparen.

    Die Loesung: Man muss einfach nur einen Registry-Key setzen, dessen Wert auf das Verzeichnis weist, in dem sich die DLL befindet. Dann werden die Klassen etc. auch ueber die Verweise in VS sichtbar. Das ganze ist hier beschrieben: 

    http://support.microsoft.com/default.aspx?scid=kb;en-us;306149

    Der Key ist folgender:

    [HKEY_CURRENT_USER\SOFTWARE\Microsoft\.NETFramework\AssemblyFolders\<var>MyAssemblies</var>]@="C:\\<var>MyAssemblies</var>"

    So einfach und doch so schwer....Zugegenerweise verzichtet man mit dieser Methode auf die Versionierung der DLL, die man bei GAC-Registrierung bekommt, aber das reicht im Moment.

     

    Schoenen Gruss,

     

    Martin

     

    • Marked as answer by mwunderlich2 Monday, November 07, 2011 8:45 AM
    Monday, November 07, 2011 8:45 AM
  • Martin,

    zum GAC: dies ist eine Ablage die primär erst zu Laufzeit auf dem Zielrechner ('beim Endanwender') eine Rolle spielt. Daher ja auch mein Hinweis zum Setup-Projekt (mind. bei Studio PRO), wo es die Registrierung im GAC mitintegriert gibt  (ohne manuelle gacutil-Übung).

    Zu Entwicklungs-/Design-Zeit hat der GAC da zuerst mal keine Rolle (daher sind eigene Assemblies auch nicht automatisch als Verweise für im Studio sichtbar!)

    Wenn deine eigene Lib-DLL auf längere Sicht stabil bleibt, dann kann die Lösung aus dem KB306149 ein Weg sein. (wobei dessen ursprüngliche Sinn AFAIK für Studio-extensions/tools war).
    [beachte, es gibt da neu auch den Key AssemblyFoldersEx, lies die Links unten]

    Ansonst ist die parallele Weiterentwicklung (Debugging) von DLL + EXE wie gesagt über die gemeinsame Projektmappe im Vorteil.

    http://msdn.microsoft.com/en-us/library/wkze6zky(v=VS.100).aspx

    http://msdn.microsoft.com/en-us/library/ez524kew(v=VS.100).aspx

    http://msmvps.com/blogs/p3net/pages/integrating-gac-assemblies-with-visual-studio.aspx

     

    Monday, November 07, 2011 6:56 PM
  • Hallo Thomas,

     

    vielen Dank fuer die zusaetzlichen Hinweise. Setup-Projekt ging leider nicht, da wir einen Nicht-MS-Installer im Einsatz haben (Tarma), der noch sehr viel mehr macht als nur das Projekt zu installieren.

     

    Der GAC hat uns heute uebrigens noch einen boesen Streich gespielt. Scheinbar haben Projekte in der Entwicklungsumgebung eine Praeferenz fuer im GAC registrierte DLLs und bevorzugen diese gegenueber den in der Projektmappe erzeugten DLLs - auch dann wenn der Verweis explizit auf das VS-Projekt gesetzt ist. Wir haben uns sehr gewundert, warum sich Aenderungen Code nicht niederschlagen, bis wir dann die DLL aus dem GAC entfernt haben. Daraufhin wurden wieder die aktuellen Bibliotheken der Entwicklungsumgebung verwendet.

     

    Schoenen Gruss,

     

    Martin

    Wednesday, November 09, 2011 6:01 PM