Geht auch super via Delegate.BeginInvoke. Einfach ein passendes Delegate erstellen, bzw. Action<> oder Func<> verwenden. Damit musst du nicht auf Typsicherheit verzichten und kannst auch wenn du brauchst einen Rückgabewert verwenden.
Schau dir bitte auch den Rückgabewert von BeginInvoke. Mit dem Waithandle hast du automatisch eine Thread.Join-Funktion.
Nachteil des ganzen, beim Aufruf von BeginInvoke solltest du später EndInvoke aufrufen. Besonders bei den MS Implementationen könnten sonst Speicherlecks entstehen.
Selber Threads zu erstellen, ist meist nur sinnvoll, wenn du die volle Kontrolle(Überwachung) über den Thread brauchst oder es sich um eine "lange" Aufgabe handelt. Wenn du nur etwas parallelisieren möchtest, ist die direkte Verwendung von Thread verkehrt, da allein das Erstellen des eines neuen Threads Ressourcen und Zeit verbraucht. Threadpool (BeginInvoke zählt auch dazu) verwenden existierende Threads, die nur drauf warten endlich mal was zu tun zu bekommen.
Soweit mir bekannt, ist es nicht möglich aus einem Setup heraus ein weiteres Setup zu startet.
Doch das geht. Das Ganze nennt sich Chainer. Bestes Beispiel ist die Installation des SQL Servers, die aus vielen kleinen einzel MSIs besteht. Problem ist nur, die MSI Pakete müssen den Vorgang unterstützen.
Hallo TinaQ,
eine gute Alternative wäre, du schreibst dir ein eigenes Bootstrapper-Package. Siehe dazu Authoring a Custom Bootstrapper Package. Mit entsprechenden InstallConditions kannst du den Bootstrapper entsprechend Steuern.
Die Methode integriert sich in ein Framework welches die Methode auch synchron aufruft, daher erwartest es auch das Ergebnis synchron. Dem entsprechend kann ich dort den Aufruf leider nicht beeinflussen.
Aber du kannst die Gui logisch von deinem Framework/BusinessClass trennen - Ist kein muss, nur sind die Anwender von heute sehr verwöhnt.
Wenn das ganze später eventuell mal erweitert werden soll, könnte es Sinn machen, statt Xml direkt eine Scriptsprache (wie Lua, oder C# selbst) zur Steuerung zu verwenden.
Hallo Marsstein,
doch ich glaube schon. Das liegt vor allem an unseren (teils sehr) beschränkten Politikern, die nur über unwichtige Themen wie GSV debattieren bzw. sich öffentlich dazu äußern.
Die wirklich wichtigen Themen wie SWIFT oder die Weitergabe persönlicher Daten bei EC-Bezahlung wie bei REWE spricht keiner an bzw. geht bei den unwichtigen Gewusel direkt unter.
Genauso das Thema "Schützt eure Kinder". Die Politiker nutzen die Ängste der Bevölkerung um irgendwelche sinnlosen Gesetzesänderungen durch zu boxen, teilweise mit schwerwiegenden Konsequenzen.
solltest auch darauf achten, dass du dir immer die Timer-Instanz merkst. Tust du das nicht, räumt der GC dir den Timer weg und das Ticken hört dann auf.
Lass die Zeilenumbrüche so wie sie sind und geb deinen Text einfach in einem <pre>...</pre>-Tag aus. Vorteil, es werden auch fürs web "überflüssige" Leerzeichen beibehalten.
Spätestens seit der letzten großen Koalition hat D. auch keine Demokratie mehr sondern nur eine Lobbykratie. Fasst alles was dort beschlossen wurde, hatte mit Volksnähe wenig am Hut.
Ein COM-lässt sich nicht speichern und beispielsweise nach einem Neustart direkt wiederverwenden. Problem ist das intern diverse Handles/Ressourcen benutzt werden, die zu einem späteren Zeitpunkt wahrscheinlich nicht mehr existieren.
Deshalb speichere nur den Zustand des Objektes (get, set Properties).
Wird eine Exportdatei eines Fremdsystems dort abgelegt, reicht der Watcher den Dateipfad an die API-Importroutine des empfangenden Systemes weiter
Warum nicht einfach einen Timer (System.Threading.Timer) verwenden, der jede Sekunde entsprechende Verzeichnisse nach neuen Dateien durchsucht und anschließend deine API aufruft? So eine Klasse wäre schnell geschrieben und zu dem ressourcenschonender und skalierbarer als mehrere FileSystemWatcher.
Hallo DeViL666.on,
bitte befass dich erstmal mit den Möglichkeiten und Einschränkungen des .NET Frameworks sowie des Threadings unter Windows und .NET.
Du brauchst nämlich in diesem Beispiel keinen Thread und keinen Threadpool. Das gibts bereits nahezu alles fasst fertig. Schau dir bitte folgende Links an:
Hallo olimlad,
du kannst das IAsyncResult für einen Timeout verwenden.
IAsyncResult result = Dns.BeginGetHostAddresses(..., callbackFunc);
WaitHandle.AsyncWaitHandle.WaitOne(5000);
...
private void callbackFunction(IAsyncResult result ) {
Dns.EndGetHostAddresses(result);
}
Hinweis, ohne Aufruf von EndXY bei MS Implementierungen hat deine Anwendung ein Speicherleck, daher bitte immer bei BeginXY die passende EndXY-Methode aufrufen.
In .NET gibts dafür Probing. Such einmal nach app.config probing.
Der Dateiname ist absolut egal. Verweise werden anhand des Assemblynamens (Name der Assembly, Version, Kultur, public Token) geladen.
Als Install-Framework kann ich dir Windows Installer XML (WiX) toolset empfehlen. Solltest dich aber unbedingt vorher mit dem Aufbau und der Funktionsweise von MSI-Paketen auseinander setzen
Es ist ein allgemeiner Irrglaube das Javascript irgendwelchen Schutz mitsichbringt. Im Gegenteil JavaScript läuft im Browser. Jeder kann so den Quelltext einsehen, beliebig modifizieren (beispiel GreaseMonkey) und entsprechend Requests faken.
Außerdem kann man bereits als C#-Anfänger leicht eine Webseite mit einem Browser-Control fernsteuern - egal ob mit oder ohne JS.
Nur verschiedene Benutzereingabe bieten einen halbwegs akzeptablen Schutz vor einer Fernsteuerung.
Für mich gehört da ein Captcha hin, um wirklich genau feststellen zu können, ob das wirklich eine Usereingabe ist. Viele mögen zwar Captchas als lästig empfinden, allerdings sind diese wirklich wichtig, um eine programmgesteuerten und Usereingabe zu unterscheiden.
Meiner Meinung nach sollte auch jedes Bestellformular ein Captcha enthalten.
Zitat
Gleichzeitig auch mit dem DateTime aus der Session prüfen, ob da eine mindestspanne dazwischen liegt.
Pro Client können auch mehrere Sessions existieren. Zum Beispiel bei verschiedenen Browsern.
class Foo {
private static int s_Count;
public static int Instances { get { return s_Count } }
public Foo() {
Interlocked.Increment(s_Count);
}
~Foo() {
Interlocked.Decrement(s_Count);
}
}
Zusätzlich Dispose zu implementieren wäre auch nicht schlecht.