Hallo,
in dem Fall werden aber bei jeder falschanfrage alle gültigen keys über's Netz geschickt... Das gilt es auf jedemn Fall zu vermeiden. wenn da jemand seinen HTTP-Port abhört, bekommt er alle keys!
Sowas macht man auf jeden Fall serverseitig.
Hallo,
Du musst in Deinem Projekt eine Installer-Klasse anlegen und die Assembly dann unter "Benutzerdefinierte Aktionen" im Setup-Projekt eintragen.
In der Installer-Klasse kannst Du dann die Ereinisse Install, Commit, Rollback und Uninstall überschreiben.
Hallo,
in dem Fall würde ich versuchen, den Key auf dem Server auszuwerten, und nur noch das Ergebnis der Abfrage zurückschicken. Dafür eignet sich hervorragend ein Webservice über eine .asmx Datei.
Da kannst Du eine Methode einfach mittels Attribut im Netz verfügbar machen.
[WebMethod]
bool CheckKey(String key){}
Auf der Clientseite fügst Du dann einfach deinem Projekt einen Webverweis hinzu, gibst die URL an und den Rest macht VisualStudio. Dann kannst Du die Methode vom Client her einfach aufrufen. Der interne Datenverkehr läuft dann über XML/SOAP.
Hallo,
wenn ich das richig sehe, machst Du den port zwar auf, liest aber keine Daten.
Iregndwo müsste noch ein port.Read() oder port.ReadExisting() gerufen werden.
EDIT:
Vergiss es, ich sollte meine Augen aufmachen.
Control.Invoke-Methode
Führt einen Delegaten in dem Thread aus, der das dem Steuerelement zugrunde liegende Fensterhandle besitzt.
Zitat
Control.BeginInvoke-Methode
Führt einen Delegaten asynchron für den Thread aus, in dem das dem Steuerelement zugrunde liegende Handle erstellt wurde.
Das heißt, auch mit Invoke() wird in Deinem Beispielcode immer der GUI-Thread arbeiten, nur eben dann synchron. Ich weiß jetzt auch wirklich gar nicht, was für Dich an der Geschichte eigentlich problematisch ist, sry
@Löwenherz
Wenn Du denvon Dir geposteten Artikel bei codeproject richtig gelesen hast, müsste Dein Problemeigentlich klar geworden sein. Ich halte den Artikel auch für sehr gut. Du scheinst an dieser Stelle noch ein grundsätzliches Verständnisproblem zu haben, lies den Artikel nochmal genau durch. Dann siehst Du, daß Du in DeinemFall entweder mit Invoke() arbeitenen solltest, oder Deine Threads eben manuell synchronisieren musst.
Original von Waschbecken
Das Verwenden der bestehenden Datenbankklassen ist eine Frage des Designs, kein Vorteil beim Versand über ASP.NET. Wenn man seine Logik vernünftig trennt, kann man auch aus anderen Anwendungen heraus den Datenlayer der Webanwendung benutzen.
Das ist zwiefellos richtig. aber wenn asp.net sowieso am laufen ist, weil meine Anwendung schon in asp.net läuft, braucht man dem Kunden ja nicht noch unbedingt nen zusätzlichen Dienst aufs Auge zu drücken
Ein mögliches Problem mit lock(this) ist z.B. folgendes:
class MyClass
{
public void MyMethod()
{
lock(this)
{
//Arbeit machen
}
}
}
// dann in einer anderen Methode z.B.:
MyClass myclass = new MyClass();
lock(myClass)
{
myClass.MyMethod();
}
Deadlock, isn't it ??
Ist also ziemlich gefährlich...
Hallo,
ich finde das hängt auch ganz davon ab was man vorhat. Wenn man eine webbasierte Anwendung schreibt, die unter anderem ein Newsletter-Feature anbieten soll, kann man es imho schon verantworten, das den asp-dienst übernehmen zu lassen. Man kann dann z.B. direkt auf die Datenbankklassen der Webanwendung zugreifen, und das ist für den Endbenutzer dann auf jeden Fall auch leichter zu handhaben.
Wenn es nur darum geht, den Newsletter zu versenden, habt Ihr natürlich recht.
Hallo,
Du kannst hierfür die Handler der global.asax benutzen, z.B. im Application_Start 'nen Timer starten. Der Thread für den Timer läuft dann im asp.net-workerprozess, und der wird nicht beendet bis der Webserver beendet wird.
Dann ist es aber wichtig, daß mindestens ein Aufruf an die Website erfolgt, nachdem der Webserver neu startet, damit der Handler auch ausgeführt wird.
Hallo,
sorry Du hast natürlich recht ich würde normalerweise auch jemand anderen als ausgerechnet this locken war nur als Beispiel gedacht...
Aber ich würde bei diesem Problem hier eher schauen ob ich nicht was am Aufbau ändern kann, damit nicht unbedingt alles asynchron läuft, dann kommts möglicherweise nicht so weit daß man hier überhaupt ein lock braucht.
nur leider war die ganze Geschichte dann nicht mehr synchron
wie denn auch? Du hast es ja explizit asynchron aufgerufen!! Wenn Du das wieder synchron habe willst, verweise ich nochmal auf die Verwendung von lock (siehe mein letzter Post).
Zitat
und ich weiß leider nicht, wie ich die Thread-ID rausbekomme
mit Thread.CurrentThread kommst Du immer an den gerade laufenden Thread.
Hallo,
um aml zwei Editoren zu nennen, die mir beide gut gefallen haben, und alles mögliche an Syntax-Highlighting unterstützen (SourceEdit ist auch selbst erweiterbar mit eigenen Sprachmodulen, viele Sprachmodule im Netz)
Die können allerdings beide nicht Projekte kompilieren, und können keine Auto-Completion.
EDIT:
In der Richtung was Du suchst ist #develop aber schon das beste was ich kenne. Ich wüßte auch nicht daß da sonst noch was wäre, würde mich aber ebenfalls interessieren.
du musst wenn Du nur Commit() nutzen willst die .dll trotzdem im Setup auch für die Install-Aktion eintragen. Sonst wird die Install()-Methode der Installer-Klasse nicht ausgeführt, und die genannte Datei, die das Commit benötigt, wird nicht angelegt.
Hallo,
ich denke Du liegst immer noch verkehrt... Wenn Du Methoden asynchron aufrufst, z.B. durch BeginInvoke(), dann werden die nicht von einem anderen Thread irgendwann abgearbeitet, sondern die Abarbeitung wird sozusagen nur angestossen und läuft parallel zum anstossenden Thread ab. das heißt du kehrst mit BeginInvoke() direkt zurück in den aufrufenden Thread.
Um sicherzustellen daß Deine Funktion dann "an einemStück" abgearbeitet wird musst du die asynchronen Aufrufe synchronisieren, das kannst Du zum Beispielmachen indem Du Deinen ganzen Funktionsrumpf in ein lock(this){}-Block packst. Dann machst Du aber asynchrone Aufrufe die Du von Hand wieder "zurücksynchronisierst" sozusagen. Wenn Du haben willst, daß die Funktion im GUI-Thread abgearbeitet wird, ist eher Invoke() DeinKandidat, und nicht BeginInvoke.
Noch einmal die Frage: Wenn die Funktion vom GUI-Zhread abgearbeitet werden soll, und erst danach der nächste Aufruf, wozu dann die asynchronen Aufrufe?
Aber wie svenson auch geschrieben hat, wird die Ausführung dieser beiden aufgerufenen Delegaten im GUI Thread nacheinander ausgeführt. Daher müsste meines Erachtens nach doch zuerst der erste Aufruf im GUI-Thread komplett durchlaufen, bevor der zweite Aufruf abgearbeitet werden kann.
das hat svenson so aber nicht geschrieben, und das ist eben genau der Unterschied zwischen BeginInvoke()und Invoke(). die Invoke()-Methode läuft synchron im GUI-Thread und blockiert diesen bis Ende seiner Ausführung. Die BeginInvoke()-Methode läuft aber asynchron und ist nicht an den GUI-Thread gebunden und hält diesen auch nicht auf.
EDIT:
Durch die ganzen asynchronen Aufrufe läuft bei Dir so ziemlich alles nebeneinander her ab. Das macht die Geschichte relativ unübersichtlich undschwierig in der Handhabe. Vielleicht solltest Du Dir mal überlegen, ob das in Deinem Programm wirklich in der Art nötig ist.
Hallo,
du kannst ein "geerbtes Benutzersteuerelement" erstellen, das von Deinem Control erbt. Dann kannst Du auf das geerbte Element wieder andere Controls ziehen.
Ja da hast Du recht. Ich glaube aber nicht das Du das alles brauchst, wenn ich mich richtig erinnere, hab ich's selbst schon mal deutlich kürzer gemacht hab den Code aber gerade nicht zur Hand.
Vielleicht reicht es schon, wenn Du so vorgehst wie in deinem ersten Versuch, aber statt WriteRaw des writers das WriteContentTo des Document benutzt.
Von wo aus wird denn die Name-Property besetzt?
Schau mal in der Doku unter "Control.Name", ob das überhaupt das ist was du haben willst. Wenn Du den Namen der Klasse erfahren willst, geht das eher mit
this.GetType().Name
EDIT:
Mit this.Name würdest du den Namen des erzeugten Fensterobjekts ausgeben, den kann man im Designer angeben.
Hallo,
sieht das jetzt nu hier so aus oder steht das Checkbox-Tag tatsächlich auch in Deiner Control innerhalb des <%@Control%>-Tags?
Das müßte doch so aussehen:
Hallo,
Ich denke für das Setup mußt Du in der .dll eine Installerklasse bereitstellen (ist als Dokumentvorlage enthalten).
In der kannst Du dann Install, Commit, Rollback und Uninstall überschreiben.
Wenn Du dann die .dll bei den benutzerdefinierten Aktionen hinzufügst, wird die entsprechende Methode ausgeführt.
EDIT:
Oder direkt EventHandler für alle möglichen während der Installation auftretenden Ereignisse im Konstuktor der Installerklasse anhängen.
Hallo,
Du könntest vielleicht eine Liste anlegen, in der Du dir beim Ändern eines Objekts (Cahnge-Event) einen Verweis auf das Objekt anlegst. Dann brauchst Du später nur noch die Einträge Deiner Liste abzuarbeiten.