Anwendung ohne Oberfläche

  • VB.NET

Es gibt 29 Antworten in diesem Thema. Der letzte Beitrag () ist von AliveDevil.

    Anwendung ohne Oberfläche

    Hallo,

    ich hätte da mal eine Frage... Ich muss dazu sagen, dass ich mich mit Konsolenanwendungen bisher garnicht beschäftigt habe.

    Zuallererst, ich möchte folgendes: Ein Programm ohne Oberfläche. Nicht nur ohne GUI, sondern gänzlich ohne Oberfläche, auch kein Konsolenfenster. Sprich, der Benutzer sieht es garnicht. Und nein, extra mit Diensten herumhantieren (was glaube ich in diesem Fall naheliegend wäre, oder?) möchte ich erstmal nicht. Dieses Programm soll eine Zeit lang untätig herumsitzen, bis ich ihm was zu tun gebe.

    Ich habe dazu mal Google bemüht, und ich habe gelesen, man solle doch einfach eine Konsolenanwendung erstellen und den Anwendungstyp auf "Windows Forms-Anwendung" stellen. Das habe ich getan und es klappt auch - keine Oberfläche, nichts sichtbar vom Programm.
    So weit, so gut.

    Nun will ich diese Konsolenanwendung aus einem anderen Programm starten und erstmal vor sich hin idlen lassen, bis ich dem Programm mittels StandardInput was "zu fressen" gebe.

    Mein Problem ist nun, dass sich die Konsolenanwendung selber schließt (was, wie ich inzwischen auch weiß, offenbar der normale Ablauf einer Konsolenanwendung ist).
    Wie bekomme ich es nun hin, mein Wunschszenario zu realisieren? Das heißt: Wie halte ich eine Konsolenanwendung geöffnet (eine sinnlose Schleife, die mir meine halbe Prozessorleistung wegnimmt, will ich natürlich nicht)? ODER: Gibt es andere Wege als eine Konsolenanwendung, um das zu erreichen, was ich haben möchte?
    oder per Konsolenanwendung mit

    Console.Readline einbauen.

    Hier Link: msdn.microsoft.com/de-de/library/system.console.readline.aspx#Y0

    (sry Handy online)

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „Gelöschter Benutzer“ ()

    AliveDevil schrieb:

    Anwendungsframework deaktivieren und die Form entfernen.
    Shutdown Mode auf "Explicit" oder so einstellen.

    Das Framework habe ich deaktiviert, die Form gelöscht und ein Modul hinzugefügt, damit das Programm was zum starten hat (oder geht das auch anders?). Unter Shutdown Mode verstehe ich jetzt mal den "Modus für das herunterfahren", den man auf "Startformular" und "letztes Formular" festlegen kann, was in diesem Fall aber garnicht änderbar ist, da das Anwendungsframework ja deaktiviert wurde. Was meintest du mit Shutdown Mode?

    Gelöschter Benutzer schrieb:

    Console.Readline einbauen.

    Wenn ich eine Konsolenanwendung normal verwende, und Console.ReadLine() verwende bleibt das Programm zwar geöffnet, aber die Konsole eben auch. Und die Konsole will ich ja garnicht sehen, deswegen habe ich den Anwendungstyp bei der Konsolenanwendung auch auf "Windows Forms-Anwendung". Ein Console.ReadLine() hat dann keinen Effekt.
    Damit eine Anwendung komplett ohne Fenster und Konsole startet, musst du bei den Projekteinstellungen im Tab Anwendung folgende Einstellungen setzen:

    Anwendungstyp: Windows Forms-Anwendung
    Startobjekt: Sub Main (statt einer Form)
    Anwendungsframework aktivieren: deaktiviert

    Ein Modul brauchst (und solltest) du nicht verwenden. Du benötigst nur eine Klasse, die eine öffentliche und statische Methode mit dem Namen Main hat. Die wird dann beim Programmstart aufgerufen.

    Und wie du ja schon eigentlich schreibst, den Modus für das Herunterfahren brauchst bzw. kannst du garnicht setzten, da das Anwendungsframework ja deaktivert ist.
    In Ordnung, das habe ich so.

    Aber mein Programm beendet sich dennoch, sobald es nichts mehr zu tun hat. Wie kann ich das Programm weiter geöffnet halten, so dass es auf Eingaben von außen reagieren kann?


    Danke übrigens, dass du selbst nachts um halb Eins noch antwortest ;)
    @~blaze~: Genau.
    @DeltaForce: Musst Du mit dem Programm kommunizieren? Offensichtlich ja.
    Wenn ja: Wie willst Du mit dem Programm kommunizieren?
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!
    @ErfinderDesRades: Hast Du Deine Brille vergessen :?:

    DeltaForce schrieb:

    Und nein, extra mit Diensten herumhantieren (was glaube ich in diesem Fall naheliegend wäre, oder?) möchte ich erstmal nicht.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!
    Wie ich mit dem Programm ommunizieren will, weiß ich selber ehrlich gesagt noch nicht genau. Bevor jetzt eine kollektive *facepalm*-Welle durch den Thread rauscht: Ich starte das Programm von einer anderen Anwendung aus, von welcher auch die Kommunikatione rfolgen soll. Ich hatte was von diesen StandardInput-Streams gelesen, und dachte, dass man über diesen Stream dem Programm Daten übergeben kann; auch wenn ich, zugegeben, mir dazu nur mal nen MSDN-Artikel überflogen hab.

    Memo schrieb:

    Oder ein Keylogger oder so :whistling:

    Das trifft es ziemlich genau nicht ganz (es soll nicht alle Anschläge logen, sondern nur einen ebstimmten verschlucken). Das Programm soll zwei Dinge tun, zum einen Mal auf die Beendigung eines anderen Prozesses warten und dann ein paar Dateioperationen ausführen und zweitens einen Keyhook aktivieren, der einen bestimmten Tastenanschlag schluckt.* Beides müsste so eigentlich funktionieren, mir geht es nun vor allem darum, das Programm geöffnet zu halten, bis ich mit ihm kommuniziere und ihm sage, was es tun soll - was eben, wie ich mir dachte, über diesen StandardInput-Stream geschehen soll. Ich lasse mich aber gerne auch anderer Alternativen belehren.


    * Bevor angefangen wird, über meine Absichten zu munkeln: Ich bin kein kleines Kiddi, das denkt, es könne einen Virus oder sowas programmieren, das es seinen Freunden auf den Rechner zaubern kann. Sinn und Zweck ist es, in einem Computerspiel die Cheatkonsole zu deaktivieren - dazu wird der Tastendruck der ^-Taste geschluckt. Und die Dateioperationen nach Beendigung des Prozesses des Spiels, sollen ein (zuvor) eingefügtes HotSeat-Skript (nachträglich hinzugefügter Multiplayer-Modus für rundenbasierte Spiele) wieder entfernen.
    Ich hege keinerlei böse Absichten...
    Und da es ja gerade explizit zur Sprache gebracht wurde: Ich programmiere ein Programm, welches den Internet-HotSeat-Modus für das rundenbasierte Echtzeitstrategiespiel Rome: TotalWar komfortabler gestaltet. Es lädt das gespeicherte Spiel des vorhergehenden Spielers von einem Server, fügt es automatisch ins Spiel ein und startet das Spiel. Nebenbei soll, weil das eine lästige Plage in Internet-HotSeat-Runden geworden ist, mit einem Keyhook das Öffnen der Cheat-Konsole im Spiel verhindert werden. Ich sehe das keineswegs als verwerflich an, Cheaten zu verhindern. Und mal ehrlich: Welches Programm auf dem Rechner arbeitet nicht in einem bestimmten Maße "gegen" den Anwender?
    Ich frage ja garnicht danach, wie ich einen Keylogger oder Keyhook hinbekomme - das habe ich schon. Eine Anwendung ohne Oberfläche, die auf Input von außen wartet und dann was tut - das ist doch nicht sofort kriminell, oder?
    Falls es so sein sollte, dass es sich dabei um "gefährliches" Wissen handelt: Wer mir helfen möchte und eine Idee hat, kann mir das ja vielleicht per PN schreiben, wenn er möchte. :) Und wer mir böse Absichten unterstellt, der tut das eben nicht.

    DeltaForce schrieb:

    Ich starte das Programm von einer anderen Anwendung aus, von welcher auch die Kommunikatione rfolgen soll. Ich hatte was von diesen StandardInput-Streams gelesen, und dachte, dass man über diesen Stream dem Programm Daten übergeben kann; auch wenn ich, zugegeben, mir dazu nur mal nen MSDN-Artikel überflogen hab.

    ich verstehe nicht, warum du ein zusätzliches Proggi verwenden willst.
    Statt ein anneres Progg aufzurufen und herumzukommandieren könnte deine Anwendung doch selbst erledigen, was zu tun ist - oder?
    Der Hauptsinn dahinter, dass ich ein zweites Programm habe, ist der: Falls das Hauptprogramm gekillt wird, hat es keine Zeit mehr, das eingefügt HotSeat-Skript wieder zu entfernen. Im Endeffekt ist das nur ein simples Dateiumbennen. Aber wenn das Hauptprogramm gekillt wird, kann es das nicht mehr tun. Deswegen hatte ich die Idee, ein Hintergrundprogramm laufen zu lassen, dass alle paar Sekunden überprüft, ob das Spiel noch läuft, und wenn dem nicht mehr so ist, besagte abschließende Dateioperationen ausführt und sich dann beendet. Falls also das Hauptprogramm geschlossen wird, können die Änderungen so rückgängig gemacht werden.