Auf dieser Seite des Dialogfelds Eigenschaften für DLL ist eine detaillierte Konfiguration einer DLL möglich.

Die Seite enthält folgende Komponenten:

Option Beschreibung
Fehlersuche aktivieren

Aktiviert die automatische Fehlersuche für die Anwendung, DLL, .NET-Interop-Assembly oder den Webdienst.

Hinweis Das Deaktivieren dieses Dialogfelds ist kein Garant für eine vollständige Optimierung.
  • Fehlersuche vor Ausführungsbeginn—

    Legt fest, dass die Anwendung, DLL oder .NET-Interop-Assembly geladen, aber erst nach Aktivierung der LabVIEW-Fehlersuchelemente ausgeführt werden soll. Diese Option kann nur aktiviert werden, wenn sich im Optionsfeld Fehlersuche aktivieren ein Häkchen befindet.
Schnelles Dateiformat verwenden

Speichert die eigenständige Anwendungen (EXE) oder DLLs in einem Format, das schneller geladen wird. Stellen Sie vor dem Verwenden des schnellen Dateiformats sicher, dass die Option Fehlersuche aktivieren auf der Seite Fortgeschritten nicht aktiviert ist.
Fehlercodedateien kopieren

Fügt Kopien der Textdateien mit LabVIEW-Fehlercodes im XML-Format aus den Verzeichnissen project\errors und user.lib\errors zur Runtime-Engine hinzu.

Hinweis Sie müssen manuell einen Ordner Fehler im Verzeichnis labview\user.lib anlegen, um die Fehlercodedateien zu ordnen.
Benutzerdefinierte Aliasdateien verwenden

Kopiert die Aliasnamen des Projekts in die Anwendung, DLL oder .NET-Interop-Assembly. Wenn Sie die Option deaktivieren, wird das Dialogfeld "Projektdatei auswählen" angezeigt und Sie können innerhalb des Projekts eine weitere Aliasdatei auswählen.

  • Aliasdatei im Projekt—

    Gibt die Aliasdatei für die Anwendung, DLL oder .NET-Interop-Assembly an, wenn die Option Standard-Aliasdatei verwenden nicht aktiviert ist.

    • Projekt durchsuchen—

      Zeigt das Dialogfeld Projektdatei auswählen an, in dem eine Aliasdatei ausgewählt werden kann.
Betriebssystemmeldungen in DLL verzögern

Zögert Meldungen des Betriebssystems so lange hinaus, bis Aufrufe von DLL-Funktionen abgeschlossen sind oder aus der DLL ein modales Dialogfeld geladen wurde.

Bei Bedarf können interne Meldungen des Betriebssystems (z. B. über Tastatureingaben oder Mausbewegungen) verzögert werden, so dass DLL-Funktion nicht in ihrer Ausführung gestört werden. Wenn eine DLL-Funktion also beispielsweise infolge eines Tastendrucks ausgeführt wird, sollte erst nach Ausführungsende der Funktion wieder auf ein Betätigen der Taste reagiert werden.

Wenn Sie ein modales Fenster von der DLL aus aufrufen, LabVIEW wird diese Option ignoriert. Das heißt, Systemmeldungen zum Öffnen modaler Fenster werden ungehindert ausgeführt. Während ein modales Fenster geöffnet ist, kann kein anderes Fenster bedient werden. Die meisten Dialogfelder in LabVIEW sind modale Fenster.

Wenn Meldungen des Betriebssystems auch bei laufenden DLL-Funktionen angezeigt werden sollen, deaktivieren Sie diese Funktion.
Zusätzliche LabVIEW-Header-Dateien einschließen

Kopiert alle LabVIEW-Header-Dateien, auf die die im Build-Prozess erzeugte Header-Datei verweist, in die erzeugte DLL. Dadurch können Sie eine in LabVIEW erzeugte DLL in C oder anderen Programmiersprachen verwenden, bei denen solche Header-Dateien benötigt werden.
Erweiterte DSC-Laufzeit-Unterstützung aktivieren

Diese Option wird nur bei installiertem LabVIEW Datalogging and Supervisory Control (DSC) Module angezeigt. Erstellt die Anwendung mit der verbesserten Runtime-Engine des LabVIEW DSC Moduls (DSC – Datalogging and Supervisory Control). Mit der Runtime-Engine für das DSC-Modul können mit den Anwendungen, die mit dem DSC Module erzeugt werden, Projektbibliotheken und Umgebungsvariablen programmatisch verwaltet werden.

Diese Option muss in folgenden Fällen aktiviert werden:
  • Die zu erstellende Anwendung bearbeitet die Bibliotheksdatei programmatisch mit Hilfe von VI-Server-Referenzen.
  • Die zu erstellende Anwendung enthält das VI "In Bibliothek speichern".
Wenn in diesen Fällen die DSC-Modul-Runtime-Engine nicht aktiviert ist, gibt LabVIEW bei Ausführung der Anwendung, DLL oder .NET-Interop-Assembly den Fehlercode 1055 aus.
Hinweis Beim Aktivieren dieser Option erhöht sich die Dateigröße und der Start der Anwendung, DLL oder .NET-Interop-Assembly verlangsamt sich.
Embedded-Runtime-Engine verwenden

(Linux) Erzeugt die DLL mit Hilfe der Embedded-Version der Runtime-Engine. Diese Option ist für Umgebungen vorgesehen, auf denen die DLL ohne Frontpanel oder Bedienoberfläche laufen soll.
Build-Protokolldatei erzeugen

Gibt an, ob für den Build eine Protokolldatei erstellt werden soll. In der Protokolldatei werden alle im Build enthaltenen Dateien einschließlich der SubVIs aufgelistet, die weder unter Zu startende VIs noch unter Immer enthalten aufgeführt sind. Die Protokolldatei enthält auch allgemeine Build-Informationen wie die Start- und Endzeit, Build-Spezifikation und Projektname und Fehler, die während der Erstellung auftraten.

  • Pfad zur Protokolldatei—

    Gibt den Pfad zum Speichern der Protokolldatei für den Build an.
Datei-Layout von LabVIEW 8.x verwenden

Gibt an, dass die Quelldateien einer Anwendung, DLL oder eines Webdienstes in einem linearen Datei-Layout gespeichert werden sollen. Bei Build-Spezifikationen, die Sie aus LabVIEW 8.6 oder einer älteren Version laden, ist diese Option standardmäßig aktiviert. Bei Anwendungen, die in LabVIEW-Versionen ab 2009 entwickelt werden, wird empfohlen, die Option zu deaktivieren.
Kompatibilitätsmodus von LabVIEW 2011

Gibt an, dass die Quelldateien einer Anwendung, DLL oder eines Webdienstes in einem linearen Datei-Layout gespeichert werden sollen. Bei Build-Spezifikationen, die Sie aus LabVIEW 8.6 oder einer älteren Version laden, ist diese Option standardmäßig aktiviert. Bei Anwendungen, die in LabVIEW-Versionen ab 2009 entwickelt werden, wird empfohlen, die Option zu deaktivieren.

In der folgenden Liste werden die Unterschiede zwischen den zwei Modi beschrieben.

Kompatibilitätsmodus von LabVIEW 2011 LabVIEW 2012 (und neuer)
LabVIEW erzeugt den Namen der C-Funktion aus dem VI-Namen. Die übergeordnete Bibliothek wird nicht im Funktionsnamen aufgeführt. LabVIEW erzeugt für Projekt-VIs qualifizierte Namen für C-Funktionen. Ein qualifizierter Name ist ein Name, der aus der übergeordneten Bibliothekshierarchie eines VIs und dem VI-Namen besteht. Wenn beispielsweise Zahlenspiel.vi zur Mathebibliothek.lvlib gehört, lautet der Name der C-Funktion Mathebibliothek_Zahlenspiel. Bei Projekten, die in LabVIEW-Versionen vor 2012 erstellt wurden und von denen bereits exportierte VIs existieren, hat der erzeugte Funktionsprototyp keinen qualifizierten Namen. Damit diese Funktionen mit qualifiziertem Namen versehen werden, müssen Sie die betreffenden VIs auf der Seite Quelldateien aus der Liste Exportierte VIs entfernen und anschließend noch einmal zur Liste Exportierte VIs hinzufügen.
Für Typdefinitionen von LabVIEW-Enums, -Clustern und -Arrays werden allgemeine Typnamen wie TD1 oder TD2 erzeugt. LabVIEW erzeugt qualifizierte Typnamen für Enum-, Cluster und Array-Typdefinitionen durch Beibehalten des Typnamens, den Sie in LabVIEW angegeben haben. Bei Enums, Clustern und Arrays, die keine Typdefinitionen sind, erzeugt LabVIEW aussagekräftigere Namen dafür. Beispiele dafür wären: int32Array, Cluster1 oder Enum1.
Die erzeugte Header-Datei enthält keine Enum-Werte. Die erzeugte Header-Datei enthält Enum-Werte.
Funktionen, die aus VIs mit den Fehler-Clustern Fehler (Eingang) und Fehler (Ausgang) erzeugt werden, enthalten ebenfalls die Parameter Fehler (Eingang) und Fehler (Ausgang). Beim Erzeugen einer C-Funktion für ein VI werden die Cluster Fehler (Eingang) und Fehler (Ausgang) nicht als Parameter der Funktion exportiert. Stattdessen enthält der Ausgabewert der Funktion den Fehlercode des Clusters Fehler (Ausgang). Verwenden Sie zum Abfragen der Fehlermeldung die Funktion LVGetLastErrorMsg und zum Beseitigen der Fehlermeldung die Funktion LVClearLastErrorMsg in der Header-Datei extcode.h. Diese Datei befindet sich im Verzeichnis labview\cintools. Bei VIs, die mehrere Parameter des Typs Fehler (Ausgang) enthalten, können Sie im Dialogfeld VI-Prototyp festlegen auswählen, mit welchem Parameter die erzeugte Funktion Fehlerangaben ausgeben soll.
Typbibliothek für TestStand oder Knoten zum Bibliotheksaufruf aufnehmen

Gibt an, dass die Quelldateien einer Anwendung, DLL oder eines Webdienstes in einem linearen Datei-Layout gespeichert werden sollen. Bei Build-Spezifikationen, die Sie aus LabVIEW 8.6 oder einer älteren Version laden, ist diese Option standardmäßig aktiviert. Bei Anwendungen, die in LabVIEW-Versionen ab 2009 entwickelt werden, wird empfohlen, die Option zu deaktivieren.

Zum Einbinden einer Typbibliothek müssen Sie zusätzliche Werkzeuge installieren. Sie finden diese Werkzeuge auf ni.com/info nach Eingabe des Infocodes DownloadMSDTBuildTools.
VIs in privatem Ausführungssystem ausführen

Konfiguriert LabVIEW so, dass es VIs in einem Ausführungssystem mit mehreren Threads ausführt, wenn in LabVIEW erzeugte DLLs Anwendungen anderer Programmiersprachen aufrufen. Diese Option ist für neue Build-Spezifikationen standardmäßig aktiviert und für Build-Spezifikationen aus LabVIEW 2016 oder älter deaktiviert. (NI Linux Real-Time) Diese Option ist standardmäßig für Linux-Real-Time-Zielsysteme deaktiviert, um potentielle Fluktuationen in der Leistung zu vermeiden.

Für neue Build-Spezifikationen ist diese Option standardmäßig aktiviert. Für Build-Spezifikationen, die aus LabVIEW 2016 oder älteren LabVIEW-Versionen stammen, ist diese Option per Standardeinstellung deaktiviert, um die beabsichtigte Funktionsweise der DLLs zu wahren. Auf diese Weise wird zum Beispiel verhindert, dass für die Einzel-Thread-Ausführung vorgesehene DLLs, die in LabVIEW erzeugt wurden, von einem Programm in einer Multithreading-Umgebung aufgerufen werden.
Künftigen LabVIEW-Runtime-Versionen das Laden dieser DLL gestatten

Binärdateien können entweder in die LabVIEW-Versionen geladen werden, mit denen sie erstellt wurden, oder in die neueste Version der LabVIEW-Runtime-Engine, die auf dem Computer installiert ist. Diese Option trifft auf Standalone-Anwendungen, DLLs, komprimierte Projektbibliotheken und Quellcodepakete zu. Bei Build-Spezifikationen, die Sie in LabVIEW 2017 oder einer neueren Version erzeugen, ist diese Option standardmäßig aktiviert. Bei Real-Time-Anwendungen wird diese Option nicht im Dialogfeld angezeigt, weil die Funktion standardmäßig aktiviert ist.

Sie können diese Option deaktivieren, wenn Sie eine Build-Spezifikation an eine bestimmte Version von LabVIEW binden möchten. Das Deaktivieren dieser Option verhindert Änderungen an den Leistungsprofilen, wodurch aus Compiler-Upgrades resultierende unerwartete Probleme vermieden werden.

Erstellen und Verteilen von Anwendungen Home