C#-Programm ohne installiertes .NET ausführen
-
Hey Leute,
kurze, brachiale Frage, und so mancher mag bei dem Titel schon 'nen Schreikrampf bekommen^^
Ich weiß, dass es möglich ist das Mono-Projekt, bzw den JIT compiler, in ein C-Programm zu packen und durch Bereitstellung der Mono-Runtime ein C# Programm auf einem System auszuführen, das keine feste .NET/Mono Installation hat. Das habe ich probiert, läuft auch 1A (mein Programm wächst dadurch von einigen Kilobyte auf stolze 170 Megabyte
).
Leider hinkt Mono in Sachen Implementierung meines Wissens etwas dem aktuellen Stand von .NET nach, und ich weiß nicht, ob es für all meine Zwecke ausreichen wird
Weiß deshalb jemand von Euch, ob es für den MS C# Compiler einen ähnlichen Mechanismus gibt, die Runtime zur Laufzeit zu ermitteln ohne sie wirklich zu installieren (mir ist dabei egal, ob das Bundle am Ende riesig wird)? Ich habe ein kommerzielles Tool gefunden, dass angeblich alle benötigten .NET-Assemblies zusammenlinkt und eine Art "portable .NET-Framework" erzeugt, aber es ist eben arschteuer und ich weiß auch nicht, ob das am Ende auch wirklich reibungslos funktioniert...
Oder besser: Kennt jemand eine Möglichkeit, den CIL code auf nativen x86 Code (Windows) fertig zu compilen, Stichwort "Full Ahead-Of-Time" Compilation? Mit dem Native Image Generator (NGen.exe) ist man ja immernoch an das feste Framework gebunden...
Für jede Hilfe bin ich natürlich dankbar! Falls etwas unverständlich geschrieben ist, entschuldige ich mich auch gleich -- ich erkläre es gerne genauer
Gruß
PuerNoctisP.S.: Bevor mich einige Brandmarken, warum ich nicht einfach das .NET-Framework auf dem Zielsystem installiere: Ich würde es ja gerne tun, aber aus diversen Gründen sollte das nach Auftraggeber möglichst vermieden werden...
EDIT: Kleine Ausbesserung
-
Wenn du das brauchst, dann bist du mit C# relativ schlecht bedient und solltest auf natives C++ mit irgendwelchen Libraries setzen. Desweiteren ist .NET inzwischen de Facto ein Bestandteil von Windows, also musst du dir, solange du nur auf neuen Systemen (Windows Vista und aufwärts) deployst, keine grossen Gedanken machen.
MfG
-
Danke für die Antwort rant
Hab' mir schon fast sowas gedacht. Bin ehrlich gesagt in C++ auch versierter als in C#, und da das Programm mit einem kommerziellen Produkt vertrieben wird, kann es gut passieren, dass sich einige lukrative GPL-lizensierte Libraries damit beißenC# fände ich zudem für GUI Entwicklungen weitaus schöner als GTK+, wxWidgets oder gar MFC
Die Lage ist etwas schwer zu erklären, aber ich werde einfach versuchen meinen Teamleiter von einem installiertem .NET als Voraussetzung zu überzeugen (die Systeme sind leider nicht immer aktuell, daher kann ich nicht standardmäßig von .NET ausgehen) -- oder ich greife einfach auf die C WinApi zurück. Hätte mir halt gefallen
Aber falls jemand doch noch was kennt: Ist immer nice-to-know
Gruß
PuerNoctis
-
Ich kenne keine praktikable Möglichkeit.
-
PuerNoctis schrieb:
Die Lage ist etwas schwer zu erklären, aber ich werde einfach versuchen meinen Teamleiter von einem installiertem .NET als Voraussetzung zu überzeugen
wenn Du ein anderes Framework verwendest musst Du meistens auch diese DLLs installieren ... ist also egal
-
Kann man das Redist-Setup des Frameworks nicht einfach vor das eigene Installationsprogramm packen, oder stellt Mickeysoft sich da an?
-
Cpp_Junky schrieb:
Kann man das Redist-Setup des Frameworks nicht einfach vor das eigene Installationsprogramm packen, oder stellt Mickeysoft sich da an?
Wenn Du in Visual Studio ein Setupprojekt erstellst, macht er das sogar von selbst.
-
@Cpp_Junky:
Geht sicherlich, nur darf das Framework bei uns nicht installiert werden. Um die Katze mal aus dem Sack zu lassen: Unser Haufen hier wirft mit verschiedenen .NET-Programmen die alle unterschiedliche Versionen von 1.0 - 3.5 benötigen durch die Gegend. Demnach haben wir ständig Probleme, dass die eine Software von uns inkompatibel mit der nächsten ist. Ich fluch da schon seit Ewigkeiten rum, aber das will ja niemand hören...Jetzt haben die selbst die Schnauze voll und das Management hat, aufgrund mangelndem Sachverständnis, nur negative Erfahrung mit .NET und will das daher in Zukunft vermeiden -.- Is'n Großkonzern, wo die Manager nur nen betriebswirtschaftlichen Kurzblick haben, da haben die oberen Schichten kein Ohr für die kleinen Leute unten.
Allgemein haben die deshalb 'ne gewisse Paranoia entwickelt wenn es darum geht, irgendein Framework zu installieren. Ja sogar mit Java haben die ihre Probleme... ein Armutszeugnis.
Daher rührt die ganze Geschichte, das .NET-Framework nicht installieren zu wollen (oder irgendein anderes), sondern einfach die Runtime explizit für ein spezielles Programm alleine bereitzustellen.
Gruß
PuerNoctis
-
PuerNoctis@Offline schrieb:
Unser Haufen hier wirft mit verschiedenen .NET-Programmen die alle unterschiedliche Versionen von 1.0 - 3.5 benötigen durch die Gegend. Demnach haben wir ständig Probleme, ...
was zur Hölle macht ihr?! ... ich habe hier 1.1 und 3.5 parallel am laufen ... 2.0 & 3.0 werden mit 3.5 abgedeckt? ... ich würde eher behaupten das Ihr mit dem Framework nicht umgehen könnt ... den ganzen Quatsch mit den Problemen soll es (lt. MS) nicht mehr geben -> DLL-Hell
Is'n Großkonzern, wo die Manager nur nen betriebswirtschaftlichen Kurzblick haben, da haben die oberen Schichten kein Ohr für die kleinen Leute unten.
ich weis schon wieso ich nie wieder für einen Konzern arbeiten möchte ...
Daher rührt die ganze Geschichte, das .NET-Framework nicht installieren zu wollen (oder irgendein anderes), sondern einfach die Runtime explizit für ein spezielles Programm alleine bereitzustellen.
VMWare oder Chroot ... beides keine sinnvollen Optionen
hand, mogel
-
müsst ihr halt alles in python oder so nem dreck programmieren.
python kann man hosten, d.h. da muss nix installiert werden.auch is dann alles schön langsam. und da langsam viel mehr "enterprise" ist als nicht langsam, ist das ja auch gut so, nen.
-
mogel schrieb:
Unser Haufen hier wirft mit verschiedenen .NET-Programmen die alle unterschiedliche Versionen von 1.0 - 3.5 benötigen durch die Gegend. Demnach haben wir ständig Probleme, ...
was zur Hölle macht ihr?! ... ich habe hier 1.1 und 3.5 parallel am laufen ... 2.0 & 3.0 werden mit 3.5 abgedeckt? ... ich würde eher behaupten das Ihr mit dem Framework nicht umgehen könnt ... den ganzen Quatsch mit den Problemen soll es (lt. MS) nicht mehr geben -> DLL-HellGebe ich dir teilweise sogar recht
Ich habe mich die letzten Jahre mit dem Framework beschäftigt, sag' jetzt aber nicht, dass ich auf dem Gebiet ein Profi bin, aber ich verstehe das System, kann damit arbeiten und weiß was ich mach. Jedoch kommen viele meiner (oft im Ausland arbeitenden Kollegen [Outsourcing]) entweder aus der Hardcore C Welt und haben da nicht so ein tolles Verständnis, oder um mal wieder auf dem Management rumzuhacken, wird zu kurz geplant und alles entsteht unter enormen Druck. Ich sehe diese beiden Punkte als Hauptursache bei dem Problem. Mangelndes Fachverständnis ist definitiv präsent!@mogel:
Ich werde jetzt einfach mit der WinApi herangehen. Werden jetzt zwar viele LOC, aber da bin ich dann Selbstsicher genug, dass ich sagen kann, dass ich das Ding am Ende ohne Problem auf einem Win2k bis zu einem Win7 zum Laufen bekommeGruß
PuerNoctis
-
PuerNoctis schrieb:
oft im Ausland arbeitenden Kollegen [Outsourcing]
hehe ... dazu war vor kurzen was im Java-Forum.org ... das Ergebniss - Outsourcing ist Mist und nur vom Management verzapft (das ging teilweise bis zu Firmenpleiten)
btw ... wenn die Outgesourcten nur mit C wollen, dann könnten die einfach kein OOP ... die Outgesourcten sollten dringenst gewechselt werden (Managment gleich mit :p )
hand, mogel