MS Visual Studio - Sprachen und Designer

[F.W.]

Hi Leutz!

Da ich an meiner BA die meiste Software von Microsoft zu Studienzwecken kostenlos beziehen kann, so auch Visual Studio 2008 Professional, habe ich mir dieses jetzt mal etwas genauer angesehen. Irgendwie finde ich mich da aber nicht ganz rein. Ich habe mir ein Bisschen Übersicht geschaffen, aber einiges überblicke ich trotzdem noch nicht, daher würde ich gern ein paar meiner Annahmen hier aufschreiben und ihr könntet mir dann sagen ob ich richtig denke? Das wär echt suppi, damit ich mein gefährliches Halbwissen erweitern kann ;-)

Mit Visual Studio 2008 Professional kann man .NET Programme schreiben, die die CLR (Common Language Runtime) benutzen und in einer Art Virtual Machine laufen, vergleichbar mit Java bzw. werden sie eben auch in Bytecode und sowas übersetzt.
Man kann aber auch die "alte" Technik verwenden, bei C++ wäre das dann MFC (Microsoft Foundation Classes), was dann eben direkt auf Windows läuft. (Vergleichbar mit VCL?)

Gibt es noch andere Arten von Programmen, die ich mit VS 2008 Pro schreiben kann? Und für welche bietet VS einen GUI Designer? So wie ich das mitbekommen habe, gibt es nur für Windows Forms (.NET) den Designer?

Mit der MFC kann man ja auch Fenster erstellen, aber dafür scheint es keinen GUI Editor zu geben oder? Dennoch muss ich dort nicht das Grundgerüst für die Programme mit RegisterWindowClass und sowas schreiben? Also gibt es ähnlich wie in Delphi vorgefertigte Objekte, eben nur nicht mit Designer?

Ich habe es letztens hinbekommen eine DLL in VC ++ zu schreiben, habe dabei Win32 Projekt ausgewählt. Gibt es eine Möglichkeit da jetzt ein Formular hinzuzufügen, welches von einer DLL Funktion dann erzeugt und so einer anderen Anwendung zur Verfügung gestellt wird? Und kann ich dieses mit einem GUI Designer entwerfen?
Im konkreten Fall geht es um einen Dialog mit Kalender über den ein Datum gewählt werden kann. Die DLL wird aus Excel aufgerufen.

Danke für eure Antworten!

[jfheins]

Also - du kannst neben c, c++ & c# auch asp.net (=Webanwendungen) schreiben und designen, sowie visual basic.

Außerdem solltest du neben Winforms auch WPF designen können und mfc müsste eigentlich auch gehen :gruebel:

[F.W.]

Ok, mit den Sprachen kann ich was anfangen :-)

Aber was ist jetzt WPF?

Ich glaube ich bin etwas verwöhnt von Delphi mit dem Designer. Kann es sein, dass es in anderen Sprachen gar nicht so normal ist, dass ein GUI Editor existiert?

Ich habe auch Probleme die Konzepte bei anderen Progsprachen zu überschauen. Bei Delphi ist es ja recht einfach, es gibt nur Borland/CodeGear Delphi mit der VCL. Aber bei C++ gibt es ja Borland/CodeGear C++ mit VCL und dann eben MS mit seinen ganzen Bibliotheken... (.NET, MFC, WPF, ..., ??? )

[mkinzler]

Zitat:

Aber was ist jetzt WPF?

Windows Presentation Framework: sozusagen Microsofts Version von XUL
http://de.wikipedia.org/wiki/Windows...ion_Foundation

[F.W.]

Ok, aus der Wikipediaseite geht hervor, was WPF ist und dass es scheinbar auch einen Designer gibt. Muss ich morgen mal suchen im VS.
Aber hat WPF eigentlich noch etwas mit den Sprachen C, C#, C++ und VB zu tun oder ist das dann komplett anders? Oder etwa nur eine Art die Oberfläche zu gestalten und drunter kann man die Sprachen legen??

Ach alles so schwierig *g*

Gute Nacht für heute erstmal und danke für die Antworten :-)

[jfheins]

WPF ist genau dafür gedacht, Code und GUI zu trennen. Das heißt (wenn ich das richtig verstanden habe) dass du einen GUI-Designer nehmen kannst, der die GUI designt und einen Programmierer, der die GUI mit Leben befüllt. Die GUI wird dabei in einer xml-artigen sprache geschriben und ist damit nicht abhängig von der verwendetetn Codesprache.

[F.W.]

Zitat:

Die GUI wird dabei in einer xml-artigen sprache geschriben und ist damit nicht abhängig von der verwendetetn Codesprache.

Cool, das wär ja mal was für mich :-) Wo ich doch gerade in andere Programmiersprachen mal reinschauen möchte :-)
Solange es einen Designer gibt...

[Khabarakh]

Aber Achtung, WPF ist - gelinde gesagt - abartig ;) . Das Framework ist einfach so verschieden von Winforms/VCL/MFC und besitzt eine steile Lernkurve, sodass du C# lieber schon davor halbwegs beherrschen solltest. Einen Designer wirst du erstmal auch nicht benötigen, der macht die Konzepte von XAML auch nicht einfacher ;) .
Deshalb kann ich für den Einstieg nur zu einem Buch raten, beispielsweise

[Fridolin Walther]

Auch für normale MFC Anwendungen existiert ein Designer. Bei MFC werden - genau wie bei der VCL übrigens - die Informationen über die sichtbaren Elemente in den Ressourcen abgelegt. Entsprechend findet sich bei MFC der Designer im Ressourcen Editor.

Erstell einfach mal eine neue MFC Applikation. Als Application Type gib am besten Dialog Based an, da der Designer für Dialog Based Applications am ehesten dem von Delphi bekannten Designer entspricht. Die anderen Einstellungen die abgefragt werden kannst Du beliebig setzen.

Sobald das Projekt erstellt ist, kannst Du die RC Datei in der Ressource Files Kategorie via Doppelklick öffnen. Im Abschnitt Dialog findest Du dann die definierten Dialoge und kannst sie editieren. Die verfügbaren visuellen Elemente findest Du dabei in der Toolbox.

Ich kann Dir auch die "How Do I" Videos von Microsoft wärmstens empfehlen. Die Auswahl an Themen ist zwar klein (und die Themen selbst sind für mich zumindest oft langweilig), aber man sieht das Arbeiten mit der IDE und lernt oft noch den ein oder anderen versteckten Punkt in der IDE kennen.

[mkinzler]

Zitat:

Erstell einfach mal eine neue MFC Applikation. Als Application Type gib am besten Dialog Based an, da der Designer für Dialog Based Applications am ehesten dem von Delphi bekannten Designer entspricht. Die anderen Einstellungen die abgefragt werden kannst Du beliebig setzen.

Wobei bei MFC der Komfort von Delphi in keinster Weise erreicht wird.

[Fridolin Walther]

Zitat:

Zitat von mkinzler

Zitat:

Erstell einfach mal eine neue MFC Applikation. Als Application Type gib am besten Dialog Based an, da der Designer für Dialog Based Applications am ehesten dem von Delphi bekannten Designer entspricht. Die anderen Einstellungen die abgefragt werden kannst Du beliebig setzen.

Wobei bei MFC der Komfort von Delphi in keinster Weise erreicht wird.

Keine Frage. Aber für einfach gestrickte Anwendungen reicht es allemal. Ich persönlich bevorzuge für GUIs ohnehin Delphi oder alterntiv C#. Ändert aber nichts an der Tatsache das ein visuelles Designen der GUI ebenfalls bei MFC möglich ist.

[F.W.]

Das sind ja eine ganze Menge von Antworten :-)

@Khabarakh: ok, dann ist das wohl eher nichts zum einfachen und schnellen Ein-/Umsteigen.

@Markus Kinzler: Ok, das werde ich mir nochmal anschauen (leider habe ich gerade keine Zeit). Diese How Do I Videos habe ich schonmal gesehen, d.h. ich habe mal reingeschaut. Aber meistens haben die nur das ohnehin ähnliche Arbeiten mit VS gezeigt, also Standard wie Projekt anlegen, kompilieren und debuggen. Ich bilde mir ein alles mit Windows Forms. Aber nachdem ich mir gerade deinen Link angesehen habe, scheinen das andere zu sein. Meine habe ich hier gefunden.

Zitat:

Zitat von 0xF30FC7

Zitat:

Zitat von mkinzler

Zitat:

Erstell einfach mal eine neue MFC Applikation. Als Application Type gib am besten Dialog Based an, da der Designer für Dialog Based Applications am ehesten dem von Delphi bekannten Designer entspricht. Die anderen Einstellungen die abgefragt werden kannst Du beliebig setzen.

Wobei bei MFC der Komfort von Delphi in keinster Weise erreicht wird.

Keine Frage. Aber für einfach gestrickte Anwendungen reicht es allemal. Ich persönlich bevorzuge für GUIs ohnehin Delphi oder alterntiv C#. Ändert aber nichts an der Tatsache das ein visuelles Designen der GUI ebenfalls bei MFC möglich ist.

Inwiefern wird der komfort von Delphi nicht erreicht? Kannst du Beispiele bringen und Gründe, warum gerade C# und nicht C++ oder VB (ok, VB scheint mir auf den ersten Blick evtl. ZU einfach gestrickt für einige Sachen und C++ wegen dem Umgang mit Speicher und strings zu kompliziert für schnelles und einfaches Entwickeln wie man es mit Delphi gewohnt ist?)


Ein Grund warum ich mich hauptsächlich auch für das VS interessiere ist, dass mir die Delphi IDE (ich benutze Turbo Delphi 2006 Explorer) nicht mehr den Komfort bietet, den ich gern hätte :-(
Ich bin großer Freund von PNGs und meiner Meinung nach sollte man heute auch einen gewissen Teil seiner Arbeit in eine ansprechende Oberfläche fließen lassen. Leider ist Delphi in dieser Version nur mit BMPs (auf BitBtns) kompatibel, was IMO nicht mehr ganz zeitgemäß ist. Ich bilde mir ein, gelesen zu haben, dass in D2009 das anders sein soll, aber ich kann für mein Delphi einfach kein Geld ausgeben, das erlaubt meine Geldbörse nicht so ganz. Und da es leider auch nicht möglich ist die Alpha Lite controls zu verwenden (zumindest nicht, wenn man sie mit Designer platzieren möchte), suche ich nach Möglichkeiten und Wege, trotzdem schöne Anwendungen erzeugen zu können.
(Das sind nur zwei Gründe) Obwohl ich es auch sehr bedauern würde, Delphi den Rücken zu kehren :-(

Wie sieht es eigentlich mit der Kompatibilität/Voraussetzungen der Techniken aus? Im heutigen Zeitalter ist das zwar vlt. nicht mehr ganz so schlimm, wenn das .NET Framework auf einem Computer noch nicht drauf ist, denn fast jeder hat ja heute Internet oder Zugang dazu, aber ich möchte trotzdem nicht, dass sich Freunde immer erst irgendwas extra runterladen müssen, für ein kleines Programm mit 3 Funktionen oder sowas.
Benötigt die MFC irgendwas, was auf Computern mit XP Service Pack 2 fehlen könnte?

[Phoenix]

Für ansprechende GUI's ist WPF eigentlich dann genau das richtige. Und ich würde das nicht am .NET Framework festmachen. Das ist so dermaßen Produktivitätssteigernd wenn man einmal die wichtigstens Teile kennengelernt hat, dass Du nicht mehr darauf verzichten möchtest wenn Du einmal Anwendungen damit geschrieben hast.

[jfheins]

Zitat:

Zitat von F.W.

Inwiefern wird der komfort von Delphi nicht erreicht? Kannst du Beispiele bringen und Gründe, warum gerade C# und nicht C++ oder VB

Najav - der Trend geht im Moment zu .net - Da c++.net eher ein Nischenprodukt ist, bleibt noch c# und vb.net. VB liebt man oder hasst man (eher letzteres) also bleibt noch c# ;)
C# ist im Grunde auch DIE .net Sprache - die meisten Beispiele wirst du hier finden. Im msdn gibt es meistens c#, c++.net, J# und vb.net

Zitat:

Wie sieht es eigentlich mit der Kompatibilität/Voraussetzungen der Techniken aus? Im heutigen Zeitalter ist das zwar vlt. nicht mehr ganz so schlimm, wenn das .NET Framework auf einem Computer noch nicht drauf ist, denn fast jeder hat ja heute Internet oder Zugang dazu, aber ich möchte trotzdem nicht, dass sich Freunde immer erst irgendwas extra runterladen müssen, für ein kleines Programm mit 3 Funktionen oder sowas.
Benötigt die MFC irgendwas, was auf Computern mit XP Service Pack 2 fehlen könnte?

Die c++ MFC ist bei jedem Windows dabei - auf einem nackten Windows XP ist jedoch iirc kein .net Framework vorhanden. Vista&Win7 haben zumindest das 2er Framework drauf.

[Khabarakh]

Zitat:

Zitat von F.W.

Ein Grund warum ich mich hauptsächlich auch für das VS interessiere ist, dass mir die Delphi IDE (ich benutze Turbo Delphi 2006 Explorer) nicht mehr den Komfort bietet, den ich gern hätte :-(

Dann ist WPF natürlich ein Traum. Ein TreeView mit CheckBoxen, eine mehrzeilige ListBox, ein Button auf einem Button :stupid: ? Kein Problem. Siehe auch http://www.delphipraxis.net/internal...=750321#750321

Zitat:

Wie sieht es eigentlich mit der Kompatibilität/Voraussetzungen der Techniken aus?

WPF: 3.0 (-> XP SP2), wobei mittlerweile jeder Computer mit 2.0 über Windows Update 3.5 SP1 bekommen haben sollte (oder läuft das noch)? Aber ich muss Phoenix zustimmen: einmal WPF, nie mehr Winforms ;) .

[F.W.]

Zitat:

Zitat von Phoenix

Für ansprechende GUI's ist WPF eigentlich dann genau das richtige. Und ich würde das nicht am .NET Framework festmachen. Das ist so dermaßen Produktivitätssteigernd wenn man einmal die wichtigstens Teile kennengelernt hat, dass Du nicht mehr darauf verzichten möchtest wenn Du einmal Anwendungen damit geschrieben hast.

Diese Ansicht finde ich sehr interessant. Ich habe ehrlich gesagt schon etwas Angst vor dem .NET Framework. Zum einen programmiere ich gern systemnah (da ich mir meistens Alltagsdinge erleichtern möchte) d.h. Handles von anderen Fenstern, Funktionen von Windows (wie Herunterfahren, Schlafen) und so Sachen und ich weiß nicht, ob das mit dem .NET Framework noch geht? Bzw. kann ich auf selbstgeschriebene Dlls aus einem .NET Framework zugreifen? (denn dann könnte ich solche Operationen nötigenfalls mit Delphi realisieren).

@jfheins: Danke für die Infos, also werde mir die MFC auch auf alle Fälle nochmal ansehen!

@Khabarakh: Ok, also meinst du für die Gründe, würde sich der Aufwand lohnen? Also werde ich mir auf lange Sicht auch die WPF ansehen.

Wie ich aus den Antworten so herauslese und auch aus dem Link im letzten Post scheint es doch mehr GUI Designer zu geben, als ich bisher im VS gefunden habe :-)


Noch eine Sache: Wie groß werden eigentlich die Exen von durchschnittlich großen und "leeren" Projekten? ("leer" --> also wie bei Delphis Startzustand - ein leeres Formular -> kompilieren)

Danke für eure Antworten! Das macht mir die Orientierung in VS und .NET-Sachen um Einiges leichter! :thumb:

[Phoenix]

Moment. Systemnah != Alltagsdinge vereinfachen. Das ist komplett gegensätzlich. Einfach ist es, wenn Du schon auf viel fertiges Zeug zurückgreifen kannst und es nicht komplett selber neu machen musst.

Und was Dll's angeht: Klar geht das. Nennt sich P/Invoke und ist ein Zweizeiler pro Funktion (eine gibt die DLL als Atribut an, die Andere ist die Signatur des Aufrufes).

Was Herunterfahren von Windows angeht:

Code:

using System;
using System.Runtime.InteropServices;

namespace ShutDown
{
  class XPShutDown
  {
    [DllImport("user32.dll", ExactSpelling=true, SetLastError=true)]
    internal static extern bool ExitWindowsEx(int flg, int rea);

    internal const int EWX_SHUTDOWN = 0x00000001;
    internal const int EWX_FORCE = 0x00000004;

    static void Main()
    {
      ExitWindowsEx(EWX_SHUTDOWN + EWX_FORCE, 0);
    }
  }
}

Das ist eine komplette Shutdown.exe in C#, inkl. DLL-Import.

[Indrizzi]

Mit Delphi Prism kann man ausserdem Projekte für Mono und Cocoa erstellen und sich dabei halbwegs im Delphi Sprachraum bewegen.

[F.W.]

Zitat:

Zitat von Phoenix

Systemnah != Alltagsdinge

Hey! Wir sind hier immernoch ein Delphi Forum ;-)

Ich habe in meinen "alltäglichen" Programmen nur oft auf Handles von anderen Fenstern zugegriffen. Auch wenn man das nicht in jedem Programm braucht, manchmal wars ganz nützlich und ich denke nicht, dass das ein plattformunabhängiges Framework unterstützt. Oder auch wieder über Dlls... Ok, also so schein ich ja erstmal keinen Schritt zurück zu machen mit dem .NET Framework

Danke für den Post. Das passt voll, weil ich nämlich gerade ein Programm zum Rechnerrunterfahren in Delphi überarbeite und mit der Funktoon gleich mal in VS umsetzen kann :-) Danke!!! :thumb:


@Indrizzi:
Ohne, dass ich jetzt google, was ist eigentlich dieses DelphiPrism?

[jfheins]

Delphi Prism ist eine .net Sprache in Pascal-Syntax ;)

Sprachen sind im .net Framework quasi beliebig austauschbar - du kannst eine Klasse in vb.net schreiben, sie in c# ableiten und diese dann in Prism verwenden ;)

[Jürgen Thomas]

Zitat:

Zitat von F.W.

Noch eine Sache: Wie groß werden eigentlich die Exen von durchschnittlich großen und "leeren" Projekten? ("leer" --> also wie bei Delphis Startzustand - ein leeres Formular -> kompilieren)

16 bis 32 kB sind gängige Größen. Der größte Teil der Funktionalität steckt in den Assemblies (DLLs) des NET Framework unter C:\Windows\Microsoft.NET\Framework\v3.5 oder so. Das entspricht etwa dem Konzept von Delphi mit separaten .bpl, aber wegen der MSIL viel konsequenter. Achtung: Das ist eine stark vereinfachte Erklärung, bitte keine Diskussion darüber.

Gruß Jürgen

[F.W.]

Zitat:

Zitat von jfheins

Delphi Prism ist eine .net Sprache in Pascal-Syntax ;)

Sprachen sind im .net Framework quasi beliebig austauschbar - du kannst eine Klasse in vb.net schreiben, sie in c# ableiten und diese dann in Prism verwenden ;)

Ach ja, ist schon irgendwie geil :-)

Aber das wirft jetzt noch eine andere Frage auf: Gibt es da jetzt zwischen den verschiedenen eingesetzten Sprachen noch Unterschiede, die dazu beitragen eine "für das Projekt geeignete" Programmiersprache zu wählen? (also ganz vorsichtig formuliert sowas wie: C++ ist schneller als Delphi)
Wobei mir natürlich klar ist, dass High-Performance-Anwendungen wie Spiele vlt nicht unbedingt in .NET geschrieben werden sollten, durch die VM. Aber gibt es zwischen den eingesetzten Sprachen z.B. Geschwindigkeitsvorteile oder andere Vorteile?

Zitat:

Zitat von Jürgen Thomas

16 bis 32 kB sind gängige Größen.

Ich war mir nicht ganz sicher, ob die 19 kb wirklich alles sind, als ich nach der EXE im Projektverzeichnis gesucht hatte. Aber dann ist ja gut :-)
Nur im Gegensatz

Zitat:

Zitat von Jürgen Thomas

Der größte Teil der Funktionalität steckt in den Assemblies (DLLs) des NET Framework unter C:\Windows\Microsoft.NET\Framework\v3.5 oder so. Das entspricht etwa dem Konzept von Delphi mit separaten .bpl, aber wegen der MSIL viel konsequenter.

Und wenn man eine Delphi-Exe mit Laufzeit Packages ausliefert, dann ist zwar die Exe klein, aber die Packages sind größer als das Bündel in einer Datei. Lohnt sich also nur bei umfangreicheren Programmen wie TuneUp, wo viele Exen ausgeliefert werden. Aber der gravierendste Unterschied ist wohl, dass das .NET Framework auf sehr viel mehr Computern drauf sein dürfte, als die Delphi Laufzeit Packages, weshalb die Dateien so klein werden.

Das ist ja mal n netter Vorteil. Auch wenn im Zeitalter von DSL vielleicht vernachlässigbar. Aber ich finds nicht schön, wenn meine Delphi DLL mit einem Formular knapp 600 kb groß ist ^^

[Phoenix]

Zitat:

Zitat von F.W.

Aber das wirft jetzt noch eine andere Frage auf: Gibt es da jetzt zwischen den verschiedenen eingesetzten Sprachen noch Unterschiede, die dazu beitragen eine "für das Projekt geeignete" Programmiersprache zu wählen? (also ganz vorsichtig formuliert sowas wie: C++ ist schneller als Delphi)
Wobei mir natürlich klar ist, dass High-Performance-Anwendungen wie Spiele vlt nicht unbedingt in .NET geschrieben werden sollten, durch die VM. Aber gibt es zwischen den eingesetzten Sprachen z.B. Geschwindigkeitsvorteile oder andere Vorteile?

Naja, eigentlich eignet sich .NET hervorragend, um Spiele zu schreiben. Schau Dir z.B. mal XNA an, womit man mit .NET Spiele für PC, die XBox 360 und den Zune schreiben kann. Da gibt es auch einige komplett fertige Spiele, anhand derer man sowas lernen kann.


Zu den .NET Programmiersprachen: Ja, es gibt Unterschiede. Sogar ganz gravierende. Das beruhigende 'Aber' ist allerdings: Diese Unterschiede machen sich nur in absoluten Grenzfällen bemerkbar.

Es gibt z.B. F#. Das ist eine Programmiersprache, die besonders für funktionale Entwicklung ausgelegt ist. Das geht zwar auch mit C#, ist dort aber relativ unangenehm zu schreiben.

Delphi Prism hat im Bereich Threading / Parallel Programming dank einiger Keywords gegenüber anderen Sprachen die Nase ganz weit vorne. Auch das kann man in anderen Sprachen von Hand machen - muss man aber nicht wenn man Prism nimmt.

Wer dynamische Sprachen benötigt greift zu IronPython, IronRuby oder Phalanger.

Nur sind funktionale Entwicklung, Aspektoriente Entwicklung, Dynamische Sprachen oder eben Parallel Programming doch eher 'Randgebiete' in der Entwicklung. Bei allem anderen, also die 08/15 OOP-Entwicklung, schenken sich die Sprachen gegenseitig eigentlich nichts. Da kommt es dann ganz auf die eigene Vorliebe (oder die vom Team) an, welche Sprache man da nimmt.

[F.W.]

Ok danke für die Infos :-)

[Meflin]

Zitat:

Zitat von Phoenix

Naja, eigentlich eignet sich .NET hervorragend, um Spiele zu schreiben.

Naja, jetzt lehnste aber weit aus dem Fenster :roll: Vieleicht sollte man das präzisieren zu "es geht" - "herrvorragend geeignet" ist mit Sicherheit übertrieben. Man denke sich mal so etwas wie GTA etc ohne Assembler-Optimierungen, da kann man sich gleich noch ne zusätzliche CPU in den PC denken...

Und derartiges ist mit dem .Net-Framework einfach ein Ding der Unmöglichkeit.

[Elvis]

Zitat:

Zitat von Meflin

Zitat:

Zitat von Phoenix

Naja, eigentlich eignet sich .NET hervorragend, um Spiele zu schreiben.

Naja, jetzt lehnste aber weit aus dem Fenster :roll: Vieleicht sollte man das präzisieren zu "es geht" - "herrvorragend geeignet" ist mit Sicherheit übertrieben. Man denke sich mal so etwas wie GTA etc ohne Assembler-Optimierungen, da kann man sich gleich noch ne zusätzliche CPU in den PC denken...
Und derartiges ist mit dem .Net-Framework einfach ein Ding der Unmöglichkeit.

Ein Großteil der kommerziellen Spiele ist eine wilde Mischung unterschieldicher Sprachen und Runtimes.
Oft gibt es eine (zugekaufte) Grafik/Physik-Engine, die so effizient geschireben ist, wie es möglich war.
Aber das Spiels selbst ist oft alles andere als hoch effizient geschrieben. Viele Spiele nutzen Skriptsprachen für NPCs, oder dynamische Levels, ...
Einige Spiele Vendor steigen auf Mono um, da es genauso flexibel und einfach zu programmieren ist, aber schneller als Scripting Srachen.

Wenn du auf eine Enige setzt, die Physik und Grafik mitbringt, kannst du sehr wohl in .Net/Mono games schreiben.
Der Performance untershied von dem, was du selbst schreiben würdest, wird sich kaum/gar nicht auswirken.
Verglichen mit nativen Sprachen kannst du aber in krüzerer Zeit, mitweniger Aufwand mehr stabileren Code schreiben.