Forenbeiträge von svenson Ingesamt 8.746 Beiträge
So ist es. Aber WCF != Webservices. Du kannst ja auch WCF ohne HTTP machen, ohne SOAP, etc.! Sessions gehen aber - wenn das Binding es erlaubt - immer. Die Implementierung ist also von Fall zu Fall anders.
Im Prinzip geht es darum, dass in WCF Sessions nix mit Cookies (wie in ASP.NET) zu tun haben. Wie auch WCF selbst sind Sessions ein abstraktes Konzept und auf vielerlei Arten umsetzbar.
Du kannst aber WCF in den Asp.net-compatibility-mode versetzen, dann bekommst du deine Cookies.
Schmeisse diese Regel aus dem Fx-Cop raus und beachte die Regel trotzdem. Es gibt ein Menge Fälle, wo das Fangen von Exception Sinn macht (z.B. bei Threads oder manchmal an Komponentengrenzen).
Die Sicht
Deswegen ist es auch "gut" dass dann ein "Absturz" folgt.
kann man für Oberflächenapplikationen einnehmen. Ein medizinisches Gerät will ich nicht so programmiert wissen.
Aber:
Gehen wir mal davon aus ich habe eine Methode die irgendetwas tut. In der Methode können ca. 20 verschiedene Exceptions auftreten. Bei allen Exceptions möchte ich das selbe tun. Warum kann ich da dann nicht die General-Exception fangen und einmal die Aktion definieren?
Genau in diesem Falle sollte man es nicht tun. Faulheit ist nicht der Grund für die Anwendung, sondern Robustheit. Gerade dieses Vorgehen macht aber die Anwendung nicht robust - im Gegenteil.
Das stimmt so aber auch nicht ganz. Ich habe auch 4 GB an Hauptspeicher und ne Graka mit 1 GB Speicher und mir bleiben 3,25 GB in Windows...
Das ist korrekt, oft wird der Graka-Speicher nicht 1:1 reingemappt, sondern nur Fenster. Aber es stehen nur 2 PCI Aeas a 256 MB zur Verfügung. Die werden ganz oder gar nicht reserviert. Und 256 MB machen die PCI-Devices schnell voll. Da wird schnell die 2 Area reserviert. Und schon sind 768 MB weg (inkl. PCIe-Bereich). SLI ist übrigens immer ein Speicher-Killer. U.U. melden die Treiber auch noch weitere Bereiche für das I/O-Mapping an. D.h. je nach Treiber und Einstellung variiert der Speicher.
Aber lange Rede kurzer Sinn: Man kann daran im Prinzip nicht viel drehen ohne HW auszubauen bzw. zu tauschen. Und mehr als 3,5 GB sind nicht drin, heutzutage sind 3,25 eigentlich die Obergrenze. Meist liegt es sogar bei 3 oder darunter.
Also lieber nur 3 GB kaufen und vom gesparten Geld einmal ins Kino gehen oder eben ein x64-BS drauf...
In der Praxis ist das eigentlich eh schnuppe, denn man hat eigentlich immer nur eine Speicherfresser-Anwendung am laufen, die aber max. 2 GB belegt (/3GB mal außen vor, das ist eh nix für Normaluser-Systeme).
Aber vielleicht mal zurück zum Thema: Wie sieht der Absturz aus (Bluescreen?). Wann tritt er auf? Erst nach einer Weile? Vielleicht auch mal im Gerätemanager prüfen, ob es irgendwelche HW-Konflikte gibt.
Was ist das für ein Stream? Wo kommt der her?
Sollte ich dann einen eigenen Fehlervertrag (FaultContract) implementieren und einen solchen schmeissen, wo dann sowas "Kunde konnte nicht gefunden werden!" drinnsteht?
Kurze Antwort: Ja.
Aber wie kann man direkt auf den QuellStream zugreifen ?
Den hat man eiegntlich immer 😃 Den BinaryReader verwendet man eigentlich nur, wenn man die Daten typisiert aus einem Stream lesen will, aber double, long, etc.! Wenn man rein auf Byte-Ebene arbeitet tut es auch der Stream. ReadBytes() alleine im Kontext des BinaryReaders zu verwenden macht daher keinen Sinn. Nur in Kombination mit den anderen Methoden wird es eingesetzt, i.d.R. um Byte-Blöcke innerhalb einer Daten-Struktur auszulesen.
Ich denke, ihr müßte euch hier keine Sorgen machen. Die Komponenten-DLLs werden ja von euch gebaut und wie das zu geschehen hat schreibt keine mir bekannte OS-Lizenz vor. Die Code-Änderung für die Signierung ist ja ebenfalls erlaubt.
Ich frage mich nur, was man macht, wenn es sich um (kommerzielle) Komponenten handelt und man überlichweise keinen Sourcecode hat. Hier muss man ja für eine nachträgliche Signierung mittels ildasm eine neue, signierte DLL bauen. Das wird vermutlich nicht erlaubt sein.
Hier mal ein gutes FAQ zum Thema:
http://www.msxfaq.de/konzepte/4gb.htm
Windows XP (und Vista) aktiviert PAE automatisch, sofern das BIOS das unterstützt. Deswegen helfen die sogenannte PAE-Tricks sowieso nichts.
Hilft nur eins: x64-BS installieren. Auf meinem Windows7-64bit hab ich die vollen 4 GB für Apps (nicht nur physikalisch) - trotz 1 GB Graka.
- Es ist ziemlich langsam
Verwende direkt den Stream und mache deutlich größere Blöcke (65k oder so).
- Die Art wie ich EOF(End of File) abfrage, geht das nicht eleganter ?
Hilfe zu ReadBytes:
Return Value
Type: array<System..::.Byte>[]A byte array containing data read from the underlying stream. This might be less than the number of bytes requested if the end of the stream is reached.
So geht das auch bei den Stream-Methoden.
Dein 1 GB-Graka-Speicher muss in den 4GB-Adress-Bereich eingemappt werden (da waren es nur noch 3 GB). Dann noch nen bißchen Klingelkram und du bist bei 2,8 GB.
Kurz gesagt: Investion sinnlos, es sei denn du fährt ein x64-BS. Da hast du volle 4 GB.
Anders als bei .NET gibt es bei Java viele verschiedene WS-Stacks. Selbst bei basicHttpBinding gab es da Probleme (z.B. RPC vs. document style). Hier hilft nur probieren über studieren. I.d.R. lassen sich aber diese Probleme allesamt lösen. Bei wsHttpBinding sieht es wieder ganz anders aus. Hier sollte man am besten die Stacks von Sun (Metro) oder von Apache (Axis) einsetzen. Die sind auf Interop mit WCF getestet und vermutlich am weitestgehensten kompatibel.
Ich geb mal eine Schätzung ab: Zu 95% wird das ohne Probleme und sofort funzen. Ggf. musst du die WSDLs auf der WCF-Seite flachbügeln.... Das geht mit ein paar Zeilen Code und einer speziellen WCF-Konfiguration.
Willst du hier _Objekte _mit Parent zu einer Baumstruktur zusammenfügen oder willst du wirklich die _Basistypen _mit Parent kennzeichnen? Reflection bietet über mit obj.GetType().BaseType letzteres schon out-of-box.
ASCII-Dateien können von Utf-8-Encodern problemlos gelesen werden, da Utf-8 im ASCII-Bereich (0-127) kompatibel ist. Ebenfalls ist ANSI mit ASCII in diesem Bereich kompatibel.
Da du aber ANSI ursprünglich vorliegen hast, liegt das Problem beim Lesen mittels Flex3. Alle Zeichen bis 127 werden korrekt gelesen, die Umlaute gehen verloren. Deine .NET-Anwendung hat keine Chance mehr, denn die Umlaute sind schon verbaselt.
Wenn du Glück hast, dann schreibt Flex3 genauso weg wie es gelesen hast. Dann musst du halt in .NET mit ANSI und der richtigen Codepage arbeiten.
Ich empfehle mal einfach mittels HTTP-Sniffer dir die beiden Request (einmal IE, einmal dein Tool) anzuschauen und zu vergleichen. Meine Vermutung: Proxy prüft zusätzlich noch UserAgent, und die werden sich unterscheiden.
- Zeile lesen
- Mittels StartWith("//") prüfen ob Kommentar
- Wenn nein, Zeile in Zieldatei schreiben
- Zurück zu 1 falls Datei nicht zuenden
Noch besser (oder einfacher) wird allerdings sein, dem Tipp von svenson (zumindest teilweise) zu befolgen und Regex zu verwenden
Oder vielleicht auch nicht, wenn man sich mal diesen Thread anschaut:
http://objectmix.com/csharp/356343-regex-challenge.html
Man findet im Netz nicht eine passable Lösung... ganz schlechte Vorraussetzungen. 😃
Regex wird nicht taugen. Man kommt wohl um einen recht aufwändigen Parser nicht drumrum.
angenommen es gibt eine Seite mit sehr vielen Kommentaren,
Vielleicht diskutieren wir hier ja die Super-Duper-Lösung und ist gefragt ist was ganz anderes. Die Fragestellung ist nämlich reichlich ungenau.
Als Ergänzung: Der Typinitialisierer (oder "statischer Konstruktor") ist auf jeden Fall kein sicherer Platz für eine solche Anmeldung, da er erst bei der ersten Verwendung eines Typs aufgerufen wird.
Vollkommen richtig. Man kann allerdings per Code den Initializer aufrufen (lassen). Aber dazu braucht es wiederum Reflection oder Typ muss bekannt sein.
Gegen Reflection ist m.E. auch wenig einzuwenden. Wenn man Interfaces einsetzt ist Reflection fast immer irgendwie im Boot (Plugins, etc.). In deinem Falle musst du dir auch keine Sorge machen, dass das irgendwie langsam oder so wäre. Die Interfaces der Appdomain bzw. des Assemblies zu durchforsten geht ratzfatz. Kritisch ist Reflection eigentlich nur bei dynamischen Aufrufen. Aber das auch nur wegen der Menge der Aufrufe.
geht das mit trim Methode oder starts with? Habe von meinem Ausbilder als Tipp bekommen wonach ich suchen muss
Ah... ich nahm an, dass du das innerhalb von Visual Studio machen willst, statt dir extra ein Tool dafür zu schreiben...
BTW: "//" kann im auch im regulären Code vorkommen (nämlich als Teil eines String-Literals).
Ich würde dir trotzdem zu Reflection raten. Du bist sonst - wie schon gesagt - gezwungen eine Basisklasse zu verwenden. Damit konterkarierst du den Sinn von Interfaces (lose Kopplung) oder gehst (bei "freiwilliger Anmeldung") die Gefahr ein, dass eine Klasse "vergißt" sich anzumelden.
Suchen/Ersetzen mittels Regular Expression.
Entweder melden sich die Klassen aktiv an oder du machst das via Reflection. Da ersteres eine Basisklasse erfordert (keine statischen Methoden in Interfaces), bietet sich die 2. Lösung an. Einfach alle Klassen in der AppDomain suchen, die das Interface implementieren.
http://www.codeproject.com/KB/files/UserFileAccessRights.aspx
http://www.freshclickmedia.com/blog/2008/11/programmatic-impersonation-in-c/
Das Stichwort zum Thema "Leveln" heisst "Impersonation".
Du musst halt nur deinen Service über mehrere, parallele Bindungen anbieten. Das erfordert allerdings den Zugang über verschiedene Ports.
Alternativ machst du HTTPS zu einem Reverse Proxy (Squid oder so), der vor dem WCF-Server steht. Der macht aus HTTPS dann HTTP und meldet sich auch via Username/Passwort an. Im Unternehmensumfeld - wo man eh den Proxy aus Sicherheitsgründen drin hat - die bessere Lösung. Diese Lösung ist in jedem Fall angesagt, wenn der HTTPS-Zugang über das Internet erfolgt.
Wenn das ginge wären die Rechte ja reichlich sinnlos, oder? Du könntest höchstens feststellen, dass die Rechte nicht ausreichen und den Nutzer auffordern die Account-Daten eines berechtigten Users einzugeben. Dann könnte sich die Anwendung entsprechend "hinaufleveln".
Ja, gibt es. Das Property heisst Proxy. Falls du HTTP-Download machst, solltest du auch die Möglichkeit vorsehen, den Useragent zu konfigurieren. Viele Unternehmensfirewalls checken das.
Ich würde empfehlen: Einfach mal austesten.
Ein kleiner Tipp: Leider gibt es kein Freeware-Tool, welches komplexere Schemata (mehrere Files, Namspaces, etc.) beherrscht.
Wenn es wirklich komplex wird, gibt es nur ein Tool welches brauchbaren Serialisierungscode erzeugt: XmlSpy. Allerdings ohne XmlSerializer Benutzung. Leider sündhaft teuer, aber die 30-Tage-Trial bringt den Codegenerator mit...
Man muss dazu sagen, dass die OpenNETCF-Implementierung buggy ist. Mit 2.2/2.3 stürzt es wenigstens nicht mehr ab. Preshared-Key funktioniert nicht mit WPA2. Es ist nützlich den Source-Code zu haben, der Bug ist leicht zu fixen. Grundsätzlich empfehle ich nur die 2.3 einzusetzen. Alle Vorgänger-Version erfordern das Rebinden des Adapters, was reichlich unzuverlässig funkioniert.
Und noch eins: Es wird WZC benutzt. Das hingegen ist kritisch wenn der Connection-Manager im System aktiv ist.
Ich habe keinerlei Probleme mit xsd2Code. Momentan mit Abstand das beste Tool für die Erzeugung von Serialisierungsklassen.
Hamachi geht auch wieder über einen Server, also nicht das was er sucht.
U.U. doch. Sitzen beide Rechner hinter einer restriktiven NAT/Firewall ist Essig mit VPN, weil keiner den anderen erreichen kann. Da hilft dann nur noch "hole punching" und das erfordert eben einen Server. U.a. dafür ist Hamachi gebaut worden. Mit der gleichen Technik überwindet auch Skype solche Schranken.
Der Server wird aber nur für das "hole punching" gebraucht. Später läuft die Kommunikation P2P, zumindest solange bis NAT das Loch erkennt und stopft.
Im privaten Umfeld reicht aber i.d.R. VPN und DynDNS. Das beherrschen eigentlich schon die besseren DSL-Router (Fritzbox, etc.) out-of-the-box.
Aber reicht nicht auch einfach DynDNS und FTP(S)? Filezilla ist in 1 Minute installiert...
WCF ist nicht objekt- sondern serviceorientiert. Willst du auf Server-Objekte zugreifen musst du das explizit implementiert. Also einen Service schreiben, über den du dir einen Handle für ein Remoteobjekt besorgst und dann weitere Service-Methoden die den Member-Zugriff via Handle erledigen. Ggf. könnten auch Sessions ein Weg sein.
Wenn es unbedingt OO sein soll, dann musst du Remoting einsetzen.
Dass WCF nicht OO ist scheint altbacken, aber die Serviceorientierung (SOA) ist ein bewußter "Rückschritt" als Reaktion auf das Scheitern der Versuche OO im verteilten Umfeld zu etablieren (CORBA, etc.). Die damit verbundenen Probleme (vor allem die Zustandsbehaftung) wurden den Anforderungen im Internet nicht gerecht.
Vielleicht hilft das bei der Auswahl:
Du solltest hier nicht mit 2 Timern arbeiten, sondern mit Callbacks/Event. Alle 10 Erfassungen ruft der Sensor-Thread eine Methode auf, die die Daten weiterverarbeitet. In dieser Methode kopierst du den Puffer und schiesst die Datenkopie via Control.BeginInvoke() in den UI-Thread. Dort kannst du sie dann anzeigen.
Sowas kannst du nur einigermaßen passabel mitt Speicherdumps analysieren. Ggf. kannst du vor dem Absturz mal rausfinden, an welchen Adressen die DLLs geladen sind. Anhand der Absturzadresse hast du dann schonmal wenigstens die schuldige unmanaged DLL.
Die 0x00000008 riecht ein wenig danach, dass irgendwo ein Null-Pointer übergeben wird und die 8 der Index in eine Struktur oder Array ist. Prüfe mal ob du irgendwo Null-Referenzen übergibst.
CheckInstance() gehört anstelle von Application.Run() ins Main().
Einmal reicht. Das Nebenläufigkeitsverhalten wird innerhalb des Service-Interfaces durch Attribute angegeben:
So ein vorgehen wie du sie beschreibst JAck30lena ist aber für ner Firma echt das letzte. Da würd ich aber mal beim Betriebsrat anklopfen. Ich finde es kann nicht sein dass ne Firma ihre Leute in Kurzarbeit schickt, sie weniger an Lohn ausschütten muss, und trotzdem ihren gewohnten Umsatz macht und durch das Vorgehen ja im Endeffekt Geld spart. Auch die Angestellten werden ja um ihren Lohn gebracht nur das die Bilanzen besser aussehen. Dagegen sollte ein Betriebsrat unbedingt vorgehen.
Na dann beklag dich mal bei Siemens, VW und wie sie alle heissen. Dort wird überall kurz gearbeitet und die Konzerne schreiben Gewinne. Nun zahlt der Steuerzahler den Aktionären ihre Gewinne.... soweit ist es gekommen...
Bei uns ins Kurzarbeit mittlerweile offiziell angekündigt. Wen bzw. welche Abteilungen es treffen wird ist noch nicht klar. Ist aber nur eine Frage der Zeit. In unserer Abteilungen können die Löhne z.Z. nur noch zu 2/3 durch Aufträge gedeckt werden. Ist aber weniger der Wirtschaftskrise als internen Faktoren zuzurechnen....
Ist doch toll. Wer Fehler zählt, statt sie zu behandeln, hat echt ein dickes Fell. Respekt. 😉
Beispiele werden hier nicht helfen. Du musst mal mittels HTTP-Snipper (Fiddler oder so) den SOAP-Verkehr belauschen und schauen was da schief läuft. Die PHP-WS-Stacks sind so kompatibel wie nen Sack Schrauben. Und du solltest unbedingt WCF und nicht ASP.NET-WS benutzen.
Ich sehe das nicht so.
Ich antworte darauf nochmal mit dem "Kritiker der Kritik":
Die angeführten Gründe halten jedoch einer eingehenden Prüfung nicht stand. Der erste Kritikpunkt ist rein theoretischer Natur, da optionale Parameter mit Standardwerten in Szenarien nicht geeignet sind,** in denen der Standardwert nicht unumstößlich feststeht.**
Aber erkläre mir doch nochmal inwiefern sich Konstanten im Versionierungsproblem von optionalen Parametern untscheiden. Hier ist für den Entwickler wegen des Wortes "const" vielleicht noch eher klar, worum es sich handeln sollte. Aber an der nächsten Ecke lauern auch hier schon wieder die "Performance-Optimierer" die mal gehört haben, dass const schneller ist als readonly. Von den C-Umsteigern, die const aus Gewohnheit verwenden, ganz zu schweigen...
Aber wir reden wohl aneinander vorbei: Es geht mir nicht um die korrekte und dann auch sichere Verwendung von const und optional, sondern um das Gefahrenpotential die sie für unerfahrene Entwickler bergen.
Die 32 hätte ja nicht nur per Default-Wert in den Code des Aufrufers kommen können, sondern einfach durch die bewusste Entscheidung des Aufrufers, explizit 32 zu übergeben. Und dann würde es in deinem Beispiel genauso knallen.
Sicher, aber wie bereits gesagt wurde: Optionale Parameter implizieren die Bedeutung: "Da muss ich mich nicht drum kümmern, wird schon". Also bewußt _keine _bewußte Entscheidung. Das gleiche Problem gilt übrigens auch für öffentliche Konstanten. Auch die werden beim Aufrufer fest eincompiliert. Daher in öffentlichen Schnittstellen besser readonly-Felder verwenden, sofern sich der Wert später mal ändern könnte.
Hier nochmal eingehender:
http://dotnet.mvps.org/dotnet/articles/optional/
Bemerkenswert die "Kritik an der Kritik":
Die angeführten Gründe halten jedoch einer eingehenden Prüfung nicht stand. Der erste Kritikpunkt ist rein theoretischer Natur, da optionale Parameter mit Standardwerten in Szenarien nicht geeignet sind, in denen der Standardwert nicht unumstößlich feststeht.
Der Hinweis zur Verwendung ist richtig, aber hier ist der gute Mann doch wohl ein wenig optimistisch, was die Disziplin der Entwickler angeht. C# ist mal unter dem Banner "defensives Programmiermodell" angetreten, mit dem Ziel Qualität über Faulheit stellen. Optionale Parameter sind wohl ein deutliches Zeichen für die Abkehr von dieser Strategie und geben den Kritikern an C# wohl recht, die sagen, dass die Sprache mehr und mehr verwurschtelt wird.
Flexibilität kann ich in diesem Zusammenhang nicht erkennen, außer dass der Entwickler nun so flexibel ist, eine fehleranfällige und eine fehlerunanfällige Implementierung zu wählen.
Die WSDL wird ausschließlich zur Compile-Time genutzt. Zur Laufzeit wird davon ausgegangen, dass sich die WSDL zwischenzeitlich nicht geändert hat.
Also
oder gemäss dem WSDL, mit dem entwickelt wurde, und das ursprünglich mit "Add Web Reference" dem Projekt hinzugefügt wurde?
Ja!
Man kann auch dynamische Geschichten bauen, aber die sind naturgemäß auf Anwendungen reduziert, bei denen der Anwender mehr oder weniger per Hand den Service aufruft. Typisches Szenario sind WS-Testclients. Dort zieht der Testclient die WSDL, baut den Service-Code zur Laufzeit und bietet dem Nutzer eine Oberfläche zur Wahl der aufzurufenden Service-Methode und Befüllung der Parameter. Quasi WS-Reflection.
Ich höre so ein wenig aus deiner Frage raus, dass du dir Sorgen machst, dass es ein Problem ist, dass du den Code aus einem File generierst. Solange aber Inhalt identisch ist, gibt es kein Problem. Musst halt nur den Url-Parameter in deiner Client-Anwendung richtig setzen, bzw. in der Config die Endpoint-Definition richtig setzen.
Ruft ein WebService-Konsument das WSDL des benutzten WebService dynamisch ab?
Das ist der übliche Weg. Das erwartet VS auch, wenn man "Add Service Reference..." macht. Ansonsten muss man die WSDL (und ggf. Schema-Dateien) per Hand in wsdl.exe (ASP.NET-WS) bzw. svcutil.exe (WCF) stecken um die Client-Klassen generieren zu lassen.
Kann die Gegenstelle also ihren Methoden-Parameter vor dem eigentlichen Methoden-Aufruf gemäss jenem "aktuellen" WSDL validieren?
Im Standardfall macht WCF keine Validierung sondern verläßt sich darauf, dass der Proxy-Code sauber generiert wurde und die Gegenstelle auch SOAP gemäß der WSDL schickt.
Wenn du dieses Vertrauen in nicht hast, dann musst du WCF entsprechen erweitern (Beispiel für den Server):
Ist es irgendwie möglich, einen WebService-Request (oder besser gesagt dessen Parameter) vor dem Aufruf zu validieren? Braucht es dazu ein XSD oder funktioniert es auch mit einem WSDL?
Möglich wäre das natürlich, aber es gibt keine Bordmittel dafür. Das WSDL braucht es dafür. Dort sind entweder die Typendefinitionen bereits enthalten oder es wird ein Schema referenziert. Aber mir fällt dafür kein plausibler Anwendungsfall ein - außer man will den Codegenerator validieren.
Kann mir jemand erklären warum mit VisualStudio beim Hinzufügen einer WebReference die ganzen Typen-Beschränkungen wegoptimiert?
Das liegt schlicht und einfach am einfach gestrickten Codegenerator (im Prinzip der xsd.exe-Code). Aber dir steht natürlich frei, ein eigenen Codegenerator zu schreiben, der die Setter der Properties mit entsprechenden Prüfungen versieht. Wird dich aber ein gutes Stück Performance kosten...
Grundsätzlich ist das Schema-First-Design von WS in .NET stiefmütterlich.
Nimm doch reliable and secure raus.... nur mal so zum Test.
Beim Einsatz von WCF ist das empfehlenswert:
Könnte es sein dass da nen Proxy dazwischenhängt? Bad Request ist normalerweise keine übliche WCF-Fehlermeldung.
Ansonsten würde ich das erstmal mit einem normalen basicHttpBinding probieren.
Der Anwendungscode ist sicher nicht dafür verantwortlich. Die WLAN-Verbindung handelt der WLAN-Treiber aus und stellt dann den Netzwerkadapter zur Verfügung. Auf der Socket-Ebene sieht man nix von Verschlüsselung und Authentifizierung. Ich vermute mal stark, dass deine Verbindung gar nicht zustande kommt. Einfach mal mittels ipconfig-Tool prüfen.