Hinzufügen von Skriptfunktionen zu .NET-Anwendungen

  • Ich habe ein kleines Spiel in C # geschrieben. Es verwendet eine Datenbank als Backend. Es ist ein ein Sammelkartenspiel , und ich wollte die Funktion der Karten als script.

    Was ich damit meine, ist, dass ich im Wesentlichen eine Schnittstelle ICard habe, die eine Kartenklasse implementiert (public class Card056 : ICard) und eine Funktion enthält, die vom Spiel aufgerufen wird .

    Um die Sache wartungsfähig / moddierbar zu machen, möchte ich die Klasse für jede Karte als Quellcode in der Datenbank haben und im Wesentlichen beim ersten Gebrauch kompilieren. Wenn ich also eine Karte hinzufügen / ändern muss, füge ich sie einfach zur Datenbank hinzu und fordere meine Anwendung zur Aktualisierung auf, ohne dass eine Assembly-Bereitstellung erforderlich wäre (insbesondere da wir von einer Baugruppe pro Karte sprechen würden, was Hunderte von Baugruppen bedeutet). .

    Ist das möglich? Registrieren Sie eine Klasse aus einer Quelldatei und instanziieren Sie sie usw.

     ICard Cards[current] = new MyGame.CardLibrary.Card056();
    Cards[current].OnEnterPlay(ref currentGameState);
     

    Die Sprache ist C #, aber zusätzlicher Bonus Wenn es möglich ist, das Skript in einer beliebigen .NET-Sprache zu schreiben.

    24 August 2017
    Peter FeatherstoneMichael Stum
9 answers
  • C # Script-Lösung von Oleg Shilo (at Das Code-Projekt ) ist wirklich eine großartige Einführung in das Bereitstellen von Skriptfähigkeiten in Ihrer Anwendung.

    Ein anderer Ansatz wäre, eine Sprache zu betrachten, die speziell für das Erstellen von Skripts entwickelt wurde. wie IronRuby , IronPython oder Lua .

    IronPython und IronRuby sind beide heute verfügbar.

    Eine Anleitung zum Einbetten von IronPython finden Sie in So integrieren Sie die Unterstützung für das IronPython-Skript in Ihre vorhandene App in 10 ea sy steps .

    Lua ist eine Skriptsprache, die häufig in Spielen verwendet wird. Es gibt einen Lua-Compiler für .NET, der bei CodePlex erhältlich ist - http: / /www.codeplex.com/Nua

    Diese Codebase ist eine großartige Lektüre, wenn Sie sich mit dem Erstellen eines Compilers in .NET vertraut machen möchten.

    Ein anderer Blickwinkel ist der Versuch, PowerShell zu versuchen. Es gibt zahlreiche Beispiele für das Einbetten von PowerShell in eine Anwendung. Hier ist ein ausführliches Projekt zum Thema: Powershell-Tunnel

    17 August 2012
    Eduardo Molteni
  • Möglicherweise können Sie IronRuby dafür verwenden.

    Andernfalls würde ich vorschlagen, dass Sie ein Verzeichnis haben, in dem Sie vorkompilierte Assemblys platzieren. Dann könnten Sie in der DB einen Verweis auf die Assembly und die Klasse haben und Reflection verwenden, um die richtigen Assemblys zur Laufzeit zu laden.

    Wenn Sie zur Laufzeit wirklich kompilieren möchten könnte den CodeDOM verwenden, dann können Sie die dynamische Assembly mit Reflektion laden. MSDN-Artikel, der möglicherweise hilft .

    02 August 2008
    Eric Haskins
  • Wenn Sie das DLR nicht verwenden möchten, können Sie verwenden Sie Boo (das einen Dolmetscher hat) oder Sie könnten das Script.NET (S #) Projekt auf CodePlex . Mit der Boo-Lösung können Sie zwischen kompilierten Skripts oder der Verwendung des Interpreters wählen. Boo macht eine schöne Skriptsprache, verfügt über eine flexible Syntax und eine erweiterbare Sprache über die offene Compiler-Architektur. Script.NET sieht aber auch gut aus, und Sie können diese Sprache und ihr Open-Source-Projekt problemlos erweitern und verwenden einen sehr freundlichen Compiler Generator ( Irony.net ).

    09 August 2008
    Nathan
  • Sie können alle DLR-Sprachen verwenden, mit denen Sie Ihre eigene Scripting-Plattform ganz einfach hosten können. Sie müssen dazu jedoch keine Skriptsprache verwenden. Sie können C # verwenden und mit dem C # -Code-Provider kompilieren. Solange Sie es in einer eigenen AppDomain laden, können Sie es nach Herzenslust laden und entladen.

    02 August 2008
    Jesse Ezell
  • Ja, ich habe darüber nachgedacht, aber ich habe schnell herausgefunden, dass eine andere Domain-Specific-Language (DSL) etwas zu viel wäre.

    Im Wesentlichen: Sie müssen auf möglicherweise unvorhersehbare Weise mit meinem Spielstand interagieren. Eine Karte könnte beispielsweise eine Regel haben: "Wenn diese Karten ins Spiel kommen, erhalten alle Ihre untoten Schergen +3 Angriff auf fliegende Feinde, außer wenn der Feind gesegnet ist". Da Sammelkartenspiele rundenbasiert sind, löst der GameState-Manager OnStageX-Ereignisse aus und lässt die Karten andere Karten oder den GameState auf beliebige Weise modifizieren.

    Wenn ich versuche zu erstellen Bei einem DSL muss ich ein ziemlich großes Feature-Set implementieren und möglicherweise ständig aktualisieren, wodurch die Wartungsarbeiten auf ein anderes Teil verlagert werden, ohne es tatsächlich zu entfernen.

    Deshalb wollte ich bleiben mit einer "echten" .NET-Sprache, um im Wesentlichen nur das Ereignis auslösen zu können und die Karte den Spielstand auf beliebige Weise (innerhalb der Grenzen der Codezugriffssicherheit) manipulieren zu lassen.

    26 November 2010
    Peter Mortensen
  • Ich würde vorschlagen, LuaInterface zu verwenden, da Lua dort, wo es so scheint, vollständig implementiert wurde Nua ist nicht vollständig und implementiert wahrscheinlich keine sehr nützlichen Funktionen (Coroutines usw.).

    Wenn Sie einige der vorverpackten Lua-Module von außen verwenden möchten, würde ich die Verwendung von vorschlagen Etwas in der Art von 1.5.x im Gegensatz zu der 2.x-Serie, die vollständig verwalteten Code erstellt und die erforderliche C-API nicht verfügbar machen kann.

    17 September 2008
    harningt
  • Ich benutze LuaInterface1.3 + Lua 5.0 für eine Anwendung von NET 1.1.

    Das Problem mit Boo ist, dass jedes Mal, wenn Sie Ihre Dateien analysieren / kompilieren / auswerten Code on the fly, erstellt eine Reihe von Boo-Klassen, so dass Sie Speicherlecks bekommen.

    Lua dagegen tut das nicht, daher ist es sehr stabil und funktioniert sehr gut wunderbar (ich kann Objekte von C # an Lua und zurück übergeben).

    Bisher habe ich es noch nicht in PROD aufgenommen, erscheint aber sehr vielversprechend.

    Ich hatte Probleme mit dem Speicherleck in PROD mit LuaInterface + Lua 5.0 . Daher habe ich Lua 5.2 verwendet und mit DllImport direkt in C # verlinkt. Die Speicherlecks befanden sich in der LuaInterface-Bibliothek.

    Lua 5.2: von http://luabinaries.sourceforge.net und http://sourceforge.net/projects/luabinaries/files/5.2/Windows%20Libraries/Dynamic/lua-5.2_Win32_dll7_lib.zip/download

    Nachdem ich dies getan hatte, waren alle Speicherlecks verschwunden und die Anwendung war sehr stabil.

    01 September 2017
    Peter Mortensen
  • Mit der Hauptanwendung, die meine Abteilung verkauft, können Kundenanpassungen sehr ähnlich gestaltet werden (dh, ich kann keine Quelle veröffentlichen). Wir haben eine C # -Anwendung, die dynamische VB.NET-Skripts lädt (obwohl jede .NET-Sprache leicht unterstützt werden kann - VB wurde ausgewählt, weil das Anpassungsteam aus einem ASP-Hintergrund stammte).

    Mit .NET's CodeDom kompilieren wir die Skripte aus der Datenbank und verwenden VB CodeDomProvider (ärgerlich ist es standardmäßig auf .NET 2 eingestellt. Wenn Sie 3.5-Funktionen unterstützen möchten, müssen Sie ein Wörterbuch mit "CompilerVersion" = "v3.5" übergeben. zu seinem Konstruktor). Verwenden Sie die Methode CodeDomProvider.CompileAssemblyFromSource, um sie zu kompilieren (Sie können Einstellungen übergeben, um die Kompilierung nur im Speicher zu erzwingen.

    Dies würde zu Hunderten von Assemblies im Speicher führen, aber Sie könnten dies tun Der gesamte dynamische Klassencode wird in einer einzigen Assembly zusammengefasst, und bei einer Änderung wird das gesamte Lot erneut kompiliert. Dies hat den Vorteil, dass Sie ein Flag zum Kompilieren auf der Festplatte mit einem PDB zum Testen, damit Sie den dynamischen Code debuggen können.

    10 January 2010
    Peter Mortensen
  • In der nächsten Version von .NET (5.0?) wurde viel über das Öffnen des "Compilers als Dienst" geredet, mit dem eine direkte Skriptbewertung möglich wäre.

    27 November 2010
    Peter Mortensen