Forenbeiträge von svenson Ingesamt 8.746 Beiträge
Es werden ja nicht nur die Bilder übertragen, sondern insbesondere auch andere Daten. Ich hatte die Hoffnung mich möglichst wenig um den Transport der Daten kümmern zu müssen, da die Arbeit so schon recht umfangreich ist.
In diesem Fall bietet sich eine Hybrid-Lösung an. Mache den "normalen" Verkehr via WCF und weiche im Falle von Massendaten auf pure-HTTP aus. Das ist eigentlich der gängige Weg auf dem CF. Um beide Wege "logisch" zu verbinden tauscht man via WCF eine SessionID (irgendeine Zahl, GUID, etc.) aus, die man dann beim Http-Verkehr als Parameter mit angibt (z.B. in der URL als Parameter). Der Http-Servercode kann dann anhand dieser ID die notwendigen Session-Daten auf dem Server auffinden (z.B. User, Bezugsobjekt, etc.).
Hättest du gute Tutorial für den HTTP oder TCP Transport?
Die Klasse für HTTP-Kommunikation heißt HttpWebRequest (bzw. HttpListener auf dem Server). Dazu findest du Unmengen an Artikeln im Netz. Einfach mal googeln.
WCF kannst du in diesem Falle auf dem CF vergessen. Übertragen die Daten klassisch per HTTP oder TCP.
Wer Google kennt, ist wie immer König:
Ich vermute, da stimmt was mit der IIS-Konfig nicht. Um das zu prüfen würde ich den Service mal außerhalb des IIS laufen lassen (kleine Konsolen-Anwendung oder so) um sicherzugehen, dass deine WCF-Konfiguration ok ist.
Wenn es denn unbedingt Read/WriteFile sein muss, dann vielleicht doch einfach den COM-Port via Win32-Funktionen öffnen.
Namespaces haben nur den Sinn der Herstellung von Namenseindeutigkeit. Sofern dein Schema das erreicht ist es reine Geschmackssache.
Zeig uns mal den C#-Code am Stück in nicht in Teilen.
BTW: Die Deklaration ist falsch und müßte lauten:
[DllImport("usbavrlablib.dll")]
public static extern IntPtr OpenDevice(int Index);
Zu beachten:
Note: Applications that use device-specific apps will not run properly on the desktop, and controls will render as desktop controls.
CF-UI-Applikation laufen zu lassen, wird daher wenig Sinn machen.
Du kannst die Anwendung entweder im Emulator oder aber direkt auf dem Device laufen lassen. In Windows geht es nicht.
Ich will mir den Film auch anschauen. Weniger weil mich die Handlung besonders interessiert, sondern eher weil es wohl ein Film ist, von dem man später sagen wird, dass es die Geburtsstunde des 3D-Films war. Alles was man bisher sah, war ja mehr oder weniger Effekthascherei. Schon bei meinen ersten Erfahrungen in Sachen 3D habe ich mich gefragt, wie man die neue Dimension wirklich künstlerisch umsetzen kann. Nun ist James Cameron ein alter Hase sein Fachs und dürfte damit die Meßlatte ersteinmal definieren.
Vermutlich wird Avatar für den 3D-Film das sein, was damals Tron für den computeranimierten Film war. Ich gehe davon aus, dass 3D als Mainstreamtechnik viel schneller über uns kommen wird, als wir uns das heute vorstellen können. Selbst 3D-Fernsehen scheint kurz vor der Marteinführung zu stehen. Die notwendigen Formate sind bereits definiert. Hier steht uns ein Schritt bevor (bzw. sind wir mittendrin), der vergleichbar mit der Einführung der Farbe in Film und Fernsehen ist.
- Wenn ich das ganze in einer Schleife ausführe, habe ich immer nach zwei WebRequests eine merkwürdige Kunstpause - woran könnte das liegen?
Riecht nach einer der Beschränkungen von ServicePointManager.DefaultPersistentConnectionLimit oder ServicePointManager.DefaultConnectionLimit.
Schau dir mal die Concurrent Coordination Runtime (CCR) von MS an. Für hochgradig parallele und gute skalierende Anwendungen braucht man einfach Programmierkonzepte und -Konstrukte, wie man sie in Sprachen findet, die extra für Parallelisierungsaufgaben gestrickt wurden (z.B. Erlang). Diese Konzepte hat sich MS abgeschaut und versucht in einem Framework (CCR) zu implementieren.
Vielleicht hilft dir das:
Aber das sollte dir zu denken geben:
http://www.lhotka.net/WeBlog/ThoughtsOnPassingDataSetObjectsViaWebServices.aspx
Bei WCF und https hast du auf der Server-Seite mit den Zertifikaten nix am Hut - auch wenn das die Configs suggerieren. Das ganze SSL-Geraffel macht der Host, bzw. http.sys (der HTTP(S)-Stack von Windows). In diesem Fall musst du entweder den Http-Stack von Windows direkt mittels Kommandozeilenprogrammen (WinXP hat andere als Vista/Win7) konfigurieren. Die Zertifikate (Server/CA) müssen zuvor die Stores installiert worden sein. Bei Hosting im IIS konfigurierst du da die (zuvor installierten) Zertifikate.
Bei den Zertifikaten musst du aufpassen: Es gibt die Zertifikate in den Internetoptionen und noch einmal diejenigen über die MMC-Konsole (Certificate Services). Ersteres ist der Ort für Clients, letzteres ist der Ort für die Server-Zertifikate.
IIS:
Self-Hosted WinXP/Server 2003:
http://developers.de/blogs/damir_dobric/archive/2006/08/01/897.aspx
Self-Hosted VistaWin7/Server 2008:
Der Vorteil von Https: Damit kannst du basicHttpBinding fahren, also z.B. ärmliche WS-Stacks z.B. von mobilen Geräten anbinden. Allerdings haben diese im HTTPS-Bereich oft empfindliche Einschränkungen (z.B. das CF), was wirklich "heisse" und ausgefallene Konzepte - gerade im mobilen Umfeld spannend und wichtig - oft unmöglich macht (an dieser Stelle möchte ich mal einen Kübel Schande über MS und seine CF-Inder ausschütten!).
WCF ist ein Apfel, Remoting ein Karotte und XYZ ist sowieso besser.
Soviel zum Thema unqualifizierte Vergleiche...
Aber zum Thema: WCF ist erprobt und es ist im .NET-Sektor für viele Anwendungsfälle im Kommunikationsbereich 1. Wahl. In jedem Fall, wenn es um klassische Webservices (bzw. mit SOAP oder JSON) oder um Messaging geht. Ebenso wenn man es mit Cloud-Computing zu tun hat. ASP.NET-Webservices sollte man nicht mehr anfassen, es sei denn, man hat es mit Altlasten zu tun. WCF ist im WS-Umfeld das, was bei Java Metro ist: Der Referenz-Stack u.a. getrimmt auf max. Kompatibilität.
Und wer setzt es ein: Ich würde mal sagen: Praktisch jeder, der sich im o.g. Umfeld bewegt. Ich tue es in meinen Projekten schon seit Jahren.
Du kannst einen Service haben, aber der muss in zwei Endpoints mit verschiedenen Konfigurationen angeboten werden. Zudem musst du darauf achten, dass Streamed Services bestimmten Restriktionen unterliegen, d.h. der Service-Contract muss Stream-tauglich sein.
Die Schnittstelle heißt RRAS API. Die Funktionen beginnen mit MprAdmin. Du brauchst das Windows Server SDK.
Die von dir gesuchte Funktion wäre MprAdminAcceptNewConnection. Die wird vom RAS-Server aufgerufen, wenn eine RAS-Verbindung erfolgreich hergestellt werden konnte. Mittels MprAdminConnectionHangupNotification kannst du dich über das Ende der Verbindung benachrichtigen lassen.
Du vermischt hier verschiedene Kommunkations-Schichten. BTSPP ist ein High-Level-Stream-Layer. Da brauchst du dich um Probleme von Datenverlusten, etc. nicht kümmern.
Wer es kostenlos mag, sollte sich das mal anschauen:
http://www.devexpress.com/Products/Visual_Studio_Add-in/CodeRushX/
Der XmlSerializer unterstützt List<T>. Nur xsd.exe ist zu doof dazu.
Ich bin inhaltlich ganz bei Golo. Für mich persönlich gibt es drei Gründe:
- Ein Service-Locator ist extrem leichtgewichtig.
- Es ist ein simples und einfaches Konzept
- Es erlaubt mir die Integration bestehenden Codes ohne Anpassung (siehe Golos Einwand bzgl. des Konstruktors)
Alles zusammen ist für mich wichtig, weil ich mich damit von konkreten Eigenschaften verschiedener DI-Container unabhängig mache und zudem die Einstiegshürde für andere erleichtere (SL ist leichter zu vermitteln als DI).
Ich habe neulich versucht eine Service-Bus-Implementierung auf das CF zu portieren und bin dabei gescheitert, weil das ganze Ding nicht ohne DI funktionierte (und ein entsprechener DI schlicht nicht existierte). Damit verkehrt sich leider der Sinn von DI ins Gegenteil. Zum Glück gab es einen Klon der Geschichte, der alternativ auch via Service-Locator konfigurierbar war (in diesem Fall brachte der SB die SL-Implementierung mit). Damit stand der Portierung nichts mehr im Wege.
DI spielt m.E. seinen Vorteil bei komplexen Objekt- bzw. Komponenten-Hierarchien aus. Die Frage ist, ob ein solche komplexe Hierarchie dann nicht eigentlich eines Architektur-Refactorings bedarf. Als provokante These formuliert: Wenn DI wirklich schnackelt, dann ist die Architektur suboptimal weil zu feingranular.
Dieses On... finde ich ein wenig unselig, was aber vielleicht ein wenig mit meiner Delphi-Vergangenheit zusammenhängt. Ich habe mir angewöhnt, die Event-Auslöser Fire....() zu nennen (z.B. FireJoined()). Finde ich klarer und ich komme nicht mit der ggf. unterschiedlichen verstandenen On....-Semantik ins Gehege.
allerdings schreibt er mir nur das letzte und nicht alle...z.b. 500 rein :S
Mir scheint, du hast das gleiche Problem, wie dieser Kollege:
Problem beim serialisieren von komplexen Klassen mit XmlSerializer
oder du baust dir eine zusätzliche Klasse, die dann als öffentliche Eigenschaft eine Liste oder ein Array mit Schülern enthält (get und set natürlich). Diese zusätzliche Klasse gibst du dann beim (De-)serialisieren an.
Konkret: Baue die eine Klasse "Schuelerliste":
[System.Xml.Serialization.XmlTypeAttribute(AnonymousType=true)]
[System.Xml.Serialization.XmlRootAttribute(Namespace="", IsNullable=false)]
public partial class Schuelerliste {
private SchuelerType[] schuelerField;
/// <remarks/>
[System.Xml.Serialization.XmlElementAttribute("Schueler")]
public List<SchuelerType> Schueler {
get {
return this.schuelerField;
}
set {
this.schuelerField = value;
}
}
}
public partial class SchuelerType {
private string nameField;
private string alterField;
/// <remarks/>
public string Name {
get {
return this.nameField;
}
set {
this.nameField = value;
}
}
/// <remarks/>
public string Alter {
get {
return this.alterField;
}
set {
this.alterField = value;
}
}
}
Dann serialisiert er so:
<?xml version="1.0" encoding="UTF-8"?>
<Schuelerliste xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<Schueler>
<Name>Hans</Name>
<Alter>15</Alter>
</Schueler>
<Schueler>
<Name>Otto</Name>
<Alter>12</Alter>
</Schueler>
</Schuelerliste>
Man beachte den Konstruktor-Parameter von XmlElementAttribute.
Jedoch wie sähe es dann mit einer Antwort der Gegenstelle aus??
Meinst du mit "er kann nur ein Objekt", dass er auch nicht zwei, oder mehrere Objekte hintereinander serialisieren kann und dafür den gleichen Stream benutzt?
Der Server muss sich ebenfalls daran halten. Wenn du XML zurücklieferst, dann ist das eben üblicherweise ein Dokument. Und ein XML-Dokument hat nunmal nur EIN Rootelement. Wenn du mehrere Dokumente pro Request / Response verschicken willst, dann muss du dir eben einen geeignete "Hülle" / Protokoll einfallen lassen und dann die Serialisierung mehrfach aufrufen.
Der XMLSerializer kann nur ein Objekt. Aber baue dir doch ein "Über"-Objekt, welches mehrere Objekte aufnehmen kann.
PDA als "Server" kannst du knicken, zumindest nicht auf direktem Wege. Der wichtigste Grund dafür: Du kannst einen PDA nicht per Mobilfunk erreichen, es sei denn, du rufst ihn per Voice-Call an. Verwendest du GPRS/UMTS, dann filtern deine Provider alle eingehenden Calls raus. Darüberhinaus fehel im CF alle notwendigen Klassen um einen Server zu basteln. Kein HttpListener, kein WCF-Service-Host. Allenfalls kannst du direkt auf TCP aufsetzen, aber wie gesagt: Der PDA muss den Socket aufbauen.
Wenn du HTTP fahren musst, dann musst du Pollen, bzw. in der "schlaueren" Form: Long Polling.
Um an der RS-232 angeschlossene "Gegenstellen" zu erkennen, gibt es extra Leitungen namens DTR/DSR. Entsprechende Properties finden sich in der SerialPort-Klasse. Natürlich müssen beide Seiten DTR/DSR unterstützen und das verwendete Kabel die Leitungen auch besitzen.
Kannst du ansonsten nicht CodeDOM des normalen Frameworks benutzen? So wie ich es verstehe, geht es doch um Post-Compile-Time. Zu dem Zeitpunkt bist du doch noch nicht aufs CF beschränkt, oder?
herbivore
Ja, das ginge. War auch mein erster Ansatz. Aber CodeDOM ist wenig transparent und vergleichsweise aufwändig. Mir scheint T4 für diesen Fall deutlich besser geeignet.
"generisch" und "Postsharp" ist ja in gewisser Hinsicht ein Widerspruch: Wenn man das tatsächlich mit irgendeinem Rewriter realisiert, der z.B. in jeden Typ eine Methode "Serialize" injiziert, ist es ja wieder nicht wirklich "generisch" - letztendlich stellt einfach jeder Typ ein Member zur Serialisierung bereit.
Generisch wäre das nur aus Sicht der Anwendung. Aber das reicht.
Hast du schon ein paar Messungen mit Reflection durchgeführt?
Nein, aber da hier rein im Speicher gemarshallt werden soll (für IPC), wird das schon ordentlich ziehen. In diesem konkreten Fall ist wirklich maximale Performance gefragt, weil die Operationen im Hochlastbetrieb auftreten und andere Teile dadurch effektive Leistungseinbußen verzeichnen. Also mal kein "Hauptsache-schnell-genug"-Fall.
Aber mittlerweile hab ich eine recht genaue Vorstellung, wie man das mittels T4-Templates bewerkstelligen kann.
Ich stehe vor der Aufgabe, einen generischen, binären Serialisierungsmechanismus zu schreiben. Da ich auf dem CF arbeiten muss, stehen mir die klassischen Formatter (und alle Hilfsklassen drumrum) nicht zur Verfügung. Des weiteren soll aus Anwendungssicht die Serialisierung transparent für die jeweilige Klasse sein, vergleichbar mit dem XmlSerializer. Die zu serialisierenden Felder der Klasse sollen Attribute bekommen, die in den Serialisierungsprozess eingehen sollen (Feld-IDs)._ Der Serialisierung soll ohne jeden Reflection-Code zur Laufzeit auskommen. (Performance) _ Codegenerierung ist also ein Muß. Nun ist CodeDOM ausgesprochen geschwätzig und Emit steht mit auch nicht zur Verfügung. Die Lösung sollte generisch sein, also für beliebige Klassen funzen. Als vereinfachende Einschänkung kann gelten: Echte Typsicherheit ist nicht gefordert (TypID nur für Skalare). Weder Polymorphie noch Generics müssen unterstützt werden. Nur einfache Collections (Array, List) müssen gehen. Auch Referenz-Unterstützung ist nicht gefordert. Das ganze ähnelt im Prinzip stark der XML-Serialisierung, aber eben binär.
Bestehende Projekte mit CF-Binding (z.B. protobuf-net) kommen leider nicht in Betracht, weil ein spezifisches Legacy-Protokoll implementiert werden muss und die verfügbaren Frameworks leider nicht die notwendige Offenheit besitzen oder letztlich immer auf Reflection aufsetzen.
Mein Gedanke ging dann in Richtung AOP. Hier fehlt mir aber die notwendige Erfahrung, vielleicht könnt ihr mir helfen.
Ziel wäre es, via Serializable-Aspekt entsprechende Interfaces inkl. Implementierungen in die betreffenden Klassen zu schiessen. Der Aspekt-Code müßte die Klasse "reflektieren" (wie gesagt - zur Post-Compile-Time) um so den Code für die (De-) Serialierung zu erzeugen (mehr oder weniger Wegschreiben der skalaren Felder (+string) via BinaryWriter und den Aufruf der Serialisierung von Sub-Objekten).
Eigentlich klassischer Persistenz-Aspekt, aber ich finde keine Beispiele zu Postsharp, die mal Persistenz-Implementierungen zeigen.
Geht sowas überhaupt (die "Reflektierung" scheint mit kritisch, Interfaces einzuschiessen scheint zu gehen) mit AOP /Postsharp? Wenn ja, habt ihr einen Dokument/Beispiel/Link, der ein vergleichbares Muster zeigt?
Hat jemand vielleicht eine Idee für einen relativ leicht unzusetzenden, alternativen Ansatz (vielleicht T4-Templates)? Es wäre durchaus möglich, dass nicht Code sondern ein passendes Schema Ausgangspunkt für die Codegenerierung ist, da es sich um reine DTOs handelt.
Du kannst ALLE Parameter der Konfig auch nachträglich per Code ändern, ergänzen, etc.! Insofern braucht es keinen expliziten Platzhalter.
SOAP ist tot.
Es gibt diverse Open Source-Projekte, die die Nutzung von Google vereinfachen. Z.B. diese hier:
http://googleapi.codeplex.com/
http://gapidotnet.codeplex.com/
Solange du uns nicht die Original-Signatur der Funktion zeigst, können wir nicht helfen...
m.E. gibt es keine Nachteile bei der Verwendung von Dependency Injection, nur Vorteile.
Dein Enthusiasmus in allen Ehren, aber hier ist dein Blick getrübt. Es gibt definitiv Nachteile. Wenn dem nicht so wäre, würde man schlichtweg JEDES Objekt via DI erzeugen. Tut man nicht weil:
* Objekterzeugung via Container kostet
* Das Erzeugen der Abhängigkeit gemacht werden muss und damit per se mehr Code geschrieben werden muss.
* Die Transparenz leidet, weil die Logik sich verteilt
Der Umweg über XMLDocument ist unnötig. Du kannst doch direkt in einen FileStream serialisieren.
Na, so eine Event-Registrierung kostet auch Speicher, und wenn du Per Call arbeitest, dann hängst du mit jedem Web-Call einen Event zusätzlich ein.
Wie oft wird denn der Konstruktor von MyWebService aufgerufen?
Das mit dem dll/sys ist Quatsch. Auch eine 64-bit-Version gibt es. Hier wirst du alles finden, um das zum Laufen zu kriegen:
Gibt es da eine Funktion oder Event mit der ich das Paritätsbit auslesen kann? Mal sehen was überhaupt für ein Bit gesendet wird.
Nein, zumindest nicht in der Serial-Port-Klasse. Üblicherweise setzt man dafür ein Stück Hardware ein, was man als Zwischenstück in die serielle Leitung hängt und via LEDs die Pins anzeigt.
Wenn der Empfänger auf Mark oder Space steht, dann kann ja keinerlei Fehlerkontrolle durchgeführt werden (bzw. nur das Kippen des Error-Bits selbst, und das interessiert keinen).
Deswegen wird da kein Error-Event kommen. Nur bei Even oder Odd kannst du mit einem Fehler rechnen. Wenn der Sender auf None steht, und der Empfänger nicht, dann sollte ein Frame-Error oder ein Parity-Error auftreten, weil die Bitlängen pro Byte nicht übereinstimmen. Aber auch hier kann es passieren, dass der Fehler nicht direkt in dem Byte erkannt wird, wo der Fehler auftritt, sondern erst im nächsten Byte.
Bei Paritätsfehlern sollte der Error-Event mit SerialError.RXParity anspringen. Dass du das nicht siehst, liegt vermutlich daran, dass die Empfängerseits None stehen hat, d.h. das Pritätsbit wird gar nicht ausgewertet. Da kannst du auf Sender-Seite einstellen was du willst.
Bis jetzt müssen die dll´s immer noch mit im Verzeichnis meiner exe-Anwendung liegen, damit das Programm überhaupt läuft.
Vielleicht hilft dir ja das:
* Das ist heutzutage normal
* Das machen alle so
* Dlls sind nicht schlimm und beißen nicht
* Der Glaube, dass Anwender sich vor DLLs fürchten und sie nicht wollen, ist falsch
* die Verwendung von DLLs hat auch Vorteile - hurra
Lass mal das ref vor der Übergabe des Arrays weg.
BTW: Mittels
[FieldOffset(16), MarshalAs( UnmanagedType.ByValArray, SizeConst=8)]
public byte[] Data;
kannst du dir den unsafe-Kram sparen.
Du kannst übrigens auch LayoutKind.Sequential verwenden, wenn du Pack=1 angibst. Dann sparst du dir die FieldOffsets. Die Größe der Struktur kannst du mit Marshal.Sizeof() berechnen lassen (ggf. mal gegen die 24 checken).
Exception abfangen, Port schliessen. Dann solltest du den Port öffnen können, sofern die HW wieder dran ist. Ein Neustart der SW ist nciht notwendig - sofern die Treiber deines virtuellen COM-Ports nicht totale Gülle sind.
meines wissens, hinterlässt der kompiler auch gewisse informationen in der fertigen exe-datei!
Das ist sicher nicht der Fall. BTW: .NET-Programme kannst du ja auch nur mit einem Texteditor und dem kostenlosen SDK erstellen (csc.exe). Die Lizenzgeschichte ist also sicher nicht von MS kontrollierbar. Wenn man sich mal vor Augen hält, dass MS - anders als bei Windows - die Lizensierung seiner SW-Produkte erstaunlich wenig restriktiv handhabt, dann ist der Verdacht naheliegend, dass MS eine gewissen Anteil von Lizenzverletzung bewußt in Kauf nimmt, um die Einstiegshürde in seine doch recht hochpreisigen Produkte zu drücken. In der Drogenszene würde man das "Anfixen" nennen. Die kostenlose Abgabe von Schüler- und Studi-Lizenzen dient ja vor allem dem Zweck, dass der Nachwuchs mit MS-Enwticklung vertraut ist. Die kostenlose Abgabe ist also keineswegs eine Nettigkeit von MS, sondern knallharte Produktpolitik. Ich würde behaupten: MS freut sich über jedes Produkt, welches zunächst mit einer kostenlosen Version von MS entwickelt wurde. Wenn sich daraus Einnahmen generieren, dann ist ja der "nachträgliche" Lizenzkauf die Regel.
Insofern: Nicht päpstlicher als der Papst. 😉
BTW: Wenn du VS lizensierst, kannst du übrigens die Kosten steuerlich absetzen.
Schleife!? port.Open, Warten/Lesen, port.Close()?
Ansonsten gehe ich gerne in Unterauftrag. 😃