Just a Code Team Blog

BizTalk Server 2009: The Microsoft Distributed Transaction Coordinator (MSDTC) may not be configured correctly.

2011-03-31T14:23:00.002+02:00

Sollte diese Fehlermeldung kommen, kann das auch an der (Microsoft) FireWall liegen. Einfach diese einmal deaktivieren und dann noch mal probieren.

"[SERVER]:[BizTalkRuleEngineDB]" associated with the deployment driver does not match the database ":" specified during product configuration.

2011-03-30T15:36:00.007+02:00

BizTalk MS Business Rule Composer Error beim Deployen einer Policie: The database "[SERVER]:BizTalkRuleEngineDB" associated with the deployment driver does not match the database ":" specified during product configuration.

Der Fehler hat vermutlich damit zu tun das beim Installieren nicht alle Angaben getätigt wurden weil man eventuell nicht alles intalliert hat. Sucht in Eurer "BizTalkMgmtDb" Datenbank nach den folgenden Tabellen: adm_Group, adm_OtherDatabases und adm_OtherBackupDatabases

Änderungen in der adm_Group Tabelle: Die Felder "RuleEngineDbServerName" und "RuleEngineDbName" suchen und füllen (Servername und Datenbankname der RuleEngine Datenbank).

Änderungen in den adm_OtherDatabases und adm_OtherBackupDatabases Tabellen: Fügt eine neue Zeile ein in der ihr im Feld "DefaultDatabaseName" den Datenbanknamen der RuleEngine eingebt und die anderen Felder mit den installationsspezifischen Informationen füllt.

VisualStudio2010 Express ISO

2010-06-16T09:57:00.005+02:00

Hier die Links zu den ISO Dateien für VS2010 auf der Microsoftseite. Die Einzelpakete lassen sich zwar über WebInstaller installieren, aber wenn man das auf mehreren Rechnern testen möchte ist das meines Erachtens etwas zu langwierig.

Englische Version

Deutsche Version

SAP .Net connector is not installed

2010-06-07T18:08:00.006+02:00

Nach langem suchen warum den der "SAP .Net connector" beim Zugriff über den SAP Adapter immer "not installed" ist, hat sich herausgestellt das die Fehlermeldung nichts mit dem eigentlichen Problem zu tun hatte. Hintergrund war das man Sourcen von einem bereits existierenden BizTalk-System auf ein neu eingerichtetes BizTalk-System kopiert hatte und da man den SAP Adapter 2.0 brauchte wurde dann nachträglich der "SAP .Net connector" und der "SAP Adapter 2.0" installiert.

Da aber zur Designtime aus VisualStudio heraus normalerweisse die benötigten RFC-Baustein Schemas aus SAP importiert werden und VisualStudio dabei für jedes dieser RFC-Bausteine eine DLL in SAP Adapter Unterverzeichnis "Bin" (z.b. C:\Program Files (x86)\Microsoft BizTalk Adapter v2.0 for mySAP Business Suite\Bin\ ) anlegt, fehlten diese natürlich.

Problemlösung: Entweder die DLLs aus dem alten System in das neue kopieren (sollte funktionieren) oder aber die SAP-Schemas noch einmal aus VisualStudio heraus importieren (und wie immer HostInstance neu starten nicht vergessen ;) ).

BizTalk 2006 R2 oder nicht R2?

2010-05-06T10:07:00.003+02:00

Wie Lösungen von trivialen Fragen in langwieriges Suchen ausarten können... "Wie ist auf die Schnelle herauszufinden ob ein BizTalk 2006 System, ein R2 Release ist?"

Es findet sich kein R2 Logo, kein Hinweis in den Add/Remove Programm Options, oder sonst etwas... WCF Adapter / RFID? Und wenn das nicht mitinstalliert wurde? Als einzigen verlässlichen Hinweis fand sich nur die Versionsnummer:

BizTalk Server 2006 Adminitration Console -> Menü "Help" -> "About Microsoft BizTalk Server Administration":

- 3.5.1602.0 = BizTalk 2006
- 3.6.1404.0 = BizTalk 2006 R2

Mal sehen wie weit das noch von diversen Patches beeinflusst wird...

BizTalk 2009, 64Bit und Custom Adapter (Wow6432Node Registry)

2010-03-10T10:34:00.005+01:00

Wir haben einen eigenen Adapter für BizTalk geschrieben und bisher funktionierte dieser auch tadellos auch unter Windows 2008 64Bit. Nun hatten wir das Problem, das dieser Adapter nicht gefunden wurde bei einer Kundeninstallation, auch Windows 2008 64Bit.

Mit Process Monitor habe ich herausgefunden, das auf unserem Referenzsystem BizTalk 2009 die Adaptoren in der 32Bit Registry sucht (Wow6432Node). Bei dem Kundensystem war der Adapter dort nicht registriert, lediglich in der 64Bit Registry. Den Knoten habe ich dann herausexportiert und dann lediglich den Wow6432Node im Pfad ergänzt und wieder neu importiert in die Registry:

HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\...

wird zu:

HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Wow6432Node\CLSID

Und schon wurde der Adapter im BizTalk gefunden

Was mich irritiert ist, wieso wird unser dazugehöriges Registry File auf unserem Referenzsystem korrekt in den 32Bit Knoten importiert und auf dem Kundensystem nicht? Der Mechanismus dazu ist mir nicht wirklich klar.

Zum Hintergrund es gibt zwei Regedt32.exe. Eine ist für 64Bit Zugriffe zuständig und liegt (verwirrender Weise) im %windir%\System32 Verzeichnis. Das Regedt32.exe für den 32Bit Zugriff wiederum liegt im %windir%\SysWow64 Verzeichnis. Ein Ausführen des Registry Files explizit mit dieser führte zu keinem Ergebnis, lieferte allerdings auch keinen Fehler zurück...

Unter 64Bit ist der Registry Zugriff schon etwas verwirrend, aber prinzipiell logisch:
- x86 Appliktaion, 32Bit Platform: Zugriff auf 32Bit Registry
- x86 Applikation, 64Bit Platform: Zugriff auf 32Bit Registry (Wow6432Node)
- x64 Applikation, 32Bit Platform: geht nicht
- x64 Applikation, 64Bit Platform: Zugriff auf 64Bit Registry
- AnyCPU Applikation, 32Bit Platform: Zugriff auf 32Bit Registry
- AnyCPU Applikation, 64Bit Platform: Zugriff auf 64Bit Registry

Um auf die jeweilige nicht Standard Registry vom Programmcode zuzugreifen (Alternate Registry View) muss man dann mit RegOpenKeyEx arbeiten: http://msdn.microsoft.com/en-us/library/ms724897(VS.85).aspx (habe dazu dieses Example gefunden)

BizTalk 2006 BAM EventBus Service Error Event

2010-03-03T10:51:00.005+01:00

Fehlermeldung im BizTalk Application Event Log:

Event Type: Error
Event Source: BAM EventBus Service
Event Category: None
Event ID: 25
Date: 3/1/2010
Time: 6:44:58 PM
User: N/A
Computer: BES086.comlineag.cl.local
Description:
Either another TDDS is processing the same data or there is an orphaned session in SQL server holding TDDS lock.Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding. SQLServer: BES082, Database: BizTalkDTADb.

Das Problem mit Lösungsvorschlägen ist beschrieben unter
http://support.microsoft.com/kb/841334 (Error Description dazu beachten)

In meinem Fall war die Lösung zu verwaisten Sessions angebracht:
http://msdn.microsoft.com/en-us/library/aa275788(SQL.80).aspx

Die Kurzfassung zur Lösung:

mit der Management Konsole sich auf die BizTalk SQL DB verbinden und exec sp_who als Query ausführen. Das listet die gegenwärtig Session mit ihrem jeweiligen Status und der jeweiligen spid auf. Die 'sa' Sessions interessieren nicht, alle anderen Sessions (bis auf die eigene) kann man dann gegebenenfalls mit dem kill Befehl abschießen (kill <spid>)

Dabei sollte natürlich sichergestellt sein, das der BizTalk in der Zeit nicht auf das System zugreift, bzw. ein anderer User Remote auf dem System arbeitet ;)

BizTalk 2009, SAP Adapter 2.0 und Windows 2008 (32Bit)

2010-03-01T10:30:00.014+01:00

Der alte (d.h. nicht WCF) Microsoft SAP Adapter unter Windows 2008 (32Bit) in Verbindung mit BizTalk 2009 kann ganz schön bockig sein...

Als erstes müssen folgende Vorraussetzungen erfüllt sein, damit der Adapter überhaupt funktioniert (unabhängig von BizTalk Version und Betriebssystem):
1. Installation der SAP eigenen DLLs, enthalten im SAP Frontend Package
2. Installation des Microsoft SAP .NET Connectors 1.0.3 (!Nicht 2.0!)
3. Installation des Microsoft BizTalk Adapter 2.0 for MySAP SP1 (unbedingt die SP 1 Version)
und das muss zudem in genau dieser Reihenfolge passieren!

Dann sollte man in einer restriktiven Umgebung unbedingt abprüfen, ob der SAP Adapter seine Datenbanktabelle und Stored Procedures angelegt hat:
1. In der Datenbank BizTalkMsgBoxDb muss eine SAPTid Table angelegt worden sein
2. Zudem müssen in der gleichen Datenbank folgende Stored Procedures existieren:
mp_sap_check_tid
mp_sap_delete_tid
mp_sap_insert_tid

sollte das nicht der Fall sein, muss mit einem geeigneten User nochmals die BizTalkSAPConfig.exe über Kommandozeile mit /i aufgerufen werden. Diese ist recht schweigsam und meldet sich nur im Fehlerfall mit einem Error Fenster.

Ist das geschehen muss sichergestellt sein, das Execution Rechte des BizTalk Users in der Datenbank auf vom SAP Adapter angelegten Stored Procedures existieren (BTS_HOST_USERS)

Ist das alles geschehen sollten zumindestens die RFC Aufrufe reibungslos passieren, sowie das Abrufen der Schemas für IDOCs und BAPI Bausteine funktionieren.

Was uns dann noch Kopfzerbrechen bereitete war, das IDOCs nicht empfangen werden konnten. Im SAP wurde unter der Transaktion SM58 ein "TARGET_METHOD_EXCEPTION raised by external server" Fehler zurückgemeldet. Unter BizTalk passierte gar nichts. Keine Fehlermeldung und keine sonstigen Einträge z.B. im Eventlog.

Nach einer Studie der Logs mit dem Process Monitor von Microsoft kam mir die Vermutung das BizTalk seine "Microsoft.BizTalk.SAPAdapterProperties.dll" nicht finden kann. D.h. er findet sie schon, allerdings sucht er sie zuerst immer im GAC_32, obwohl er seinen Adapter später im GAC findet, scheint dies trotzdem im weiteren Verlauf zu Problemen zu führen (z.B. unzählige Buffer Overflows, in den Pipeline Komponenten)

Als Problemlösung habe ich die "Microsoft.BizTalk.SAPAdapterProperties.dll" schlichtweg in den Ressourcen meines BizTalk 2009 Projekt referenziert (so wie ich es schon früher bei diesem Problem getan habe: http://justacodeblog.blogspot.com/2008/09/biztalk-und-sap-adapter-error.html). Danach funktionierte der IDOC Empfang wieder reibungslos. Ich vermute es reicht auch aus, die SAP Adapter Installation einfach vom GAC ins GAC_32 Verzeichnis manuell zu verschieben.

Nachtrag: Der Fehler TARGET_METHOD_EXCEPTION raised by external server tritt auch auf wenn das aus SAP abgerufene Schema nicht auf dem aktuellsten Stand ist.

BizTalk 2009 Issues unter VS2008

2010-02-09T11:07:00.006+01:00

Seit wir mit BizTalk 2009 unter Visual Studio 2008 entwickeln, haben wir immer wieder heftige Probleme mit referenzierten Projekten. Und zwar vornehmlich dann, wenn sich diese innerhalb der gleichen Solution befinden. Nach unseren letzten Problemen hab ich mich auf die Suche gemacht und Blogeinträge mit den gleichen Erfahrungen gefunden:

http://dotnet.org.za/ryancrawcour/archive/2009/07/17/biztalk-2009-amp-visual-studio-2008-annoyance-2.aspx http://blog.eliasen.dk/2009/07/21/IssuesWithBizTalk2009OnVSNET2008.aspx

Und nun die gute Nachricht: Es gibt seit Dezember doch tatsächlich einen Hotfix dafür :)
http://support.microsoft.com/kb/977428/en-us

BizTalk dynamischer Sendport - uninitialized dynamic port

2010-01-22T15:35:00.003+01:00

Beim kompilieren eines BizTalk Projektes unter VS2008 mit einem dynamischen Send Port, bekam ich die Fehlermeldung "uninitialized dynamic port"

Eine google Recherche ergab, dass dies auf das nicht gesetztes Property des Send Ports Microsoft.XLANGs.BaseTypes.Address hinweist. Das dumme nur war es ist gesetzt gewesen, aber in der falschen (!) Reihenfolge.

Zuerst hatte ich nämlich das Property Microsoft.XLANGs.BaseTypes.TransportType gesetzt und dann Microsoft.XLANGs.BaseTypes.Address.

Also:
myDynamicSendPort(Microsoft.XLANGs.BaseTypes.TransportType) = "My Type" myDynamicSendPort(Microsoft.XLANGs.BaseTypes.Address) = "My UNC"

-> build failed: uninitialized dynamic port

Aber:

myDynamicSendPort(Microsoft.XLANGs.BaseTypes.Address) = "My UNC" myDynamicSendPort(Microsoft.XLANGs.BaseTypes.TransportType) = "My Type"

-> build succeded

...its not a bug, its a feature :P

Bool-Shit

2009-10-05T16:58:00.001+02:00

if (request.getParameter("x") != null && ( (String) request.getParameter("x")).equalsIgnoreCase("1") || request.getParameter("x") == null ) {[...]}

java.lang.NoSuchMethodError: java/lang/String.isEmpty()Z

2009-09-15T07:50:00.003+02:00

Die Methode String.isEmpty() ist (wie in der JavaDoc unschwer ersichtlich) zwar erst ab Java 1.6 verfügbar, dennoch ist es möglich, Programme mit Compiler compliance level 1.5 (bei einem 1.6er JDK) zu compilieren, ohne dass der Compiler die Methode ankreidet. Erst beim versuch, die Methode in einer Umgebung mit Java 5 laufen zu lassen äußert sich der Fehler durch die, in der Überschrift genannte Exception. Sollte man also nicht 100%ig sicher sein, welche JRE auf der Zielumgebung läuft so ist weiterhin das gute alte .equals("") bzw. das ab prüfen über die Länge die sicherere Variante.

Anwendung nicht im Alt + Tab - Fenster anzeigen

2009-07-31T10:32:00.002+02:00

Manches mal hat man die Anforderung, dass eine Applikation nicht in dem Fenster angezeigt werden soll, das aktiv wird, wenn man die Tastenkombination Alt + Tab verwendet, um zwischen den laufenden Applikationen umzuschalten.

Eine kurze, prägnante und gute Anleitung dazu ist mir unter http://www.csharp411.com/hide-form-from-alttab/ über den Weg gelaufen. Das soll hier einfach mal für den Fall vermerkt werden, dass ich mal in die Verlegenheit kommen sollte. Zudem hilft es ja vielleicht auch dem ein oder anderen weiter.

MSDN Webcast

2009-07-14T15:14:00.002+02:00

Da mittlerweile stattliche 750 MSDN-Webcasts abrufbar sind, wollte ich darauf einmal aufmerksam machen falls es jemand noch nicht kennen sollte :) MSDN-Webcasts

Microsoft Message Queue MSMQ

2009-07-07T10:09:00.031+02:00

Vor einigen Wochen habe ich einen Crashkurs innerhalb weniger Stunden in Sachen MSMQ durchlaufen müssen, an dessen Ende eine Biztalk Lösung stand. Da ich auf einige Hindernisse gestoßen war, fasse ich mal meine Erfahrungen zusammen.

Kurz gesagt, MQ dient der asynchronen Kommunikation zweier Applikationen. Und das auch über Rechnergrenzen, oder gar Domänengrenzen hinweg. Dazu legt nach dem FIFO Prinzip eine Anwendung auf ihrem System Nachrichten ab, und eine andere lauscht auf die Adresse und greift die Nachricht ab. MSMQ kann sich dabei verschiedener Kommunikations Protokolle bedienen. (engl. Einführung in MSMQ)

MSMQ unterstützt gegenwärtig drei Queue Typen:
- Public Queues (benötigt Active Directory, Adressen werden dort direkt veröffentlich und sind von allen in der selben AD erreichbar, bzw. über Domängrenzen über Replikation)
- Private Queues (benötigt kein AD, die Adresse muss der empfangenden Anwendung daher aber auch bekannt sein, selbst mit AD!)
- Transaktions Queues (Sicherheit verbunden mit hohen Overhead Kosten)

Zum Entwickeln empfehlen sich Hilfstools, denn das größte Problem meines Erachtens (eigentlich das Einzige das ich hatte) ist die Kommunikationsinfrastruktur zu konfigurieren, solange man nicht eine sehr simple Netzwerkstrutur vor sich hat.

Zu einem gibt es dafür von MS das MQBench Paket und dann noch von Cogin ein freies MSMQ First Aid Kit.

Im bin Verzeichnis von MQBench gibt es 2 Tools: MSMQRecv bzw. MSMQSend, mit denen man über die Kommandozeile das Empfangen und Senden testen kann. Zum Vorgehen empfiehlt es sich zuerst einmal lokal zu testen, ob die MQ korrekt eingerichtet wurde. Funktioniert das, kann man zum eigentlichen Empfangsrechner über gehen der die Messages später abgreifen soll. Diese Tools haben aber einen Nachteil, sie unterstützen nur den Typ Public Queue, da sie nur das Pathnamen Format beherrschen. Aber der Pathname MUSS im AD nachgeschlagen werden, sobald es über Rechnergrenzen hinweg geht, d.h. Lokal funktionieren Pathnamen auch wunderbar mit Privat Queues!

Beispiel lokaler(!) Zugriff auf private MQ:
msmqrecv .\private$\MeineTestNachrichten

Remote Zugriff:
msmqrecv <rechnername>\private$\MeineTestNachrichten
-> Error: 0xc00e0003 (= Queue Not Found)
(geht nicht, Path wurde nicht in AD publiziert, da privat!)

Anmerkung: ein Versuch das ganze mit einem Formatname anstatt Pathname aufzurufen führt zu einem 0xc00e0014 (= Illegal Queue Pathname), die Tools können nur Pathname!

Das selbe gilt leider auch für das FirstAidKit!

Wie aber Eingangs erwähnt, unterstützt MSMQ unterschiedliche Kommunikationprotokolle, wie z.B. TCP. Dadurch hat man also die Möglichkeit ohne AD Lookup direkt auf die MQ eines anderen Rechners zuzugreifen. Um aber den Protokoll Zugriff beschreiben zu können, benötigt man das Direct Format Name Format. Da ich kein freies Tool kenne das einem das abnimmt, hab ich mir kurzerhand was in .NET zusammengecoded.

(Eine Anmerkung zum MSMQ Biztalk Adapter, dieser unterstützt das "Direct Format Name" Format ebenfalls von Haus aus.)

Unter System.Messaging gibt es im .NET Framework das richtige Werkzeug dazu:

...

MessageQueue mq = null;

bool cr = false;

string strFormatnameaddress = @"FormatName:DIRECT=TCP:192.168.1.114\test";

try

   msg.Priority = MessagePriority.Normal;

   mq = new MessageQueue(strFormatnameaddress);

   cr = mq.CanRead;

catch (System.Messaging.MessageQueueException ex)

   Console.WriteLine("MSMQ Error: " + ex.ToString());

catch (Exception ex)

   Console.WriteLine("Error: " + ex.ToString());

finally

   mq.Close();

return cr;

...

Das CanRead Flag gibt uns auf jeden Fall Informationen dazu, ob wir nun überhaupt auf die MQ zugreifen können, oder nicht. Jedenfalls ist die Programmierung sehr simpel, das gilt auch für das empfangen, bzw. senden von Messages:

...

// empfang aller Messages in der MQ

Message[] msgs = mq.GetAllMessages();

...

// senden einer Message in die MQ

Message msg = new Message();

msg.Label = "Test Message";

msg.Body = "Das ist nur ein Test";

mq.Send(msg);

...

Das eigentliche Problem fängt nun da an, wenn man keinen Zugriff auf die Message Queue bekommt. Das läßt sich in der Regel auf Security Einstellungen zurückführen. Was kein großes Problem ist, solange man sich am gleichen AD befindet und man über den Pathnamen zugreifen will (Es reicht in der Regel dem User des lesenden Rechners einfach die Zugriffsrechte auf die MQ zu gewähren, notfalls den Anonymus Access erlauben). Befindet man sich in unterschiedlichen AD (aber noch unter dem gleichen Forrest) benötigt man eigentlich nur noch zusätzlich eine funktionierende AD Replikation für den Pathnamen Zugriff. Ansonsten sollte in der Regel der Direct Format Name Zugriff funktionieren.

Was aber wenn sich die Rechner in unterschiedlichen Forrests befinden? Die unterschiedlichen Forrests müßen sich diese Vertrauen, und das bedeutet entweder Zertifikate, oder die "Umsonst"-Variante: ein Loch in die "Mauer schlagen". Dazu benötigt es nicht viel mehr als eines zusätzlichen Eintrages in die Registry des MQ Servers:
http://msdn.microsoft.com/en-us/library/cc236138(PROT.10).aspx
1.) HKLM\Software\Microsoft\MSMQ\Parameters\security\NewRemoteReadServerAllowNoneSecurityClient dword = 1
2.) Zugriffsrechte für Anonymus

Das gibt dem Admin sicherlich richtige Magenschmerzen ;)

Dazu hat John Breakwell von Microsoft, der einem auch bei einem Microsoft Call Support leistet, ein ausführliches Blog verfasst. Folgende Einträge beschäftigen sich mit MSMQ und Rechnern in unterschiedlichen Forrests: http://blogs.msdn.com/johnbreakwell/archive/2008/02/14/how-do-i-send-msmq-messages-between-domains.aspx http://blogs.msdn.com/johnbreakwell/archive/2008/06/27/cross-forest-msmq-you-need-to-be-trusting.aspx http://blogs.msdn.com/johnbreakwell/archive/2008/10/13/authenticating-msmq-messages-between-forests.aspx

BizTalk SAP Adapter 2.0 - IDOC Unknown Segment

2009-05-06T11:26:00.006+02:00

Beim abrufen eines IDOCs unter BizTalk 2006 mit dem BizTalk Adapter 2.0 erhielt ich die Fehlermeldung:

The schema generation encountered the following error(s):

1. Error occured while generating schema for: xxxx

Error returned: SEGMENT_UNKNOWN

Die Problemursache war, dass nicht alle Segmente in SAP released waren.

http://www.tech-archive.net/Archive/BizTalk/microsoft.public.biztalk.general/2005-02/0693.html

Versionskontrolle mit VisualSVN & AnkhSVN

2009-01-19T21:35:00.000+01:00

Versionskontrolle ist sicherlich für jeden Entwickler ein Thema, vor allem natürlich im beruflichen Umfeld. Doch auch für die private Entwicklung ist sie ein Thema, denn auch hier möchte der Entwickler nicht auf die Sicherheit verzichten, die eine Versionskontrolle bietet. Nicht umsonst ist der Einsatz eines Versionskontrollsystems bereits für den ersten, den Roten Grad im Wertesystem der Clean Code Developer vorgesehen.

Aus genannten Gründen habe ich mich mit eben diesen Systemen auseinandergesetzt und mich letztlich für eine Kombination aus VisualSVN als Server und AnkhSVN als Visual Studio-AddIn entschieden. Dass beide kostenlos verwendet werden können, hat dabei natürlich auch eine Rolle gespielt.

Obwohl sich Installation, Einrichtung und Verwendung als denkbar einfach erweisen, möchte ich hier eine kleine Hilfe für den Einstieg bieten, die eventuell auch für Unentschlossene als kleine Entscheidungshilfe dienen kann.

Installation

Nachdem die beiden Installationsdateien für VisualSVN und AnkhSVN, die jeweils nur etwa 3 MB klein sind, heruntergeladen wurden, kann mit der Installation des Subversion-Servers begonnen werden. Man startet also zunächst die Installation von VisualSVN.

Die Installation gestaltet sich dabei als einfach. Lediglich in einem Fenster müssen Entscheidungen getroffen werden, die der Konfiguration des Servers dienen.

Neben dem Installationsverzeichnis kann hier das Verzeichnis gewählt werden, in dem später die Repositories des Servers abgelegt werden.
Auch kann man den zu verwendenden Port einstellen und wählen, ob eine sichere Verbindung via https:// verwendet werden soll, um eine Verbindung mit dem Server herzustellen.
Schlussendlich bleibt noch die Wahl, ob man für den Zugriff separate Subversion-Benutzer verwenden möchte oder lieber die bereits existierenden Windows-Benutzer.

Der nebenstehende Screenshot zeigt die Standardeinstellungen, die ich für meine Installation auch so belassen werde.

Damit ist die Installation des Servers auch bereits abgeschlossen und er ist damit funktionstüchtig. Bevor wir uns jedoch genauer damit auseinandersetzen, installieren wir zunächst noch das Visual Studio-AddIn AnkhSVN, das uns als Client dienen wird. Diese beschränkt sich auf das Starten der Installation plus mehrmaliges “Weiter”-Klicken, daher gehe ich darauf nicht näher ein.

Konfiguration & Einrichtung

Nach erfolgreicher Installation starten wir zunächst den VisualSVN Server Explorer, den im Startmenü gefunden werden kann. Dieser dient der Verwaltung des Subversion-Servers. Hier werden beispielsweise Benutzer und Repositories angelegt, mit denen Subversion arbeitet. Auch kann hier der Server gestoppt und gestartet werden.

Diese grundlegenden Einstellungen kann man direkt vom Startbildschirm aus treffen.
Wurde als Authentifizierungsmethode die Subversion-Authentifizierung gewählt, sollte zunächst ein Benutzer erstellt werden.
Anschließend wird noch ein Repository angelegt und schon ist die grundlegende Einrichtung erledigt und der Server einsatzbereit.

Bevor wir jetzt allerdings unser erstes Projekt unter Versionskontrolle stellen, möchte ich noch zeigen, wie man die Verwendung von Keywords bzw. Properties aktivieren kann.
Diese werden zur sogenannten Keyword Substitution benötigt. Dabei handelt es sich um die dynamische Ersetzung bestimmter Schlüsselwörter durch deren Werte innerhalb der Quelldatei. So kann man beispielsweise im Header der Quelldatei eine Übersicht realisieren, welcher Benutzer eine Datei zuletzt eingecheckt hat und wann dies geschehen ist.

Um Keywords zu aktivieren, navigieren wir zunächst zum Konfigurations-Verzeichnis des Subversion-Servers, der unter Windows XP unter “C:\Dokumente und Einstellungen\<Benutzername>\Anwendungsdaten\Subversion” zu finden ist. Dort öffnen wir die Datei “config” mit einem beliebigen Editor.
In der Sektion [miscellany] muss zunächst die Zeile enable-auto-props = yes einkommentiert werden. Hierzu wird einfach die vorangestellte Raute entfernt.
Anschließend muss in der Sektion [auto-props] noch ein Eintrag für jede Datei-Art eingefügt werden, für die Keywords aktiviert werden sollen. Für C#-Quelldateien sieht der Eintrag folgendermaßen aus:

*.cs = svn:keywords=HeadURL LastChangedBy LastChangedRevision LastChangedDate Id

Wie hier zu sehen gibt es fünf Keywords, die aktiviert werden können. Diese haben teilweise noch Alias-Namen, die stattdessen verwendet werden können.
Um mehr über die Keywords und die Keyword Substitution an sich zu erfahren, kann unter http://svnbook.red-bean.com/en/1.4/svn.advanced.props.special.keywords.html nachgelesen werden.

Wichtig:
Soll Keyword Substitution verwendet werden, muss das beschriebene durchgeführt werden, bevor das Projekt , in dem sie verwendet werden soll, unter Source-Control gestellt wird.

Verwendung

Nun, da alles eingerichtet ist, können wir endlich dazu übergehen, unsere Subversion-Installation zu verwenden.

Wird jetzt in Visual Studio ein neues Projekt angelegt, zeigt sich eine Checkbox, die zuvor nicht verfügbar war. Diese erlaubt es, das zu erstellende Projekt direkt unter Source-Control zu stellen.

Wird diese Option ausgewählt, erscheint nach dem erfolgreichen Anlegen des Projekts ein Subversion-Dialog, in dem bestimmt werden kann, in welchem Repository es verwaltet werden soll.

Hier muss lediglich die URL des zu verwendenden Repositories eingefügt werden. Diese kann ganz einfach aus dem VisualSVN Server Manager kopiert werden.

Bei aktivierter Subversion-Authentifizierung kommt, muss sich der Benutzer nun zunächst anmelden.

Nach einem Klick auf OK steht das neu erstellte Projekt jetzt offiziell unter Versionskontrolle.

In Visual Studio wird man feststellen, dass einige neue Fenster hinzugekommen sind, ebenso wie einige Einträge ins Kontextmenü des Projektmappen-Explorers. Von entscheidender Bedeutung ist hierbei sicherlich das Fenster Pending Changes, dass anzeigt, welche Änderungen seit dem letzten Auschecken aufgetreten sind. Hier können diese Dateien auch wieder eingecheckt werden, was die Änderungen in das Versionskontrollsystem übernimmt.

Da wir uns so viel Mühe gegeben haben, die Keyword Substituation zu aktivieren, zeige ich jetzt noch, wie sie auch tatsächlich verwendet werden kann. Soll beispielsweise nach jedem Einchecken angezeigt werden, wann dies passiert ist und wer dafür verantwortlich zeichnet, fügt man in die Datei einfach einen Header ein, der wie folgt aussehen könnte.

   1:  // $LastChangedDate$

   2:  // $LastChangedBy$

Die Keywords, die enthalten sind, werden nun bei jedem Einchecken ersetzt und überschrieben, so dass der Header immer aktuell ist.

Jetzt wünsche ich viel Vergnügen beim Coden und Herumprobieren mit Subversion.
Sollten bei der Verwendung Fragen oder Probleme auftreten, kann das kostenlose Online-Buch Version Control with Subversion sicherlich wertvolle Dienste leisten.

DataBinding mit einer List<string>

2009-01-13T18:52:00.000+01:00

Neulich stieß ich bei dem Versuch eine List<string> als Datenquelle für ein DataGridView zu verwenden auf ein interessantes Verhalten, das ich mir jedoch zunächst nicht erklären konnte.

Nehmen wir beispielsweise folgenden Code:

   1:  public FormMain()

   2:  {

   3:      this.InitializeComponent();

4:

   5:      List<string> tvStations = new List<string>();

   6:      tvStations.Add("Pro7");

   7:      tvStations.Add("RTL");

   8:      tvStations.Add("Sat1");

   9:      tvStations.Add("VOX");

  10:      tvStations.Add("Arte");

  11:      tvStations.Add("N24");

  12:      tvStations.Add("Phoenix");

  13:      tvStations.Add("RTL II");

14:

  15:      this.dgvTvStations.DataSource = tvStations;

  16:  }

Zu erwarten wäre, dass beim Start der Applikation unser DataGridView die in der Liste enthaltenen Fernsehsender anzeigt. Doch weit gefehlt, denn das Ergebnis sieht in Wirklichkeit so aus:

Angezeigt werden uns also keineswegs die Fernsehsender sondern lediglich die Länge der Strings, die in der Liste enthalten sind.
Das liegt daran, dass die Datenquelle untersucht wird, wobei natürlich festgestellt wird, dass es sich um eine Liste von Strings handelt. Versucht man hier via Index auf einen bestimmten Wert zuzugreifen, wird man feststellen, dass die einzige verfügbare Eigenschaft dieses Wertes Length ist. Und genau diese wird dann vom DataGridView verwendet.

Um die Daten nun korrekt anzuzeigen muss ein Umweg in Kauf genommen werden.
Wir erstellen hierfür zunächst eine Klasse, die die Daten entgegennimmt, die wir anzeigen wollen. Im vorliegenden Fall könnte diese beispielsweise so aussehen:

   1:  public class TvStation

   2:  {

   3:      private string name;

4:

   5:      public string Name

   6:      {

   7:          get

   8:          {

   9:              return this.name;

  10:          }

  11:      }

12:

  13:      public TvStation(string name)

  14:      {

  15:          this.name = name;

  16:      }

  17:  }

Nun verwenden wir im Formular, das die Daten anzeigen soll, statt einer List<string> eine List<TvStation> und binden diese an den DataGridView.

   1:  public FormMain()

   2:  {

   3:      this.InitializeComponent();

4:

   5:      List<TvStation> tvStations = new List<TvStation>();

   6:      tvStations.Add(new TvStation("Pro7"));

   7:      tvStations.Add(new TvStation("RTL"));

   8:      tvStations.Add(new TvStation("Sat1"));

   9:      tvStations.Add(new TvStation("VOX"));

  10:      tvStations.Add(new TvStation("Arte"));

  11:      tvStations.Add(new TvStation("N24"));

  12:      tvStations.Add(new TvStation("Phoenix"));

  13:      tvStations.Add(new TvStation("RTL II"));

14:

  15:      this.dgvTvStations.DataSource = tvStations;

  16:  }

Wenn jetzt die Anwendung gestartet wird, zeigt der DataGridView tatsächlich die erwarteten Daten.

Schade, dass in diesem Fall ein solcher Umweg nötig ist, aber so funktioniert DataBinding nun einfach mal.

Error: 0x80040204 - Invalid user auth.

2008-12-11T16:12:00.006+01:00

Die im Titel stehende Meldung erhielt ich letztens beim lauf einer meiner Schnittstellen, die sich sequentiell durch Datensätze (in meinem Fall Accounts) eines CRM Systems per Webservice itteriert und darin automatisiert Änderungen durchführt.

Kleiner Fehler ganz groß. Als erstes wurde von allen (ausser mir ;) ) vermutet das sich der am CRM anmeldende User etwas erlaubt was ihm so nicht gestattet ist. Da ich diesen User aber bei allen Zugriffen benutze und alle anderen ja einwandfrei funktionierten, konnte ich das gleich ausschließen.

Meine Vermutung ging in Richtung des im Datensatz selbst zugewiesenen Systemuser (Owner) der bei jeder Änderung mit überegben wird. Dieser User ist ein auf der CRM Seite vorhandener Domänenuser und wird vom CRM System noch einmal extra als Entität "Systemuser" gehalten.

Meine Recherchen ergaben das man den Domänenuser aus der Domäne GELÖSCHT hatte, aber der User natürlich immer noch im CRM als Entität "Systemuser" vorhanden und bei vielen Datensätzen als Owner eingetragen war.

Durch die Löschung jedoch aus der Domäne hat der User praktisch alle rechte verloren und darf somit seine ihm zugeteilten Datensätze auch nicht mehr ändern.

Im vorliegenden Fall, hat die Firma in deren CRM das vorgekommen ist, in allen Datensätze mit einer Referenz zu dem rechtelosen User diesen durch einen in der Domäne noch aktiven User ausgetauscht. Damit hat dann wieder alles funktioniert.

CU TerA

throw ex vs throw

2008-12-05T17:26:00.005+01:00

Es ist eigentlich ein alter Hut, der Unterschied zwischen throw ex und throw sollte jedem bekannt sein. Throw ex schneidet den alten Stack Trace ab und verpackt sozusagen den Fehler neu, Throw hingegen nicht.

Aber dennoch halten sich irgendwie hartnäckig gegenteilige Meinungen, vermutlich aus den Gegenbenheiten aus Java resultierend, aber ich habe auch schon einige ellenlange Threads gelesen in denen das vollkommen Falsche dargelegt wurde, bis hin zu Projektleitern die von einem Verlangen ein ganzes Projekt umzuprogrammieren, weil sie der Meinung wären es wäre genau anders herum.

Den Beweis zu führen ist recht simpel, entweder man schaut sich den MSIL Code an und erkennt das throw zu einem rethrow compiliert, während throw ex, ein throw ex bleibt. Oder aber man testet es einfach mit einem Programm folgender Art selber aus, um auch den letzten Kritiker hoffentlich verstummen zu lassen...

   1:  class ThrowVsThrowEx

   2:  {

   3:     static void Main(string[] args)

   4:     {

   5:        try

   6:        {

   7:           ReThrow();

   8:        }

   9:        catch(Exception ex)

  10:        {

  11:           Console.WriteLine("ReThrow sent: " + ex.ToString());

  12:        }

13:

  14:        Console.Write(System.Environment.NewLine);

15:

  16:        try

  17:        {

  18:           ThrowNew();

  19:        }

  20:        catch (Exception ex)

  21:        {

  22:           Console.WriteLine("ThrowNew sent: " + ex.ToString());

  23:        }

24:

  25:        Console.ReadLine();

  26:     }

27:

  28:     static void ReThrow()

  29:     {

  30:        try

  31:        {

  32:           DontCallMe();

  33:        }

  34:        catch

  35:        {

  36:           throw;

  37:        }

  38:     }

39:

  40:     static void ThrowNew()

  41:     {

  42:        try

  43:        {

  44:           DontCallMe();

  45:        }

  46:        catch(Exception ex)

  47:        {

  48:           throw ex;

  49:        }

  50:     }

51:

  52:     static void DontCallMe()

  53:     {

  54:        throw new ApplicationException("I said don't call me!!");

  55:     }

  56:  }

Ergebnis von throw:

ReThrow sent: System.ApplicationException: I said don't call me!! at DemoExceptions.ThrowVsThrowEx.DontCallMe() in C:\Projects\DemoExceptions\D emoExceptions\ThrowVsThrowEx.cs:line 54 at DemoExceptions.ThrowVsThrowEx.ReThrow() in C:\Projects\DemoExceptions\Demo Exceptions\ThrowVsThrowEx.cs:line 36 at DemoExceptions.ThrowVsThrowEx.Main(String[] args) in C:\Projects\DemoExcep tions\DemoExceptions\ThrowVsThrowEx.cs:line 7

und das Ergebnis von throw ex:

ThrowNew sent: System.ApplicationException: I said don't call me!! at DemoExceptions.ThrowVsThrowEx.ThrowNew() in C:\Projects\DemoExceptions\Dem oExceptions\ThrowVsThrowEx.cs:line 48 at DemoExceptions.ThrowVsThrowEx.Main(String[] args) in C:\Projects\DemoExcep tions\DemoExceptions\ThrowVsThrowEx.cs:line 18

Wunderbar zu erkennen wie throw ex den Ursprung abgeschnitten hat und stattdessen bei sich "selbst" anfängt... keine Worte :)

Konsole in Konsolenanwendung verbergen

2008-11-10T15:50:00.001+01:00

Gerade hatte ich mal wieder eine "wie Schuppen von den Augen"-Situation.

Zielsetzung war, eine Konsolenanwendung zu erstellen, bei der die Konsole nicht sichtbar sein sollte.
Zuerst habe ich an etwas gedacth wie Console.Hide(), doch eine solche Methode existiert nicht.
Dann habe ich Google bemüht und seltsame Verrenkungen gefunden, die einen DllImport benötigten. Auch nicht gerade die feine Art, wie ich fand.

Und dann schoss es mir in den Kopf: Einfach den Ausgabetyp auf Windows-Anwendung setzen und glücklich werden!
Schon erstaunlich, wie einfach es manchmal sein kann und wie weit man dennoch daneben liegt...

P.S.: Gerade habe ich noch gesehen, dass in den Kommentaren des obigen Blog-Eintrags die von mir verwendete Möglichkeit tatsächlich auch von jemandem erwähnt wurde.

Toolbox-Item hinzufügen bei installierten Power Commands nicht möglich

2008-10-30T09:01:00.004+01:00

Gerade eben wollte ich mir die Chart Controls für das .NET Framework 3.5 anschauen, die Microsoft vor kurzem veröffentlicht hat.
Leider war nach der Installation des Pakets nichts neues im Data-Tab der Toolbox zu finden. Laut Anleitung soll man für diesen Fall die Controls einfach händisch hinzufügen. Als ich das jedoch versuchte, fror mein Visual Studio 2008 einfach ein oder stürzte gar ab. Letzteres erfreulicherweise ohne jede Fehlermeldung.

Nach ein wenig Recherche habe ich tatsächlich herausgefunden, dass das Verhalten durch die installierten Power Commands für Visual Studio 2008 hervorgerufen wird.
Also habe ich diese schnell deinstalliert und siehe da, ich kann wieder Items zur Toolbox hinzufügen.

Sehr schade, dass die Power Commands einen derart negativen Einfluss auf VS2008 haben, denn eigentlich finde ich sie sehr nützlich. Deshalb werde ich sie auch wieder installieren und hoffen, dass ich mich das nächste mal, wenn ich etwas in die Toolbox schieben möchte, daran denke, sie zuvor zu deinstallieren.

Interessant ist im Übrigen auch, dass mein Kollege die Power Commands ebenfalls installiert hat, er jedoch problemlos neue Items in die Toolbox einfügen kann...

Nachtrag:
Ich habe die Power Commands jetzt wieder installiert und erneut versucht, ein Toolboxelement hinzuzufügen. Siehe da, es funktioniert einwandfrei.

Hexadezimaldarstellung eines Strings nach Int32 umrechnen - bbo-Style

2008-10-29T21:32:00.002+01:00

Wie tropensturm Hex-Strings nach Int32 konvertiert, haben wir heute schon gelernt. Natürlich hat er gleich wieder Forderungen gestellt, also kommt hier meine Version.

Zunächst muss ich anmerken, dass ich wesentlich pragmatischer an die Sache herangegangen bin. Ich habe Dinge wie Encoding und Little- / Big-Endian vernachlässigt, denn ich brauchte schnell eine funktionierende Lösung für einen Test.

Folgender Code ist bei mir dabei heraus gekommen:

   1:  public static int ConvertHexStringToInt(string hexString)

   2:  {

   3:      string hex = "0x";

4:

   5:      for (int i = 0; i < hexString.Length; i++)

   6:      {

   7:          hex += ((int)hexString[i]).ToString("X");

   8:      }

9:

  10:      return Convert.ToInt32(hex, 16);

  11:  }

Im Prinzip ist das, was ich hier tue, eigentlich recht einfach.
Zunächst lege ich mir eine String-Variable an, die die hexadezimale Darstellung des übergebenen Strings aufnehmen soll. In der for-Schleife sorge ich entsprechend dafür, dass dies auch so ist. In Zeile 7 wandle ich zunächst jeden Buchstaben des Übergabe-Strings in seine ASCII-Int32-Repräsentation, die anschließend nach Hexadezimal konvertiert und dem finalen String angehängt wird.
Ist die Schleife für alle Zeichen des Strings durchlaufen worden, haben wir einen String im Format 0xA9AE.
Diesen String konvertiere ich dann in Zeile 10 noch nach Int32, wobei ich eine Basis von 16 (also hexadezimal) angebe und gebe das Ergebnis zurück.

So weit, so einfach...
... leider aber auch so "beschränkt".
Durch das Konvertieren jedes Buchstabens in seine Int32-Repräsentation in Zeile 7 wird diese Lösung auf Zeichen beschränkt, die im ASCII-Zeichensatz vorhanden sind. Werden Zeichen verwendet, die in diesem nicht auftauchen, führt das zu falschen Ergebnissen.

FAZIT:
Für meine Zwecke ist diese Implementierung absolut ausreichend, da ich mir sicher sein kann, dass mein Übergabe-String nur Zeichen enthält, die auch im ASCII-Zeichensatz auftauchen. Für einen produktiven Einsatz ist aber auf jeden Fall tropensturms Lösung vorzuziehen, da diese eben auch mit nicht ASCII-konformen Zeichen umgehen kann.

bbo-Style: 0
tropensturm-Style: 1

Freie Cryptography API

2008-10-29T20:44:00.004+01:00

Eine freie Cryptography API, inkl. OpenPGP, ohne jegliche Lizenzeinschränkungen mit der Ausnahme das License Informations File weiterzugeben. Hört sich zu gut an um wahr zu sein? :)

The Legion of the Bouncy Castle - Bouncy Castle Cryptography API

Features:

Generation and parsing of PKCS-12 files.

X.509: Generators and parsers for V1 and V3 certificates, V2 CRLs and attribute certificates.

PBE algorithms supported by PBEUtil: PBEwithMD2andDES-CBC, PBEwithMD2andRC2-CBC, PBEwithMD5andDES-CBC, PBEwithMD5andRC2-CBC, PBEwithSHA1andDES-CBC, PBEwithSHA1andRC2-CBC, PBEwithSHA-1and128bitRC4, PBEwithSHA-1and40bitRC4, PBEwithSHA-1and3-keyDESEDE-CBC, PBEwithSHA-1and2-keyDESEDE-CBC, PBEwithSHA-1and128bitRC2-CBC, PBEwithSHA-1and40bitRC2-CBC, PBEwithHmacSHA-1, PBEwithHmacSHA-224, PBEwithHmacSHA-256, PBEwithHmacRIPEMD128, PBEwithHmacRIPEMD160, and PBEwithHmacRIPEMD256.

Signature algorithms supported by SignerUtilities: MD2withRSA, MD4withRSA, MD5withRSA, RIPEMD128withRSA, RIPEMD160withECDSA, RIPEMD160withRSA, RIPEMD256withRSA, SHA-1withRSA, SHA-224withRSA, SHA-256withRSAandMGF1, SHA-384withRSAandMGF1, SHA-512withRSAandMGF1, SHA-1withDSA, and SHA-1withECDSA.

Symmetric key algorithms: AES, Blowfish, Camellia, CAST5, CAST6, DESede, DES, GOST28147, HC-128, HC-256, IDEA, ISAAC, NaccacheStern, Noekeon, RC2, RC4, RC5-32, RC5-64, RC6, Rijndael, Salsa20, SEED, Serpent, Skipjack, TEA/XTEA, Twofish and VMPC.

Symmetric key modes: CBC, CFB, CTS, GOFB, OFB, OpenPGPCFB, and SIC (or CTR).

Symmetric key paddings: ISO10126d2, ISO7816d4, PKCS-5/7, TBC, X.923, and Zero Byte.

Asymmetric key algorithms: RSA (with blinding), ElGamal, DSA, and ECDSA.

Asymmetric key paddings/encodings: ISO9796d1, OAEP, and PKCS-1.

AEAD block cipher modes: CCM, EAX, and GCM.

Digests: GOST3411, MD2, MD4, MD5, RIPEMD128, RIPEMD160, RIPEMD256, RIPEMD320, SHA-1, SHA-224, SHA-256, SHA-384, SHA-512, Tiger, and Whirlpool.

Signer mechanisms: DSA, ECDSA, ECGOST3410, GOST3410, ISO9796d2, PSS, RSA.

Key Agreement: Diffie-Hellman and EC-DH.

Macs: CBCBlockCipher, CFBBlockCipher, GOST28147, HMac, ISO9797 Alg. 3, and VMPCMAC.

PBE generators: PKCS-12, and PKCS-5 - schemes 1 and 2.

OpenPGP (RFC 2440)

Cryptographic Message Syntax (CMS, RFC 3852), including streaming API.

Online Certificate Status Protocol (OCSP, RFC 2560).

Time Stamp Protocol (TSP, RFC 3161).

Elliptic Curve Cryptography (support for F2m and Fp curves).

Reading/writing of PEM files, including RSA and DSA keys, with a variety of encryptions.

Hexadezimaldarstellung eines Strings nach Int32 umrechnen

2008-10-29T16:02:00.016+01:00

BBo hat mir eine Aufgabenstellung hingeworfen und wir haben diese dann unterschiedlich gelöst. Es ging darum die Hexadezimaldarstellung eines 2 Byte langen String nach Int32 zu konvertieren. Das war etwas schwieriger als wir dachten. Hier nun meine Lösungsvariante, vielleicht postet BBo ja noch seine ;)

Das Erste was mir durch den Kopf ging ist, dass dies etwas gefährlich ist in Bezug auf das Stringencoding. Denn je nach dem wie der String decodiert wurde, hat man ja je nach Umgebung eine andere Hexadezimalwertdarstellung nach dem Encodieren. Darum habe ich einfach zur Absicherung das Encoding mit eingebaut in meine Lösung. Theoretisch kann man in einer homogenen Welt darauf verzichten, doch meine praktischen Erfahrungen in den letzten Monaten haben mir oft genug die Finger verkokelt. Man kann ja selber mal damit herumspielen und mit unterschiedlichen Encodings die unterschiedlichen Ergebnisse vergleichen...

   1:  // test

   2:  int erg = TwoByteStringHexValueToInt32("Aÿ", System.Text.Encoding.GetEncoding(1252));

   3:  ...

4:

   5:  public static int TwoByteStringHexValueToInt32(string input, Encoding encoding)

   6:  {

   7:     if (input.Length != 2)

   8:        throw new ArgumentException("TwoByteStringHexValueToInt32 - parameter input is allowed to be 2 byte long only!");

9:

  10:     if (encoding == null)

  11:        encoding = System.Text.Encoding.Default;

12:

  13:     int result = 0;

  14:     byte[] ba = encoding.GetBytes(input); // split to byte array of 2

15:

  16:     if (System.BitConverter.IsLittleEndian) // when little endian we need to do a workaround

  17:     {

  18:        result = (Convert.ToInt32(ba[0]) << 8) + Convert.ToInt32(ba[1]);

  19:     }

  20:     else

  21:     {

  22:        result = (int)System.BitConverter.ToInt16(ba, 0);

  23:     }

24:

  25:     return result;

  26:  }

In Zeile 14 geht es richtig los, da zerleg ich den Input string in ein 2-Byte Array in Abhängigkeit (!) vom Encoding des Strings. 1252 ist das herkömmliche Encoding unter Windows für lateinische Schriftsysteme, u.a. Deutsch. Danach steht also in unserem Byte Array die Hexdarstellung unseres Strings.

Danach mache ich einen kleinen Kunstgriff in Zeile 16, x86 Syteme sind LittleEndian kodiert, Motorola z.B. normalerweise BigEndian. Hier eine kleine Info wenn man damit nichts anfangen kann. Im Klartext, normalerweise rechnet man den Wert in unserem Bytearray wie in Zeile 22 gezeigt um. Mit dem Bitkonverter nach 16Bit Integer, werden 2 Bytes aus dem Bytearray ab der Position 0 gelesen und in Integer umgerechnet (Int32 bräuchte 4 Bytes, darum dieser Umweg).

Und GENAU hier schlägt die Sache mit dem Little/Big Endian System zu! Denn wir haben zuvor oben unseren String eigentlich verkehrt herum abgelegt für unser x86 System!! Denn das rechnet von Hinten nach Vorne Bytedarstellungen nach Integer um!

Daher das Byteshifting in Zeile 18, falls ein Little Endian System vorliegt. Ich greife mir das erste Byte konvertiere es nach Int32 und verschiebe es mal 8 Bits nach "links" (= 1 Byte, wir haben ja 2 Bytes und schieben das Erste sozusagen nach "vorne"), um dann einfach das Ergebnis aus der zweiten Byte Konvertierung dazu addieren.

Nachtrag: Der Rückweg

   1:  public static byte[] Int16ToBigEndianByteArray(short input)

   2:  {

   3:     int higher = input >> 8;     // shift 1 byte -> get higher byte

   4:     int lower  = input & 0x00ff; // mask -> get lower byte

5:

   6:     byte[] ba = new byte[2];

   7:     ba[0] = Convert.ToByte(higher);

   8:     ba[1] = Convert.ToByte(lower);

9:

  10:     return ba;

  11:  }

12:

13:

  14:  ...

  15:  // test

  16:  byte[] ba = Int16ToBigEndianByteArray((short)31910);

  17:  string res = System.Text.Encoding.GetEncoding(1252).GetString(ba);