ist zwar unwahrscheinlich, aber ist das ein frisch installierter SAP GUI 7.50? Dann könnte einmal neustarten ausreichen. Das Ding hat nach der Installation ein paar Grafikfehler, die nach dem Neustart aber weg sind.

wenn die IT einem verbietet, die IP zu ändern, wird sie einem aus demselben Grund (versehentlich doppelt vergebene Adressen im internen Netz) auch verbieten, eine IP-Adresse per Kommandozeile zu vergeben.

Wenn die IP-Range, die man zusätzlich braucht, sich nie ändert, kann man die IT einfach bitten, einem ein Routing in diesen Adressbereich einzurichten. Dann klemmt man einfach den Controller ans interne Netz an und richtet ihn ein. Routing können auch schon Switche mit Management, dafür braucht man keinen expliziten Router. Am besten am Default-Gateway einrichten, dann muss man an den Clients gar nichts mehr machen.

Problem 1 (Editor) ist ne Bequemlichkeitssache, mit nem guten Xml-Editor ist das evtl. auch nicht unbedingt nötig. Eine UI für bestimmte XML-Dateien zu bauen, die die Datei öffnet, einen Dialog für ein paar Werte in der Datei anzeigt und dann die Änderungen darin speichert, ist nicht zu kompliziert umzusetzen. Man muss halt entweder was generisches bauen, was beliebige XML-Dateien editieren kann (= man baut sich einen Xml-Editor) oder man geht individuell auf spezifische Xml-Dateien ein, wie auch immer man die identifiziert.

Problem 2 ist eigentlich Softwareverteilung. Ob da jetzt die Software neu installiert werden soll oder nicht, eigentlich ist eine Änderung in der app.config gleich einem neuen Versionsstand der Software. Es gibt günstige oder auch kostenlose Softwareverteilungs-Lösungen, die einem das Problem abnehmen können. PDQ und WPKG setzen wir selber intern ein, um Software auszurollen. WPKG ist da sehr flexibel, PDQ sehr bequem. Alternativ könnte man ein Powershell-Skript schreiben, das alle Rechner in der Domäne (ohne Domäne wirds bei 30 Rechnern im Netzwerk etwas mühsam) auf eine installierte Anwendung abprüft und die Konfigurationsdatei austauscht, wenn sie sich unterscheidet. Wenn man das etwas feiner steuerbar machen möchte, hängt man alle zu prüfenden Rechner in eine AD-Gruppe und verarbeitet im Skript nur deren Mitglieder. Damit sind die Entwickler-Rechner auch aussen vor, denn die wollen sowas meist nicht automatisieren. Dann ändert man die zentral abgelegte app.config und das auf irgendeinem Server per Batch ausgeführte Skript erledigt alle 30 Minuten den Rest.

Linux selbst ist, wenn man Support haben möchte, sicher nicht groß günstiger als Windows. Ein SLES mit unlimited VM kostet nicht groß weniger als ein Windows Datacenter. Dafür hat man bei SLES gleich den Support für Postgres mit dabei. Und wenn man sich mal die Lizenzproblematik Oracle in virtuellen Umgebungen anschaut, will man von dem Setup eigentlich nur noch weg.

Administration unter Linux ist für Windows-Admins sicher nicht ganz ohne, aber es gibt für Unternehmen eigentlich keinen Grund, nicht zweigleisig zu fahren. Bei uns laufen die SAP-Systeme auf SLES, ein paar Webanwendungen ebenfalls, der Rest läuft mit Windows.

sowas würde ich mit WebAPI-Schnittstellen (selfhosted in deiner Anwendung) realisieren. Das lässt sich recht einfach in beiden Anwendungen isoliert testen (für GET reicht ein Browser, für POST kann man sowas wie Fiddler verwenden).

SAP Idocs sind Textdateien mit fester Länge und verschiedenen Satzarten. Zum Einlesen musst du die Satzarten kennen und wissen, welche Satzart welche Felder hat, wie lang diese sind und in welcher Reihenfolge die in der Zeile stehen. Im SAP-System kannst du die Idoc-Dokumentation u.a. über die Transaktion WE60 erhalten. In jedem Fall solltest du die Doku von deinem Auftraggeber erhalten.

EDIFACT ist auch ein Textformat, allerdings anders aufgebaut. Auch EDIFACT kennt Nachrichtenarten, Segmentarten und Semente, die Felder werden aber durch konfigurierbare Trennzeichen (üblicherweise "+" für Segmente und ":" für Felder innerhalb der Segmente) getrennt. Segmentarten werden durch das '-Zeichen getrennt. Eine ganz praktische Übersicht über die Nachrichtenarten und die dazugehörigen Inhalte gibts u.a. hier: http://www.stylusstudio.com/edifact/frames.htm . Die Standards werden von der UN (UNECE) festgelegt und können auch auf den Seiten der UNECE heruntergeladen werden (allerdings nicht sondern bequem).

Die Idocs wirst du Zeile für Zeile einlesen müssen. Ob du zuerst das ganze Idoc einliest und auswertest oder Satz für Satz direkt EDIFACT-Daten erzeugst, ist dir überlassen. Da man aber häufiger auch Daten über mehrere Datensätze (wie z.B. alle Rechnungspositionen mit einem bestimmten Steuersatz) in ein EDIFACT-Segment übergeben muss, macht es mehr Sinn, zuerst das gnaze Idoc einzulesen und in ein internes Format zu konvertieren, auf das du einfacher zugreifen kannst.

wobei es zwischen einem expliziten Dispose() und der Nutzung des FileStreams in einem using-Block eigentlich ja keinen Unterschied geben dürfte. using() ruft ja auch nur Dispose bei Verlassen des Blocks auf. Insofern hätte die ursprüngliche Lösung auch kein memoryleak erzeugen dürfen. Oder andersherum, das einzelne using() hätte ein evtl. vorhandenes Leak nicht beseitigen dürfen.

versuch doch mal, dein Programm solang laufen zu lassen, bis kein Speicher mehr übrig ist. Wenn du das schaffst, kannst du dich über nicht funktionierende Garbage Collection beschweren. Aber der GC räumt nicht immer gleich dann auf, wenn man es gerne hätte sondern oft erst dann, wenn er muss. Und von Hand aufrufen muss man ihn normalerweise auch nicht.

wenn man Methoden vollständig von Unit-Tests abdecken will, ändert man doch als erstes den Test und sorgt dann dafür, dass die Methode den Test wieder erfolgreich absolviert (TDD).

Mandantenfähigkeit kann man auch anders umsetzen. Eine technisch sehr einfache Variante, die z. B. die SAP in ihrem ERP-System nutzt, ist die Speicherung aller Datensätze mit einer Mandantennummer. Mandantenunabhängige Tabellen haben das Feld nicht, alle anderen Tabellen schon. Zugriffe auf mandantenabhängige Tabellen dürfen dann natürlich nur inklusive der Mandantennummer erfolgen. Damit das auch eingehalten wird, sollte man alle Zugriffe auf die Datenbank dann über ein Repository ausführen, das die Zugriffe entsprechend vornimmt.

in fast allen etwas größeren Projekten kommt für sowas ein Objektrelationaler Mapper (Entity Framework, NHibernate) zum Einsatz. Für den Transport zwischen Webservice und Webservice-Client werden üblicherweise Datentransferobjekte eingesetzt, so dass eine Änderung in der Datenbankstruktur nicht zwangsläufig eine Änderung in der Webservice-API bedeutet.

deine Klassenbezeichnungen sind etwas durcheinander. Du hast eine Klasse "Mitarbeiter", im Mapping verwendest du aber eine Klasse "Staffer". Und auch der Konstruktor in der Klasse "Mitarbeiter" deutet darauf hin, dass diese Klasse eigentlich "Staffer" heissen sollte. Wenn das tatsächlich so im Quellcode steht, würde ich erstmal das aufräumen. Ansonsten bitte den geposteten Quellcode korrigieren.

auch wenn mir dabei das Frühstück hochkommt, fällt mir zu dem Thema am ehesten eine Access-Datenbank ein.

ein Fehler ganz oben: im DataReceived-Event von sPort1 verwendest du denselben Eventhandler (sPort_DataReceived statt sPort1_DataReceived) wie für sPort. So soll das vermutlich aussehen:

sPort1.DataReceived += new SerialDataReceivedEventHandler
(sPort1_DataReceived);

am einfachsten kann man in solchen Fällen im Businesslayer eine eigene Initialisierung implementieren. Die muss dann nur bei der Initialisierung des Containers berücksichtigt werden. Du könntest z. B. ein eigenes Interface erstellen, das nur eine Init()-Methode mit dem erzeugten Container als Parameter entgegennimmt. Dann registrierst du die Implementierung(en, könnten ja mehrere sein) bei der Container-Initialisierung, lässt dir sofort eine Liste alle Implementierungen auflösen und rufst die Init()-Methode jeder Implementierung auf. Damit hat dein WebGUI-Projekt keinen direkten Verweis auf das DataAccess-Layer und kann trotzdem darin enthaltene Komponenten auflösen.

Wenn du jetzt auch im DataAccess-Layer eigene Interfaces und Komponenten hast, die du auch im Businesslayer nicht sehen kannst, kannst du dasselbe Spielchen auch mit dem DataAccess-Layer machen, indem du in der Initialisierung im Businesslayer auf dieselbe Art und Weise konstruierst.

der konkrete Fehler bei Android 4.2 war doch ein reines UI-Problem, bei dem ein Control falsch angesteuert wurde. Zuerst wurden Min- und Maxwerte gesetzt, danach wurde die Werteliste zugeordnet. Dabei wurde übersehen, dass das Zuordnen einer Werteliste die Min- und Maxwerte anscheinend auf den Index der Werteliste zurücksetzt.

Soweit ich weiss, geht das nicht, jeder Aufruf erfolgt in seinem eigenen Kontext. Man kann sich aber damit behelfen, einen SAP-Baustein zu bauen, der dieselben Eingangsparameter wie der eigentliche Funktionsaufruf hat und der am Ende den Commit-Baustein aufruft.

die Einstellungen werden in Konfigurationsdateien entweder pro User oder pro Anwendung (systemseitig also global) auf dem lokalen System abgelegt. Die ändern sich natürlich nicht, wenn du eine neue Version deiner Anwendung verteilst, sonst würden sich alle anwenderseitigen Einstellungen bei jedem Update ändern. Ich kann nur vermuten, dass du bei der Installation über dein Setup die Anwendungseinstellungen überschreibst und damit die neue Version hinterlegst, was beim manuellen Kopieren der Anwendung nicht passiert.

Fragt sich, warum du die Version der Anwendung, die ja abhängig von der Assembly ist, in eine Konfigurationsdatei legst? Warum rufst du nicht einfach direkt die aktuelle Version der Assembly ab?

warum überschreibst du setSize überhaupt, wenn die Implementierung sich nicht ändern soll?

abgesehen davon ginge das zum Beispiel so:

abstract class MyClass
{
   private int testWert = 2;

   public virtual float setSize()
        {
            float test = 7.5f;
            return test;
        }
}

class MyChild : MyClass
{
        public override float setSize()
        {
            float baseTest = base.setSize();
            return baseTest;
        }
}

was meinst du eigentlich mit "Variable zurücksetzen"? Eine "Variable" ist normalerweise ja was methodenlokales, was in dem Zusammenhang keinen Sinn machen würde.

es gibt eine Upgrade()-Funktion in den Settings.

ich erledige das so:

                if (Properties.Settings.Default.CallSettingsUpgrade)
                {
                    Properties.Settings.Default.Upgrade();
                    Properties.Settings.Default.CallSettingsUpgrade = false;
                }

CallSettingsUpgrade ist dabei ein Setting vom Typ Bool mit Standardwert "true". Daher ist das Setting nach einem Upgrade der Anwendung erstmal "true" und wird nach Upgrade der Settings auf "false" zurückgesetzt.

blöde Frage: warum ist es schlimm, wenn die Verarbeitung hin und wieder länger dauert? Muss eine Rückmeldung innerhalb der 150 ms irgendwohin erfolgen oder ist die Anwendung einfach nur nicht darauf ausgelegt, einen zweiten Aufgabensatz zu beginnen, wenn der erste noch nicht abgeschlossen ist?

mein eigentlicher Rechner ist nicht virtualisiert, weil ich zusätzlich noch virtuelle Maschinen in VMWare Workstation-Umgebungen neben meiner eigentlichen Installation nutze. Rechenleistung ist gar nicht so das Problem bei Virtualisierung, ich finde eher die Bedienung etwas träge. Und ich weiss nicht, wie weit die Citrix-Technik mittlerweile ist, aber vor einigen Jahren konnte man Videos (z. B. Ausschnitte der Entwicklerkonferenzen von MS) noch nicht über RDP oder Citrix schauen, ohne dass das heftig geruckelt hat.

vDesktops haben natürlich nette Vorteile. Regelmäßige Backups in der Nacht, Nebenbei-Betrieb mehrerer Maschinen für verschiedene Zwecke usw.

der FaultContract ist einfach Teil der Service-Schnittstelle. Man spezifiziert damit nicht nur das Format der Anfragen und Antworten, sondern auch das Format eventueller Ausnahmen, die im Dienst auftreten. Der Client muss diese ja auch verarbeiten können. Ein Entwickler kann aber, wenn er den Dienst nicht selber entwickelt hat, nicht vorhersehen, welche Ausnahmen er denn erwarten kann, also muss auch hier eine definierte Schnittstelle her, die zumindest den Informationsaustausch zwischen Dienst und Client standardisiert. Zudem ist der FaultContract eine gute Möglichkeit, Fehler im Dienst nicht nach aussen weiterzuleiten. Das ist auch ein potentieller Angriffspunkt.

Kann man machen, macht im Zweifelsfall aber Ärger. Ändert sich eine Bibliothek, muss ggf. jedes Projekt, das sie benutzt, angepackt werden. Besser ist es, Hilfsbibliotheken wie fremde Bibliotheken zu behandeln und mit Versionsnummern "auszuliefern" und dann diese in Projekten zu benutzen. Wenn es um möglichst einfaches Aktualisieren der Bibliotheken geht, würde ich ein lokales nuget-Repository auf einem Fileserver ablegen, in VS einbinden und dann darüber Updates beziehen, wenn sich an einer der Bibliotheken was ändert. So kann man updaten, wenn man will - und wenn man aus welchen Gründen grad nicht will, kann man das auch lassen. Mit dem Einbinden der Solution bin ich gezwungen, die aktuellste Version zu benutzen.

ich würd mal das Tracing in der web.config des WCF-Dienstes aktivieren und schauen, wo genau das Ding pausiert.

ich machs mir normalerweise etwas einfacher und baue die Transfermodels analog zu den Datenmodels auf, nur dass die Relationen größtenteils weggelassen werden. Da muss man AutoMapper dann nur noch anweisen, aus X bitte Y zu machen, wenn alle Eigenschaften gleich benannt und typisiert sind.

man sollte möglichst vermeiden, sein Datenmodell direkt per Webservice an Clients weiterzureichen. Zum einen sind Änderungen im Datenmodell dann auch immer gleich Änderungen am Service-Kontrakt, zum anderen sind die durch einen ORM relativ leicht zu managenden Relationen zwischen Objekten ein ziemliches Problem bei der Serialisierung. Von daher sollte man immer Datentransfer-Klassen (im Prinzip so, wie du es im Beispiel schon machst) erzeugen, die dann für diesen einen Zweck optimiert sind.

Zur Erzeugung der eigentlichen Objekte würde ich übrigens sowas wie AutoMapper empfehlen. Das Ding baut dir mit Hilfe einer simplen Konfiguration aus Klasse X eine Klasse Y. Aus deiner Datenklasse "User" kannst du im Idealfall mit nur einer Zeile deinen "EnterpriseUser" machen.

Danke für die Antwort,

Mir ist irgendein AD-Lite im Kopf, das hatte ich vor einigen Jahren mal irgendwo gelesen...

Ich denke, ich schmeiß mal meine VM an, damit ich das auf ein echtes AD testen kann.

du meinst AD LDS (Leightweight Directory Services). Das entspricht mehr oder weniger einem LDAP-Server. AD an sich kann ein bisschen mehr, unter Umständen ist der Unterschied für dich aber gar nicht so relevant.

AD-Anfragen sind LDAP-Anfragen relativ ähnlich. Ob die Anfragen vollständig kompatibel sind, weiss ich allerdings nicht. Für einen echten Integrationstest würde ich vermutlich eher einen richtigen Active Directory-Server aufsetzen und mit dem testen.

klar geht das. Nur muss man auch den Launcher und den Update-Mechanismus mitentwickeln. Das relativiert den Mehraufwand, den man im ersten Moment bei ASP.Net-Anwendungen vermutet.

im Unternehmen haben Winforms-Anwendungen durchaus ihre Nachteile. Aktualisierung ist da so ein Thema. Der Firefox, der sich selbst aktualisiert, macht das nämlich auch nur, wenn der Benutzer die entsprechenden Berechtigungen hat. Die hat ein Endanwender in einem Unternehmen aber nicht. Also bleibt Firefox 3.5 noch viele Jahre Firefox 3.5, bis die IT sich für eine Softwareupdate-Lösung entscheidet. Diesen Weg kann man dann natürlich auch für eigene Anwendungen gehen, aber das ist zusätzlicher Aufwand, der für die Webanwendung nicht nötig ist. Moderne Webanwendungen können zudem auch eine Web-API bereitstellen, über die man Daten in anderen Anwendungen nutzen kann. Ich mach mittlerweile auch relativ viel über Webanwendungen, eben weil ich mit Deployment und Wartung auf Clientsystemen nichts mehr zu tun hab. Und wenn mein Chef da was auf seinem iPad sehen möchte, ist das auch kein Problem.

Mit AutoPoco kann man Objekte regelbasiert erzeugen. Das Ding kann einem auch mal 10.000 Objekte erzeugen, wenn man die braucht. Mit entsprechend umfangreicher Regelung kann man damit vermutlich auch größere Konstrukte erzeugen.

da sollte UInt32.TryParse() funktionieren.

das funktioniert im groben so:

bei Registrierung wird der neue User in der Datenbank angelegt, aber noch als inaktiv gekennzeichnet. Dazu wird eine Aktivierungs-Id für diesen User in der Datenbank angelegt. Wird jetzt die Aktivierungsseite aufgerufen und eine Id als Parameter mitgegeben (eben dieses xyz.com/act?id=1234sonstwas), wird in der Datenbank nach dieser Id gesucht und der User, zu dem diese Id gehört, aktiviert. Man kann die Aktivierungsseite noch mit Captcha absichern, wenn man sich gegen Spambots wehren will. Meistens kann man sich das aber sparen, da Spambots ihre Accounts eh nie mit echten Mailadressen anlegen, daher auch nicht an den validen Aktivierungs-Code kommen können.

ganz grob ist das, was ihr da machen müsst, ein ziemlich böser Fix. Wenn ein Dienst Daten bereitstellt, muss der Client - in diesem Fall das SAP-System - entsprechend darauf vorbereitet sein, diese Daten auch verarbeiten zu können. Ihr wollt sozusagen reverse engineered ein bestimmtes Ergebnis aufgrund der Erwartungen des WS-Clients erzeugen, nicht umgekehrt den WS-Client an euren Service anpassen.

Für solche Fälle ist WCF vermutlich wirklich unpassend. Da wäre es vermutlich einfacher, eine ASP.Net MVC-Seite zu bauen, die mit einer einzelnen Route jeden Request auf einen Controller leitet, der dann das XML entgegennimmt und darauf reagiert. Das hat dann rein gar nichts mehr mit Webservices an sich zu tun, aber damit hättet ihr dann die manuelle Eingriffsmöglichkeit, die ihr wollt. Pflegen würde ich sowas aber nicht wollen...

hier ist glaub ich eher die SAP-Seite das Problem. Dass WCF Namespace-Deklarationen in seine Soap-Dokumente reinschreibt, gehört sich so. Wie wird denn dein WCF-Dienst vom SAP-System angesprochen? Wie wurde der Webservice-Client auf SAP-Seite erstellt? Ohne das WSDL von deinem WCF-Dienst kann man auf SAP-Seite ja noch gar nichts erstellen. Und mit dem WSDL sollte es auch keine Namespace-Probleme geben.

sowas wird eigentlich nie gebraucht. WCF ist ja gerade dazu da, sowas wegzuabstrahieren. Du benutzt ja auch keinen WCF-Client, sondern schickst den Request von Hand weg. Das Äquivalent auf Serverseite wäre, jeden HTTP-Request von Hand abzuwickeln, statt die WCF-Engine dafür zu benutzen.

an das rohe XML kommst du nur über Tracing. In einem WCF-Service kommen nur die Daten an, die vorher die Validierung überstanden haben. Wenn da schon was scheitert, würde ich als erstes das Tracing aktivieren und schauen, wo und warum genau das nicht funktioniert. Gerade bei SAP-Systemen kann das zum Beispiel ein Namespace-Problem bei der Deklaration deines Dienstes sein.

jupp, dafür ist HTTPS da.

MS hat mit ASP.Net versucht, Windows Forms ins Internet zu bringen, mit mäßigem Erfolg. Auf den ersten Blick und mit simplen Beispielen funktioniert es sogar, aber sobald man komplexe, dynamische Seiten aufbaut, wirds sehr viel komplizierter.

Ganz grob: HTTP ist statuslos. Nachdem der Webserver einen Request bearbeitet hat, werden die daran beteiligten Klassen aufgelöst und der Server vergisst alles, was er für diesen Request gemacht hat. Das betrifft sowohl HTTP-Get als auch Post. MS hat sich also den Viewstate ausgedacht, um eine Art Status in ein statusloses Protokoll reinzutricksen. Effekt ist halt, dass man in dem Moment, in dem man den von MS vorgegebenen (reichlich schmalen) Trampelpfad verlässt, mit der Machete allein im Dschungel steht und sich selbst darum kümmern muss, den Status von Request zu Request weiterzutransportieren.

das liegt daran, dass ein Postback nichts anderes als ein erneuter Aufruf der Seite ist - mit dem einzigen Unterschied, dass per POST noch ein paar Parameter mit übertragen werden können. Die Seite (und damit die Klasse, auf der die Seite basiert), wird komplett neu erzeugt, damit sind auch alle beim ersten Request vorgenommenen Änderungen, die nicht im Viewstate stecken, verloren.

In deinem Fall wirst du die Daten, die du nach dem Postback wieder benötigst, irgendwo ablegen müssen. Eine Variante ist die Ablage der Daten im Viewstate, dann musst du im Page_Initialization-Ereignis die Daten aus dem Viewstate zurückholen und die Klasse erzeugen, noch bevor das Page_Load-Ereignis aufgerufen wird.

Eine Referenz zum ASP.Net Page Lifecycle: http://msdn.microsoft.com/en-us/library/ms178472.aspx

Microsoft hätte wohl Probleme, den Begriff "Net" innerhalb der Informationstechnologie wirklich effektiv zu schützen. Da könnten sie genauso gut versuchen, den Begriff "Tool" zu schützen. Die TLD .net gibt es beispielsweise auch schon bedeutend länger als das Net-Framework.

Abgesehen davon ist MS das ganze vermutlich sogar sehr recht. Günstigere Werbung gibts ja kaum.

Stateless bezieht sich bei MVC wohl eher auf den nicht mehr vorhandenen ViewState. Sessiondaten kann man weiterhin in der Session ablegen. Ansonsten bliebe noch ein Cookie als Alternative. Man kann solche Daten natürlich auch in die Datenbank der Anwendung legen, aber das macht aus guten Grund kaum jemand. Ich würd ein Cookie benutzen, das dürfte die beliebteste Variante sein.

geht viel einfacher. Setz an der Stelle, an der die wechselnden Views auftauchen sollen, ein Panel auf das Form und erzeuge 4 UserControls, die du dann bei Bedarf in das Panel einsetzt.

so ein Projekt wär viel zu aufwändig, um es glaubhaft in 70 Stunden abzuwickeln. Zumindest, wenn es auch funktionieren soll. Du könntest das Projekt als ganzes umsetzen und nur einen Teil davon als Abschlussprojekt benutzen. Der Onlinezugriff von Kundenseite aus wäre zum Beispiel eine in sich geschlossene Funktion, die man in so einem Projekt umsetzen könnte.

kannst du mal schauen, ob die Datei denn auf dem Server überhaupt in UTF8 gelesen wird, der Umlaut nach Einlesen der Datei also noch im String enthalten ist? Kann sein, dass ReadAllText ASCII liest und schon da der Umlaut verloren geht.

SOAP-basierte Webservices sind nicht einfach nur irgendein XML, der Client erwartet schon ein Dokument nach einem ganz bestimmten Standard. Irgendein XML-Dokument würde am Client für Probleme sorgen. Das wäre kein Webservice, sondern einfach nur eine statisch ausgelieferte XML-Datei.

XML-Dateien und Binärdaten werden base64-codiert, damit sie nicht mit der XML-Syntax in einer SOAP-Nachricht kollidieren. Der Parser wär nicht in der Lage zu erkennen, was Nachrichtensyntax und was Inhalt ist. Base64-Codierung vergrößert die Nachricht zwar, codiert sie aber so, dass sie sicher über XML übertragen werden können. Auf Clientseite wird dann wieder von base64 zurückcodiert und die Daten sind in unveränderter Form angekommen.

Bzgl. Umlauten: soweit ich weiss, ist das bei XML so definiert, dass - ähnlich wie bei HTML - diverse Zeichen über Sonderzeichen codiert werden müssen. Wenn man das dann auf Empfängerseite wieder korrekt in ein XmlDocument umwandelt, sollte der Umlaut auch wieder da sein. Xml-Dateien mit String-Operationen zu bearbeiten ist so ziemlich der schlechteste und umständlichste Weg, sowas zu machen.

wenn du von "in einem virtualisierten System" redest, redest du von einer Sicherung, die von dem virtualisierten System selbst ausgeführt wird. Da so ein System dann irgendwie an das Bandlaufwerk herankommen muss und sowas normalerweise per SAS/SCSI passiert, würde das vermutlich nicht funktionieren - die VM hat keinen Zugriff auf einen echten SCSI-Controller.

Die Sicherung einer virtuellen Maschine auf Band ist andererseits kein Problem. Wir setzen HP Data Protector ein und sichern unsere vSphere-Umgebung direkt auf LTO4-Bänder in einer Bandbibliothek. Das Backup findet dann aber ausserhalb der virtuellen Umgebung statt, dafür bietet vSphere auch entsprechende APIs, damit Hersteller von Sicherungssystemen Snapshotsicherungen (mittlerweile auch differentiell oder inkrementell) durchführen können.

Edit: kleiner Nachtrag zu "direkt auf LTO4-Bänder in einer Bandbibliothek": die Bandbibliothek ist natürlich an einem Server angeschlossen, der nicht virtualisiert ist.

doch, wenn innerhalb der Methode DeQueue gelockt wird (und auch bei allen anderen Zugriffen auf die Queue), ist das threadsafe. Dann kann ich nur nicht erkennen, wozu der lock() in der DoWork() aus dem Anfangspost gut ist, wenn die Queue selbst threadsafe bearbeitet wird. Stört nicht, bringt aber (wenn ich nichts übersehe) auch nichts.

Wenn du einen Profiler zur Hand hast, könntest du den mal mitlaufen lassen und schauen, wo die meiste Zeit vergeht.

im Vergleich zu dem Beispiel in dem verlinkten Thread hast du hier natürlich zusätzlichen Overhead, der Verzögerungen mit sich bringt. Vor allem die Abarbeitung der Queue der beiden Threads, die so wie es im Beispiel aussieht, nicht threadsafe ist. Dazu ist für einen echten Vergleich auch wichtig, welche IO-Leistung das ausführende System aufbringen kann.