Forenbeiträge von svenson Ingesamt 8.746 Beiträge
Da müßtest du wohl erstmal Herrn Heijlsberg persönlich überzeugen, denn der denkt - wie ich finde zurecht:
The reason that const works in C++ is because you can cast it away
Angesichts solch grundlegender Abneigungen, scheinen technische Probleme wie Metadaten-const fast nebensächlich. Und wenn die Runtime const prüft, nutzt es eh keiner wegen der schlechten Performance.
So wie ich das sehe, sind das zwei völlig verschiedene Paar Schuhe. Die "Modelle", die man innerhalb eines C#-Projektes erzeugen kann, bieten ja praktisch kaum Funktionalität.
Ein Modelling Projekt scheint einem dagegen volle UML-Möglichkeiten zu geben. Der Prozess der Code-Erstellung ist also völlig anders. Und da T4 eigentlich immer nur für Forward-Engeneering genutzt wird, gehe ich davon aus, dass die Codegenerierung aus einem Modelling-Projekt eben nicht Roundtrip ist.
OpenNETCF hat mit der Klasse Monitor2 eine Reimplementierung im Angebot.
Schreibaufwand sollte kein Kriterium sein. Du solltest allerdings beachten, dass Webservices oftmals über langsame Netze (Internet) abgewickelt werden. Man sollte also die Granularität der Abfragen auch unter dem Gesichtspunkt der Datenmenge und damit der Geschwindigkeit betrachten.
Im Compact Framework sind die allermeisten Ressourcen ( in diesem Fall die Exception-Texte) in einem sprachabhängigen Assembly (SystemSR.dll) zusammengepackt. Diese ist standardmäßig nicht im SDK. Fehlt dieses Assembly, sieht man bei vielen Exceptions nur den Namen und diesen Text als Message.
Für die Entwicklung empfiehlt sich daher, diese DLL per Hand mit in das Ausführungsverzeichnis der Anwendung zu packen. Dummerweise bekommt man die DLL nicht so leicht. Ich habe sie mir per Hand und einem CAB-File-Entpacker aus der CF-Installation geprockelt.
Ansonsten: Verwende doch mal "" anstelle von "/".
Es liegt ziemlich sicher an der .NET-Implementierung selbst. Das betrifft nicht nur FTP, sondern auch andere Teile des Frameworks, die nicht gerade performanceoptimiert wurden. Gutes Beispiel sind die Klassen im Kompressions-Namespace. Die hinken ihren (managed) Konkurrenten teilweise um Faktoren hinterher.
Bei FTP kann es z.B. daran liegen, dass die erlaubte Blockgröße bei FTP nicht ausgereizt wird. Probier einfach mal ein paar Konkurrenten aus. Für FTP gibts ja so einige, auch kostenfrei.
Offensichtlich soll hier Out-Marshalling verwendet werden, versuche mal:
[DllImport("unithandle.dll", EntryPoint = "_ReadDetails@8")]
static extern System.Int32 ReadDetails(System.Int32 Number, [In, Out] Block block);
Mein kleiner Tipp für all diejenigen, die mit Unit-Tests anfangen möchten: Legt euch ein Tool für Code-Coverage zu. Es fördert den "sportlichen Ehrgeiz" (intrinsische Motivationen sind immer wichtig) und gibt einem das Gefühl, wann es "genug" ist.
Ich hab keines und werde mir sicher keines kaufen. Liegt aber primär daran, dass Mobilgeräte für mich generell uninteressant sind. Mein Handy liegt ständig unaufgeladen in der Ecke. Ich bin noch in der Zeit aufgewachsen als es keine Handys gab, daher fällt es mir leicht sich der Immer-und-überall-erreichbar-sein-Sucht zu entziehen. Ich nutze mein Handy nur, wenn ich längere Zeit unterwegs bin und dann selbst jemanden erreichen will. Ansonsten verlasse ich mich darauf, dass Leute ihre Verabredungen einhalten. Das Einzige was mich bewegen könnte, meine alte Krücke gegen ein neues Handy zu tauschen, wäre kostenlose offline-Navi, a la Ovi-Maps von Nokia. Dann aber in einem möglichst billigen Gerät. Internet-Zugang im Handy finde ich sekündar. Ich habe den ganzen Tag Interzugang (Arbeit, zuhause), das reicht mir.
"Erwartete Fehler" sollten eben keine Exceptions sein...
Du brauchst hier was asynchrones, also was mit "Rückruf", wenn die Batch-Bearbeitung fertig ist. Ich würde dir empfehlen unter der Haube von WCF MSMQ einzusetzen. Am besten kominiert mit "Reliable Messaging". Normales HTTP-Binding ist bei solchen Laufzeiten nicht angesagt. Ggf. Messaging über HTTP.
Da du dann eh asynchron bist kann du dann auch wieder mit PerCall arbeiten. Das skaliert dann auch ordentlich.
@svenson: Auch in dieser beziehung bin ich wohl zu grün hinter den Ohren ... wie würdest Du solche logs aufbauen ... überall einfach Punkte im Code setzten und diese in ein File schreiben? Oder mehrere Files mit Zeitstempel ...
Zeitstempel sind gut. Auch die ThreadID ist praktisch, vor allem wenn mehrere Threads die gleiche Methode parallel aufrufen. Dann bietet sich der Beginn und das Ende einer Funktion an, sowie Punkte vor und nach Synchronisationspunkten.
Wie immer bei Threading-Problemen: Logs, Logs, Logs....
Was ich beschrieb war der Weg für ASP.NET Webservice-Clients (deswegen deprecated). Wenn du einen ASP.NET WS-Client hast, muss das Einhängen des Checkers vor dem ersten WS-Aufruf - also vor der ersten Prüfung - erfolgen
Bei WCF sieht das ein wenig anders aus, ist aber konzeptionell im Prinzip identisch: Ein benutzerdefinierter Callback wird automatisch aufgerufen, wenn eine Zertifikatsprüfung stattfinden soll.
http://stackoverflow.com/questions/338385/how-do-i-tell-wcf-to-skip-verification-of-the-certificate
http://msdn.microsoft.com/en-us/library/aa354512.aspx
Ein wenig unschön bei der WCF-Methode ist die Tatsache, dass der HttpRequest nicht mehr als Parameter mitkommt.
Natürlich ist das "unsauber", denn letztlich akzeptierst du damit jeden Server. Konkret musst du eine eigene Zertifkatsprüfung implementieren.
Hier findest du etwas weiter unten ein gutes Beispiel:
http://blogs.x2line.com/al/articles/258.aspx
Der einfachste Fall besteht darin, wirklich nur auf certProblem == 0 zu prüfen. Dann wird wenigstens geprüft, ob das Zertifikat gültig ist und der Common Name der Server-URL entspricht.
Im o.g. Beispiel wird zusätzlich der Aussteller geprüft, d.h. das ist in etwas so, als wenn du beim Online-Banking prüfst, ob das Zertifikat wirklich von der Bank X stammt, weil da der korrekte Name drinsteht. Sofern die CA die Identität eines Zertifikatsantrages korrekt prüfen (was in der Vergangenheit leider nicht immer der Fall war), dann ist diese Angabe auch korrekt.
Das ist das CA-Zertifikat, also das Root. Dein Exchange-Server hat ermutlich ein eigenes. Wenn das Stamm-Zertifikat - wie unten angegeben - bereits installiert ist, dann musst du eigentlich nicht viel tun.
Wenn du vor einem WS-Aufruf einfach
ServicePointManager.CertificatePolicy = new TrustAllPolicy();
einfügst, sollte er verbinden. Du kannst (und solltest) dort eine eigene Zertifikatsprüfung unterbringen.
Sicher, dass du WCF und nicht ASP.NET machst? Ansonsten mal checken was WCF sendet (Fiddler oder WCF-Tracetool).
Hast denn mal überhaupt versucht den Dienst zu nutzen? Einfach mal als Service-Referenz einbinden. Wenn du auf 2.0 festgenagelt bist, dann halt als Web-Referenz.
Die von die angesprochenen Elemente sind über das "WS-I Basic Security Profile" vorgeschrieben. WCF setzt dieses Profil um. Bei ASP.NET musst du wohl noch die WSE 3.0-Erweiterung zusätzlich einbinden.
Deine Frage ist unklar: Ein HttpWebRequest hat erstmal mit SOAP gar nix zu tun. SOAP macht z.B. WCF oder auch WS mit ASP.NET. Bei WCF kannst du so gut wie alles manipulieren.
Wenn du dein SOAP per Hand baust und per HttpWebRequest losschickst, hast du sowieso alles in der Hand.
Da gibt es noch MaxArraySize und MaxStringContentLength. Darüberhinaus kann dein Problem auch beim Webserver liegen. Da i.d.R. eingehende Requests komplett gecached werden, ist die maximale Größe des Requests beschränkt. Default im IIS sind 4 MB.
Hier eine relativ aktuelle Diskussion zum Thema:
http://stackoverflow.com/questions/24216/resharper-vs-coderush
CodeRush punktet vor allem bei Templates und der leichten Erweiterbarkeit. Resharper eher bei der Formatierung und Codeanalyse.
Ich persönlich bin kein Riesenfreund von zuviel Schnickschnack, der mich am Tippen behindert (Stichwort "aggressives Anbieten"). Zudem vergesse ich ständig die Tastenkombinationen und nutze daher nur einen Bruchteil der Funktionen (meine Erfahrung mit Resharper).
Ich benutze jetzt das kostenlose CodeRush Xpress. Da fehlen zwar einige Refactorings, aber die wichtigsten sind dabei.
BTW: Für den DXCore von Coderush gibt es ein Plugin, welches zumindest Fehler durch eine gekringelte Linie unter dem betreffenden Code anzeigt. Sehr schön auch das Plugin, welches den vertikalen Scrollbar durch eine Miniaturanzeige des Codes mit Direkt-Navigation ersetzt. Ansonsten hab ich noch ein Plugin im Einsatz, welches Blockeinrückungen durch dünne, vertikale Linien kenntlich macht.
Mal probiert die Anwendung unter verschiedenen Accounts laufen zu lassen, ggf. als Admin? Gehe mal davon aus, dass die Ursache nicht in deinem Code, sondern auf der speziellen Maschine zu finden ist. Ist auf beiden Maschinen VS installiert?
Das kannst du knicken. Alles was TCP benutzt, erkennt Abbrüche immer nur dann, wenn Daten zum Empfänger gehen. Wenn TCP keine Bestätigung auf ein Paket bekommt, dann wird wiederholt. Das kann bis zu einer Minite dauern. Erst dann wird die Verbindung als abgebrochen erkannt. Bei Abstürzen sorgt normalerweise die Laufzeitumgebung bzw. das BS für den regulären Abbau des Sockets. Wenn du aber z.B. einen mobilen Client hast, der schlicht seine Verbindung zum Netzwerk verliert, dann ist Essig.
"Sicher" ist so ein Verfahren also grundsätzlich nicht. KeepAlive ist die einzige Rettung. Oder eben gleich davon ausgehen, dass die Verbindung nicht zuverlässig ist.
Meine Empfehlung bei Entwickler-Produkten ist immer, nur englische Versionen zu verwenden. Ansonsten reduziert sich die Zahl der potentiellen Hilfeseiten, die man über eine Suchmaschine findet, doch erheblich.
Die Frage die ich mir stelle:
Kann man mit einer guten Architektur nicht das gleiche erreichen?
Jedes Konzept hat seine Stärken und Schwächen. Und es gibt sicher Fälle, wo ein Grid schon aus theoretischer Sicht einem anderen Verfahren überlegen ist, z.B. weil weniger Daten üebr langsame Netze fliessen müssen. Kann man nur im Einzelfall entscheiden.
Ist vermutlich ein Problem fehlender Rechte für den Keystore. Tritt typischerweise bei nicht-interaktiven Accounts auf.
Probier mal vor der XML-Konvertierung:
rsa.PersistKeyInCsp = false;
Geht das nicht, baue dir ein RSA-Objekte über den RSACryptoServiceProvider-Konstruktor. Da dann LocalMachineStore angeben.
Ggf. muss man das auch über die CAS machen. Kann sein, dass die Rechte für den Key-Zugriff restriktiv sind.
Auch Microsoft hat was im Angebot: "M".
Fowler betrachtet das aus Integrationssicht. Objekte haben sich nicht als "Vehikel" für Daten zwischen Anwendungen bewährt. Solche "Spaces"-Gesichten machen aber u.U. Sinn, wenn man eine Anwendung "einfach" verteilen will.
Man setzt sowas ganz gerne ein, wenn man eine ausfallsichere Lösung haben möchte, die mit massig Live-Daten umgehen muss. Datenbanken zielen eher auf langfristige Speicherung und skalieren in einem solchen Szenario (Daten "leben" nur einige Minuten bis Stunden) schlecht.
Nachteil: Es ist sehr schwer zu beurteilen, warum sie denn doch nicht so gut skalieren wie erwartet.
Services erheben den Anspruch, vielfältig wiederverwenbar und orchestrierbar zu sein. Hier geht es eher darum, Unternehmensgrenzen zu überwinden. Aber in der Praxis findet man solche Anwendungen sehr selten, es sei denn, sie sind ausschließlich für den "öffentlichen" Gebrauch ausgelegt. Für Integration von Unternehmensanwendungen gelten andere Prioritäten, und da ist Fowler näher an der Praxis. Wenn du das mit .NET umsetzt, nimmst du eh WCF und da steht quasi sowieso "SOA" drauf. Also was solls: Alles nur Bullshit-Bingo...
Verwechsle immer Technologie mit Konzepten 😉
Das ist auch die Praxis. Die Leute, die "Konzepte" pushen, wollen ja i.d.R. auch Technologien verkaufen.
Nimm Fowlers Buch als das was es ist: Eine Anregung Unternehmensanwendungen auf eine bestimmte Art zu entwerfen und zu verzahnen, so dass sie besonderen Anforderungen genügen. Mit WCF hast du die Technologie an der Hand, das zu tun. Du kannst aber auch auf WCF verzichten und stattdessen irgendwelche ServiceBus-Geschichten veranstalten. Entscheidend ist m.E. nur eines: Entkopplung, technologisch (z.B. Plattform) und aus Service-Sicht (lose Bindung der Systeme, z.B. über formale Schnittstellenspezifikationen wie WSDL).
Der String wird per Default zu einem Pointer gemarshallt (char*), deswegen klappt das nicht. Du kannst aber den String so per Attribut auszeichnen, dass stattdessen ein Zeichenfeld (fester und bekannter Länge) in das Struct eingebettet wird:
public struct EventData
{
[MarshalAs(UnmanagedType.ByValTStr, SizeConst = 5)]
public string eventID1;
[MarshalAs(UnmanagedType.ByValTStr, SizeConst = 5)]
public string eventID2;
...
}
Aber Achtung: Bei ByValTStr wird keine automatische Nullterminierung vorgenommen...
Service-Objekt zu, neue Service-URL zusammenbauen, neues Service-Objekt erzeugen, darauf weiterarbeiten.
Fowler preist doch nur Messaging als _Technologie _ (oder Paradigma) für Anwendungsintegration. SOA ist hingegegen keine Technologie. Man kann SOA wunderbar mit Messaging machen, machen auch viele. Im Prinzip sind das orthogonale Begrifflichkeiten, die sich zwar berühren, aber doch unabhängig zu betrachten sind: Man kann Messaging ohne SOA machen und SOA ohne Messaging. Für SOA mit Messaging gibt es jedoch gute Gründe.
Mir würde es ganz sicher keinen Spass machen. VS2010 nutzt WPF... das braucht anständige HW-Beschleunigung für die Grafik, der Atom ist zu schwachbrüstig, 1 GB zu wenig. Und SW-Entwicklung auf kleinem Schirm ist m.E. ein No-Go, es sei denn man macht nur ein wenig Consolen-Anwendungen...
Generics sind zugegebenermaßen nicht so mächtig wie C++-Templates, aber den von dir geplanten Fall kannst du auch anders umsetzen, nämlich via ModuleBuilder.DefinePInvokeMethod(). Definiere dir die Methode zur Laufzeit in deine Anwendung. Der Nachteil sei aber nicht verschwiegen: So eine Methode kannst nur via Reflection aufrufen.
Wenn es nur darum geht zwei DLL-Varianten zu unterscheiden (z.B. für 32 und 64 bit), dann ist die simple Unterscheidung wie oben beschrieben deutlich einfacher.
Sollte zu beheben sein, indem man das Projekt auf .NET 3.5 umstellt. Aber ich entsinne mich dunkel, dass das die Express-Edition nicht beherrscht...
Suche mal nach "T4 Template". Vs2010 adressiert ein paar Probleme mit T4 und bietet nun sogenannte "Preprocessed Templates" an. Man muss aber leider sagen, dass das Thema T4 von MS etwas stiefmütterlich behandelt (dokumentiert) wird, obwohl es innerhalb von VS für viele Sachen eingesetzt wird (Stichwort DSL). Zumindest unter Vs2008 war es sehr schwierig eigene T4 Templates zu entwickeln - nicht weil T4 so schwierig wäre, sondern weil man die Templates nicht oder sehr schwierig bei der Arbeit debuggen könnte. Abhilfe schuf bisher nur ein kommerzieller T4-Editor.
Mit preprocessed templates habe ich allerdings noch nicht gearbeitet, kann gut sein, dass sich das hier ein wenig einfacher gestaltet. In VS2010 fehlt allerdings nach wie vor Intellisense.... der zweite große Wermutstropfen.
These: Jahreszahlen (int) reichen aus. Es wird wohl (mit einer Ausnahme (kein) historisches Datum geben, welches auf Monat und Tag dokumentiert ist. Ggf. halt Monat dazu. Knifflig wird eine Datumsimplementierung immer erst dann, wenn der Tag/Woche hinzukommt.
Aber der Java-Port sieht doch gut aus. Würde ich verwenden...
Macht das nicht VS2010?
Hier mal ein Beispiel, wie Binding-Settings Auswirkung auf die Policy-Section haben:
http://webservices20.blogspot.com/2008/10/interoperability-gotcha-sslcontexttoken.html
Stichwort ist "Windows CE Remote API (RAPI)".
Hier gibts nen .NET-Wrapper:
Ja, eine solche Möglichkeit gibt es:
XmlInclude ist die statische Variante. Es geht auch dynamisch, indem man die erlaubten Kind-Klassen im Konstruktor den XmlSerializers angibt. Kombiniert mit Reflection gibt das dann eine volldynamische LÖsung:
In der Regel tut man dies nicht direkt sondern über die jeweiligen Einstellungen der Bindings. Die werden dann von WCF automatisch für den WS-Policy-Abschnitt umgesetzt.
Ansonsten ist das der Weg:
http://blogs.msdn.com/ralph.squillace/archive/2006/07/26/679359.aspx
müsste also eine Art Sicherheitssystem eingebaut werden damit sich nur "richtige" Prozesse dort anmelden können die ich auch dafür autorisiere.
Spätestens jetzt sollte man merken: Lieber gleich auf eine Technologie setzen, die ohne großen Aufwand solche Leistungsmerkmale bereit stellt. Aber das Not-Invented-Here-Syndrom ist nunmal die Hauptkrankheit der Branche...
und es scheint nicht zu funktioniere.
Das ist so unspezifisch, dass man darauf nicht antworten kann. Vermutlich hat sich eben noch etwas anders geändert...
Ich nehme an das es SOAP da irgendwie eine Art Versionnummer mit überträgt...
Dem ist definitiv nicht so. Webservices sind genau mit diesem Gedanken gestrickt worden, dass die Bindung sehr lose ist, so dass solche Versionsprobleme möglichst ausgeschlossen sind.
Denn dann werden die Server wiederum zu Clients wodurch wir beim selben Problem angelangt sind.
- Server beissen nicht
- Server und Client sind nur _Rollen _in einer Kommunikations-Beziehung.
- Ob UDP oder TCP ist in diesem Kontext schnuppe, wer Daten als "Anfrage" empfängt ist per Definition ein Server.
P2P unterscheidet sich von dem klassischen Client-Server-Modell nur dadurch, dass es eben nicht nur _einen _Server gibt, sondern jeder Teilnehmer immer zugleich Client und Server ist.
Was du beschreibst ist also kein _Problem _sonden die Natur von P2P.
Zum Problem wird ein Server nur dann, wenn eine Firewall oder NAT die Funktion als Server verbietet.
Werden WM6-Geräte und dem Menü Tools/Options/Device Tools/Devices angezeigt?
Ich habe mal mit einem Sales-Mann einer Firma gesprochen, die große kommerzielle Lizenz-Lösungen anbieten. Dort kann man die Lizensierung undabhängig vom zusätzlich "Knack-Schutz" kaufen. Der sagte interessanterweise, dass nur 10% seiner Kunden sich für eine "sichere" Lösung entscheiden. Allerdings handelte es sich dabei auch um große kommerzielle Anwendungen, die i.d.R. nicht auf Crack-Seiten auftauchen. Dem normalen Business-Anwender werden wohl keine großen kriminellen Ambitionen zugetraut....