Forenbeiträge von svenson Ingesamt 8.746 Beiträge
- Der XmlSerializer kann mit keiner Art von Referenzen umgehen. Du bekommst immer eine Kopie.
- SerializableAttribute ist für die Verwendung der Formatter-Klassen. Beim XmlSerializer hat er keinerlei Einfluss.
Für deinen Fall bietet sich der DataContractSerializer von WCF an. Gibts aber erst ab .NET 3.0:
Serialisierung und Deserialisierung
Der Nachteil ist: Du musst alles schön mit DataContract und DataMember auszeichnen. Build-In-Klassen von .NET gehen daher nicht.
Den SoapFormatter gäbe es auch noch, aber der macht aber kein Plain-XML- zumindest so out-of-the-box.
globale objekte lassen sich mit dem singleton pattern implementieren
Mal davon abgesehen, dass - wie schon gesagt - globaler Zugriff schlecht ist: Singletons sind oftmals über globale Variablen (statische Member) ZUGREIFBAR. Das ist aber keineswegs zwingend. Singeltons "implementieren" daher globale Variablen nicht.
Deswegen ist der zitierte Satz schlicht falsch. Ein Singleton hat etwas mit der _Zahl _der Objekte einer Klasse zu tun (eins pro Applikation/Thread, etc.) und sagt überhaupt nichts darüber aus, wie auf dieses Objekt zugegriffen wird.
**
Globale Variablen = statische, öffentliche Felder einer Klasse.**
Klar... du musst halt sukzessive alle COM-Ports öffnen und schauen, ob dir dort NMEA-Botschaften entgegenpurzlen. Problematisch ist allerdings, dass man die GPS-Receiver oftmals auf verschiedene Baudraten konfigurieren kann. So eine Auto-Baud-Erkennung ist nicht ganz trivial. Im Prinzip funzt das aber so: Wenn Müllzeichen oder Frame-Errors auftreten, dann liegt der Verdacht nahe, dass der Receiver in anderer Baudrate läuft, als du den COM-Port konfiguriert hast. Dann musst du halt alle Baudraten von - sagen wir - 9600 bis 115200 Baud (darüber machen es die Receiver i.d.R. nicht) durchtesten.
Ja, die RhinoQueue findet sich in vielen SBs. Ist aber eigentlich nur eine Queue und noch kein Bus. Aber die Rhino-Leute haben auch das in petto:
http://ayende.com/Blog/archive/2008/12/17/rhino-service-bus.aspx
Wenn es geht, dann sind Queues - egel welche - immer Mittel der Wahl. Das gilt eigentlich für alle SOA-Geschichten. Sie nehmen - wie du ja schon gesagt hast - viel Komplexität aus der Anwendung und bringen eben auch nette Features, wie offline-Fähigkeit, damit z.B. stressfreies Runterfahren (Updates, etc.). HTTP-basierte Webservices können da nicht mithalten. Aber man muss auch sagen: Es fehlen da auch noch Standards wie Transaktionen, die aber bei fast allen SOA-Anwendungen sowieso kaum eingesetzt werden. Zumeist nicht interoperabel und skalieren schlecht.
ServiceBus-Geschichten sind für sowas eigentlich prädestiniert. Die bieten i.d.R. auch Unterstützung für DI. Der ServiceBus ist aber im Architekturmodell ganz oben. WCF wäre nur ein Transport-Typ (der wiederum auf verschiedenen Channels laufen kann) - also ganz unten im Modell (außer beim .NET Service Bus, hier ist WCF quasi der Kern und der SB nur der Aufsatz). In der Regel hat ein ServiceBus dann noch direkten Support der üblichen MessageQueue-Verdächtigen (MSMQ, Rhino, etc.), da Message-Queueing der natürliche Freund einer nachrichtenorientierten Kommunikation ist.
Ich persönlich arbeitet gerade mit SimpleServiceBus (siehe Codeplex) - einem NServiceBus-Klon.
Die Typinformation kannst du dir schenken. Das macht die Serialisierung ja von sich aus. Analog zu Webservices definierst du deine Messages ja ebenfalls über ein Schema (xsd), auch denen die Serialisierungsklassen gebaut werden - zumindest wenn du XML als Serialisierungsprotokoll verwendest. Ein Contract besteht also aus dem Messagetyp als XML complex type und dem Inhalt. Der wiederum ist aber nur Teil der transportierten Message, die ja noch Infrastrukturinformationen ,wie z.B. die CorrelationID der Message, enthält. Wie die aber serialisiert wird, hängt wiederum vom Transportprotokoll ab. Wenn du XML via MSMQ transportierst, dann steht die im MSMQ-Header.
Aber davon bekommst du aus Anwendungssicht gar nix mit. Da hast du halt Send, Receive, Request/Response und Publish/Subscribe.
Das Problem ist, dass es weder eine Methode, noch einen Typ gibt, der "result" heisst.
Der Problem ist vermutlich in der Xsd lokalisiert. Hast du da mal nach result gesucht?
Bei der Nutzung von TCP kann sowas eigentlich nicht passieren. Wenn die Gegenstelle nicht schnell genug ist, muss Write() blockieren, zumindest wenn die Sendepuffer voll sind. Entweder die Netzwerkstacks des Scanners sind rott, oder du hast ein Problem in deiner Anwendung. Ggf. überfordert auch der Nagle-Algorithmus deinen Scanner. Schalte mal mit Socket.NoDelay = true; den Nagle aus.
Es ist auch zu beachten: Das Mounten kann sehr lange dauern. Je nach Formatierung und Größe der Karte kann das Minuten (!) dauern. Wenn es geht immer mit maximaler Clustergröße (64KB) formatieren. Dazu braucht man aber spezielle Tools, denn das Format von Windows macht für FAT32 keine solch großen Cluster und formatiert dazu nur bis 32 GB Größe.
Du brauchst wceload in deiner Plattform. Damit kannst du CAB-Files installieren (das CF kommt als CAB). Wenn du kein wceload in deiner Plattform hast, hast du verloren. Dann musst du eine Plattform bauen, welches CF 3.5 enthält.
Beachte: Wenn du ein headless device hast, dann muss das natürlich auch die headless Version von wceload enthalten:
KB317803: Ein monitorloses WCELoad Update steht zur Verfügung
Ansonsten: Beachte, dass bei vielen WINCE-Plattformen das gesamte Windows-Verzeichnis (wo auch das CF reininstalliert wird) nicht persistent ist, d.h. nach einem Reboot (Strom weg oder hard reset) ist dein CF 3.5 weg und muss neu installiert werden...
Google doch einfach mal nach "WCF streaming". Im Prinzip möglich, hat alelrdings Einschränkungen (Parameter/Returnwert/Binding).
Read liefert im Blocking mode nur 0, wenn der Stream geschlossen wurde.
Vielleicht das:
Portfreigaben prüfen (20+21), Server-Konfig (ob PASV erlaubt). GGf. einfach mal einen anderen Server ausprobieren.
Wenn der Benutzer in der Lage ist Programme auf das System zu bringen, kannst du den Screenshot nicht verhindern. Also musst du sämtliche IO-Ports dicht machen (USB-Ports, Wechsellaufwerke, etc.). Geschichten wie Drucken dürfen natürlich keinesfalls über Windows direkt erfolgen, sondern direkt über die Anwendung über einen gesichterten Kanal zu einem speziellem Druck-Server. Du musst jeden Weg rein und raus unter Kontrolle haben. Du musst übrigens auch die Erzeugung jeder Datei verhindern. Sonst kann der Nutzer per Hand Byte-Code in eine Datei schreiben und ausführen. Im Prinzip brauchst du ein XP Embedded, welches ausschließlich und nur deine Anwendung zeigt.
In diesem Fall kriegt man einen Screenshot aber gar nicht aus dem System._ Also ist es gar nicht notwendig, der Erzeugen eines Screenshots zu verhindern._
Aber manchmal geht es ja um "gefühlte" Sicherheit und um ein wenig Aktionismus, mit dem man vor dem inkompetenten Chef glänzen kann. In diesem Falle ein paar Ansätze:
- Globaler Windows-Event-Hook um die Taste abzufangen.
- Ständig Clipboard prüfen und leeren, bzw. dauernd mit Müll füllen
- Taste per Hardwaremanipulation außr Kraft setzen (ggf. Sicherheitsdienst alamieren!)
Leider würde nichts davon jemanden mit durchschnittlichen Programmier-Kenntnissen und ein wenig krimineller Energie davon abhalten, trotzdem ein Bild deines Schirmes zu erstellen.
Das finde ich auch gut:
Method and system for copy protection of on-screen display of text
Das Stichwort ist gut, dazu gibt nämlich ein Beispiel von MS:
Gewusst wie: Schreiben eines Kopierkonstruktors (C#-Programmierhandbuch)
Ansonsten gibt das einen guten Einblick über die Probleme, die zu bedenken sind:
Du solltest dir erstmal Grundlagen über Objekte und Refrenzen aneignen. Dann erübrigt sich die Frage von selbst. Was du machen willst nennt sich übrigens "deep clone" (zum googeln). Und wie du dann feststellen wirst: Eine Kopie erstellen ist u.U. gar nicht so einfach. Die im vorigen Post genannten Verfahren zum Kopieren sollte man übrigens nur dann einsetzen, wenn man sich über die Eigenarten der jeweiligen Serialisierungsarten auskennt. Zudem sind sie relativ langsam.
Am besten mal ein Beispiel angucken:
1.GetResponse() ausführen, nachdem du den RequestStream geschlossen hast
2. Das Abort() am Ende verursacht deinen Absturz. Du schiesst dir die Verbdindung selbst ab.
Windows Azure? Noch ist es umsonst...
Oder wie wärs mit einem RSS-Feed. Die Items erlauben beliebige XML-Elemente einzubetten (xs:any).
Eine andere Möglichkeit ist, im 2. Parameter von QueueUserWorkItem ein selbst definiertes Objekt zu übergeben, welches nicht nur die Parameter für die Funktion, sondern auch Events für Fortschritt, Beendigung und Fehler enthält.
Vorab erstmal ein Posting, welches dringend von der ganzen Geschichte abrät:
Das stößt in das gleiche Horn:
Ich würde empfehlen, einfach die passende (letzte) Version der 3rd-Party-DLL mit deiner Anwendung zu installieren. Das ist definitiv der saubere Weg.
Ansonsten findest du da auch den Hinweis, dass man mit Assembly.LoadWithPartialName() die letzte Version aus dem GAC laden kann. Seit 2.0 aber als deprecated markiert. Funzt aber noch. MS will nicht dass man das benutzt, denn du führst damit natürlich die DLL-Hölle wieder ein - zumindest für deine Anwendung. Du hast nun die Möglichkeit viele DLL-Versionen parallel zu installieren, und du solltest davon Gebrauch machen.
AssemblyResolve:
Dealing With Assembly Load Failure
Statt des Ladens aus dem Internet einfach Assembly.LoadWithPartialName() und fertig.
BTW, goto case ... ist die einzige Möglichkeit einen C/C++-ähnlichen Fallthrough zu ermöglichen. Und er ist sogar besser als das Original - man kann nämlich die Case-Blöcke beliebig verschieben und der Compiler meckert, wenn der Fallthrough-Block gelöscht wird. Ohne goto case muss man manchmal auf ellenlange if-else-Ketten ausweichen. Auch nicht gerade schön. Goto label wurde wohl eingeführt um VB-Code besser portieren zu können.
Suche dir auf jeden Fall was mit Zustands- und Sequenzdiagrammen.
Es gibt auch professionelle Tools für umsonst, z.B. die Personal Edition von objectIF:
Schau mal nach, ob der Name der Maschine irgendwelche Sonderzeichen (Underline, etc.) enthält. Denkbar wäre auch, dass der SMTP-Server den Namen nicht auflösen kann, z.B. wenn sie nicht in der gleichen Domäne hängen.
Na, ohne die 3687 kann es nicht klappen.+
LOG: In der Anwendungskonfigurationsdatei wurde eine Umleitung gefunden. 9.0.2.3687 wird nach 9.0.2.3687 umgeleitet.
Das besagt, dass du gegen 3687 compiliert hast und dann auf 3687 (die gleiche Version umleitest). Das Redirection verwendet man, wenn man eine alte Anwendungsversion hat, und ein referenziertes Assembly gegen eine neuere Version austauschen will, ohne die Hauptanwendung neu zu compilieren/installieren. Was damit nicht geht, ist eine Dritt-DLL unabhängig von ihrer Version gegen deine Anwendung zu binden. Das heisst nicht umsonst "binden".
Der einzige Weg für sowas ist m.E. dass du einen eigenen Resolver schreibst (im statischen Konstruktor der Anwendung einhängen), der z.B. die möglichen Assemblies im GAC auflistet und z.B. den neuesten lädt.
??? Du biegst auf 3687 um, hast aber nur 3198 im GAC?
Wenn da hier ein Proxy sein soll, dann musst du mit zwei Threads arbeiten.
Der Unterschied zwischen string.Empty und "" offenbart sich in diesem Fall aus der Distanz. Tretet mal einen Meter vom Monitor zurück (oder setzt die Brille ab).
string.Empty "" "'" " " Wer da den Unterschied nicht erkennt, der hat entweder Adleraugen oder eine 24-Punkt-Schrift eingestellt.Gibt es denn eine Möglichkeit die dll versionsunabhängig einzubinden? Ich kann mir nicht vorstellen, dass das so schwierig sein soll. Aber ich finde nirgends Informationen dazu.
Eigentlich sollte der Weg mit Bindestrich (1.0.0.0-2.0.0.0) bei OldVersion funktionieren. Hast du die public key tokens aller Versionen mal geprüft?
Ich hab das ein bisschen umgeschrieben, erst empfangen, dann gesendet, geht trotzdem nicht.
Nee, natürlich nicht. Die eine Seite muss senden, die andere empfangen. Am besten du besorgst dir mal ein kleine Socket-Beispiel-Programm und schaust dir das erstmal in aller Ruhe an.
werdet ihr nach Zeilen bezahlt?
Das passiert eben, wenn Metriken zur Leistungserfassung eingesetzt werden... 😉
Erst Offset, dann Size (sowohl bei Send als auch bei Receive). Aber auch so wird das nix. Erst wird empfangen und danach gesendet. Klassische Verklemmung.
jetzt möcht ich nur den String allein ausgeben in der listbox...
??? Add() ?
gibt es eine möglichkeit im dan zu sagen was er aus dem objekt anzeigen soll?
Hier hilft genaues Studieren der Hilfe. Es gibt zwei Möglichkeiten:
Wenn der Auflistung ein Objekt hinzugefügt wird, überprüft ListBox zuerst, ob die DisplayMember-Eigenschaft der ListControl-Klasse den Namen eines Members des angegebenen Objekts enthält, auf das zum Abrufen des Elementtexts verwiesen wird. Wenn für die DisplayMember-Eigenschaft kein Member angegeben ist, ruft ListBox die ToString-Methode des Objekts auf, um den Text abzurufen, der in der Liste angezeigt werden soll.
Er lädt das Assembly aus dem Filesystem und nicht aus dem GAC. In diesem Falle lasse den ganzen Binding-Kram weg und er nimmt diejenige, die er beim Probing findet.
Du musst halt bei der Referenzierung in VS aufpassen, ob du strong-named willst oder nicht. Wenn du eh immer alle Komponenten einer Anwendung mit einer neuen Version austauschst brauchst du keinen GAC. Bei Komponenten-Installation ist es zwingend, weil du dann eben mehrere Versionen eines Assemblies im GAC haben kannst. Und DANN schlägt das redirecting zu.
Vielleicht Publisher-Policy?
Ansonsten prüfe mal die Public-key-tokens der neue Versionen. Vielleicht hat der Hersteller die Keys geändert?
Die von dir gewünschte Funktion gibt es doch bereits und heisst AddRange(). Wenn es denn typisiert sein muss, dann einfach eine extension method:
public static class ExMethods
{
public static void AddInts(this ListBox.ObjectCollection col, int[] intList)
{
foreach (object i in intList)
{
col.Add(i);
}
}
public static void AddStringAndInt(this ListBox.ObjectCollection col, string s, int i)
{
col.Add(s);
col.Add(i);
}
}
Irgendwie war ich der Ansicht, dass ich den String selber formen muss.
Wir sind doch hier nicht bei PHP. 😉
Das hier wäre ein Ansatz:
http://www.dimastr.com/redemption/
Die ganz schlanke Lösung wäre halt
Process.Start("mailto:name@domain.com?subject=TestCode&Body=Test Text");
Aber da kommst du halt nicht mehr an die Anhänge und Empfänger ran. Ebenso kannst du nicht feststellen, ob die E-Mail versendet wurde.
Beim Umgang mit WMI empfiehlt sich dieses Tool:
Generiert auch gleich den entsprechenden Code zur Abfrage.
Hier mal ein Beispiel:
http://www.codeproject.com/KB/aspnet/Esignature.aspx
Ansonsten einfach mal "PDF signing" eingeben. Mit dem Umgang mit Zertifikaten und Signierung sollte man natürlich vertraut sein. Und ja, das ist ein nicht ganz einfaches Thema.
Ich vermute eher, dass du gegen die bekannten Restriktionen von .NET und MAPI läufst. Kurz gesagt: .NET und MAPI laufen nur unter ganz bestimmten Vorraussetzungen stabil miteinander:
http://blogs.msdn.com/stephen_griffin/archive/2009/04/03/mapi-and-net.aspx
Nimm mal Win32_NetworkAdapter anstelle von Win32_NetworkAdapterConfiguration.
BTW, benutze lieber SerialNumber von Win32_BaseBoard.
Selbstverständlich ist das eine Gefahr. Um sicher zu sein sind Verschlüsselungsverfahren zwingend, also bei Browsern HTTPS. Ansonsten würde ich empfehlen, wenigstens eine GUID als Session-ID zu verwenden. Die errät man eher nicht. Natürlich kann man die auch abfangen und verwenden, aber das ist eben nicht mehr ganz so einfach. Bindungen an Client-IPs kann man machen, sind aber im Zeitalter von allgegenwärtigem NAT nur ein bedingter Schutz. Die Verschlüsselung eines Integers kann man sich schenken, es sein denn, du füllst sie mit einem Salt auf. Aber dann kannst du auch gleich eine GUID verwenden.
Das Verhalten im m.E. völlig korrekt. Du gibst halt einen String zurück, der Sonderzeichen enthält, die escaped werden. Was du aber willst, ist eine Objektliste (!) zurück zu geben, welche JSON-serialisiert werden soll. Definiere dir eine Klasse Kursänderung (oder so) und deklariere dort die Member symbol, price und change. Dann definiere HelloWorld so:
[WebMethod]
[ScriptMethod(ResponseFormat = ResponseFormat.Json, UseHttpGet = false)]
public KursAenderung[] HelloWorld() {
return new KursAenderung[]
{
...
};
}
Das Stichwort zum Thema ist "Security Token Services". Das ist mächtig, aber auch nicht wenig komplex.
In diesem Fall bietet es sich wohl eher an, den Login-Service direkt als Implementierung einer Role-based-Security abzufackeln. Das ganze Token-Geraffel macht WCF sowieso. Die Tokens werden im SOAP-Header automatisch eingebastelt.
Das alles kommt nur dann nicht in Frage, wenn man nur basicHttpBinding nutzen kann. In diesem Fall muss man die Authorisierung tatsächlich - wie oben beschrieben - in die Anwendungsschicht ziehen.
Zwei verschiedene Services (aus Sicht des Clients) sind in jeder Hinsicht zu vermeiden.
Weil etwa 40 Module nur über solche Zeiger auf 9 verschiedene Tabellen und deren Werte zugreifen.
Sind das C#-Module oder machst du diesen Zeigerkram in Zusammenhang mit unmanaged DLLs?