Announcement

Collapse
No announcement yet.

dcuil nicht gefunden

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • dcuil nicht gefunden

    Hallo
    ich habe mir ein Package gemacht, in dem ich einige Functionen und Proceduren habe.
    Jetzt wollte ich die DLL in mein aktuelles Projekt einbinden
    Referenz hinzufügen
    nur jetzt kommt immer der Fehler er kann die dcuil nicht finden

    weiß jemand rat?

    Raimund

  • #2
    Hallo,
    eine in Delphi geschriebene und mit Delphi 2005 kompilierte Assembly-DLL kann nur in einem C#- oder VB.NET-Projekt als einzelne Assembly-DLL eingebunden werden. Wenn ein in Delphi geschriebenes .NET-Projekt diese Assembly-DLL einbinden soll, muss zusätzlich auch die .DCPIL-Datei mit weitergeben werden (wobei beide Projekt mit der exakt gleichen Delphi 2005-Version kompiliert werden müssen).

    Delphi hat schon immer die benötigten Symbolinformationen in separaten Dateien mit der Dateiendung .dcu (Win32) oder .dcuil/dcpil (.NET) abgelegt. Aus der Sichtweise von Delphi greift der Kompiler dabei immer auf den vollständig qualifizierten Bezeichnernamen zu, so dass sogar ein mehrfaches Vorkommen von gleichen Bezeichnern in verschiedenen Units nicht zum Problem wird. Allerdings hat Borland mit Delphi 2005 auch neue Namespace-Regeln eingeführt, um ein von vielen Entwicklern bemängeltes Problem von Delphi 8 zu lösen. Als unerwünschte Nebenwirkung hat das Entfernen des letzten durch den Punkt abgetrennten Namespace-Teils jedoch zur Folge, dass sich Delphi immer dann am eigenen Output verschluckt, wenn der Struktur einer Library-Assembly nachträglich wieder über Reflection ausgelesen werden soll. Denn dann sind nur die „offiziellen“ Daten sichtbar, aber nicht mehr in der Assembly untergebrachten Hilfsdaten. Da Delphi 8 noch streng der Regel „Eine Unit = Ein Namespace“ folgte, konnte Delphi 8 die Library-Assembly problemlos auf dem offiziellen Weg einlesen.

    Im Fall einer Package-Assembly legt Delphi 2005 neben der Assembly-DLL mit den offiziellen Informationen auch eine .dcpil-Datei mit den eigenen Hilfsdaten an, während er das im Fall eines Library-Projekts nicht macht. Sobald nun ein anderer Entwickler die gleiche Package-Assembly in sein eigenes Projekt verbauen will, besorgt er sich beide Dateien. Wenn er dann in Delphi einen Verweis auf die Package-Assembly hinzufügt, stehen die Interna in der dcpil-Datei zur Verfügung, so dass der Kompiler an alle die Informationen herankommt, die er für seinen Job benötigt. Dies gilt auch für den Fall, dass eine Unit die $WEAKPACKAGEUNIT-Kompilerdirektive nutzt, um zum Beispiel P/Invoke-Deklarationen aus dem veröffentlichten Inhaltsverzeichnis der Assembly zu entfernen. Diese Hintergründe sorgen nun im Worst Case auch dafür, dass ein Zugriff von einer in C# geschriebenen Anwendung auf die Delphi-Package nicht mehr möglich ist, wenn dort diese Sonderfälle vorkommen.
    <br>
    Lange Rede - kurzer Sinn: Delphi 2005 nutzt zur Zeit einen Hack, der zu einer technisch nicht sauberen Implementierung führt

    Comment


    • #3
      Hallo
      soll ich jetzt meine Package's lieber alle in eine Library packen?
      aber ich dachte ich kann ne Library nur win32 unter dalphi nutzen und nicht für net.

      was mache ich aber wenn ich ein projekt habe das ich mit delphi2005 update 1 geschreiben habe und nun meine dll mit update 2 reinkopiere?
      fliegt mir mein programm um die ohren

      Comment


      • #4
        Hallo,
        rein technisch gesehen ist in der .NET-Welt sowohl eine Library als auch eine Package eine Assembly-DLL (bei der Konkurrenz VS.NET wird ja sowohl in C# als auch in VB.NET eine Assembly-DLL als <i>Class Library</i> bezeichnet). In Delphi 8 war eine kompilierte Library einer kompilierten Package gleichgesetzt. Mit Delphi 2005 spielt der Unterschied zwischen einer Library und einer Package nur dann <b>keine</b> Rolle, wenn diese Assembly-DLL in einen C#- oder VB.NET-Projekt eingebunden wird. Wenn allerdings ein mit Delphi 2005 kompiliertes und in der Sprache Delphi geschriebenes Programm diese Assembly nutzen soll, muss diese zwingend als Package kompiliert werden. Bei einer Library kommt sofort die Fehlermeldung <i>„[Fatal Error] F2458 Cannot import metadata from Delphi 'library'. Use packages instead“.</i>. Da die Entwicklungsumgebung Delphi 2005 beim Einbinden einer in der Sprache Delphi geschriebener Assembly-DLL die zusätzlichen Typinformationen aus der DCPIL-Datei benötigt, spielt in der Tat die Version eine Rolle. Nur dann, wenn die in der Sprache Delphi geschriebene Assembly-DLL von einer C#- oder VB.NET-Anwendung eingebunden wird, ist das völlig egal

        Comment


        • #5
          Hallo
          dann habe ich es richtig verstand und ein Problem!
          Ich schreibe meine Programme alle mit Delphi2005 Update2
          Ich muss dann, wenn ich dem Kunden eine neue DLL gebe auch gleich sein Projekt noch mal erzeugen und ihm nicht nur eine neue DLL geben sondern auch gleich noch sein ganzes Projekt, damit meine DLL funktioniert.
          Mit was für ein Fehler muss ich denn rechnen?
          Und wie kann man den anfangen.
          Ist irgendwann abhilfe zu erwarten

          Comment

          Working...
          X