Da müßtest du wohl erstmal Herrn Heijlsberg persönlich überzeugen, denn der denkt - wie ich finde zurecht:
Zitat
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.
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.
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.
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.
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.
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.
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.
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.