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.