DLLs für Unity: Wie man eine DLL als Abhängigkeit in einem Unity-Package exportiert und in anderen Projekten verwendet (Teil 3)

Im dritten Teil unserer Artikel-Serie über DLLs in Unity zeigen wir, wie man Unity-Projekte, die eine eigene DLL verwenden, als Package exportiert und wieder in andere Projekte importiert.

Einleitung

Im zweiten Teil unserer Anleitung haben wir geprüft, ob das Singleton funktioniert und die Instanz über mehrere Szenen hinweg gehalten wird. Jetzt wollen wir schauen, wie man zwei Unity-Projekte, die beide die im ersten Teil erstellte DLL verwenden, als Unity-Packages mit Abhängigkeit exportiert und in einem neuen Projekt beide Packages wieder importiert.

Zum vorherigen Teil: DLLs für Unity: Wie man ein GameObject als Singleton erstellt und über den Szenenwechsel behält (Teil 2)

Versionshinweis

In diesem Beitrag wurden Tools mit folgenden Versionen verwendet:

  • Unity 2019.3.6
  • Visual Studio 2017 (15.9.6)
  • Visual Studio Code 1.43.2
  • .NET Framework 4.6.1

Unity Package inklusive DLL als Dependency

Eine zweite Applikation erstellen

Zunächst benötigen wir eine zweite Applikation. Dazu erstellen wir ein neues Unity Projekt und ziehen wieder die DLL in einen Ordner unter Assets.

Achtung: 

Für den Ordner der DLLs wurde bewusst ein anderer Name gewählt als in der ersten Anwendung, um zu schauen, was später beim Import der gleichen DLL in ein Projekt passiert.

Dann erstellen wir ein neues Script, in dem wir die Klasse aus der DLL verwenden wollen.

Den Code halten wir sehr simple und legen lediglich fest, dass die Komponente, die dieses Script erhält als Singleton behandelt wird.
Die Klasse PersistentSingleton ist in unserer Klassenbibliothek in der DLL enthalten.

Jetzt erstellen wir eine SampleScene und fügen dieser ein leeres GameObject hinzu.

Dem fügen wir im Inspektor unser eben erstelltes Script hinzu.

Erste App mit Abhängigkeiten als Package exportieren

Jetzt wollen wir das erste Unity-Package erstellen. Dazu markieren wir den Ordner aus dem Assets-Folder, der unser Paket werden soll und öffnen mit der rechten Maustaste das Kontextmenü. Dort wählen wir Export Package.

Hier listet uns Unity die Dateien auf, die ins Paket übernommen werden. Per Standard ist Include dependencies angewählt. Deshalb wurde unser Ordner DDLs und die darin enthaltene DLL-Datei bereits zum Export vorausgewählt.
Mit Klick auf Export können wir einen Speicherort und Namen für das Paket angeben, bevor das Paket erstellt wird.

Zweite App mit Abhängigkeiten als Package erstellen

Auf die gleiche Weise exportieren wir nun den Ordner TestApp2 aus unseren zweiten Projekt.
Wieder inkludieren wir die Abhängigkeiten, also unseren DLL-Ordner.

Wir sollten nun zwei Unity-Packages vorliegen haben.

Als nächstes versuchen wir beide in einem weiteren Unity-Projekt zu importieren.

Beide Pakete mit Abhängigkeiten in ein gemeinsames Projekt importieren

Neues Projekt anlegen

Wir legen also ein neues Projekt an, an dem wir den Import demonstrieren wollen. Ein einfaches 2D-Projekt genügt.

Erstes Package importieren

Nun importieren wir das erste Package. Dazu wählen wir im Menü Import Package und dann Custom Package.

Nun können wir im Dateiauswahldialog das Paket wählen.

Unity zeigt uns an, was im Paket enthalten ist und wir können entscheiden, was wir importieren wollen.
Wir wählen hier alles aus.

Nach dem Import finden wir die neuen Assets in Form der Ordner DLLs und TestApp1 in unserem Projekt.

Zweites Package importieren

Jetzt wollen wir das zweite Paket importieren. Wie wir sehen, enthält das ebenfalls unsere DLL, nur in einem anderen Ordner.

Hinweis: 

Hätten wir den Ordner für die DLL im zweiten Paket gleich genannt, könnten wir das Häkchen nicht anhaken. Gleiche Ordner können nicht doppelt importiert werden.

Wir lassen alles ausgewählt und starten den Import.

Wir haben zwei neue Ordner erhalten.

Und jede Menge ROT.

Doppelte Imports – Fehler beheben

In der Console werden uns Fehler ausgegeben.

Unity erkennt also, dass die gleiche DLL zwei mal vorhanden ist.

PrecompiledAssemblyException: Multiple precompiled assemblies with the same name MyUtilities.dll included for the current platform. Only one assembly with the same name is allowed per platform. Assembly paths: Assets/DLLs/MyUtilities.dll, Assets/MyDlls/MyUtilities.dll

Wir können nun einfach eine der beiden DLLs löschen.

 

Imports in einer Szene testen

Jetzt testen wir noch schell, ob unsere importierten Scripte fehlerfrei funktionieren.
Dazu erstellen wir eine neue Szene und ein leeres GameObject, in diesem Beispiel mit dem Namen GameManagerSingleton.

Diesem fügen wir die Singleton-Komponenten hinzu.

Wenn wir das Spiel starten, erkennen wir, dass das Objekt als Singleton behandelt wird, da es unter DontDestroyOnLoad aufgelistet ist.

Build testen

Zum Schluss testen wir den Build-Prozess. Dazu wählen wir im Menü wieder BuildSettings und fügen die Beispielszene zu Scenes In Build hinzu.

Fazit

Es baut, es rennt, alles klappt.
Wir haben erfolgreich eine Klassenbibliothek für Unity als DLL erstellt, diese in Unity verwendet, als Abhängigkeit in einem Unity-Package exportiert und in einem neuen Projekt wieder importiert.

Wir können nun also Code, den wir wiederverwenden wollen in eine Klassenbibliothek auslagern und in allen unseren Unity-Projekten darauf zugreifen. Sogar in Packages, die wir eventuell im Asset Store bereitstellen wollen.
Da haben wir dann sogar den Vorteil, dass dieser Teil des Codes nicht von den Käufern eingesehen werden kann.

Damit schließen wir diese Artikel-Serie vorerst ab. Eventuell schauen wir uns noch an, wie man eine solche DLL nur mit Visual Studio Code erstellt.
Bis dahin hoffe ich, diese erstbeste Lösung war hilfreich.

Ähnliche Beiträge

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert