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

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 Error BEC2004: Validate Instance failed for schema

warning BEC2004: Data at the root level is invalid. Line 1, position 1

Da erstelle ich doch glatt ein XSD Schema mit dem Flatfile Schema Wizard von BizTalk2006/R2 für meinen Kollegen, schick es ihm rüber und es funktioniert nicht...

Noch einmal getestet bei mir, geht immer noch, bei ihm... nicht...

Also hingesetzt bei ihm, Schema nachkreiert -> Funktioniert...

Zu mir rübergeschickt -> geht nicht...

WinDiff -> Kein Unterschied...

Unterschied Kollege hat 64Bit Betriebssystem ich 32Bit, also Files in einer anderen Text Codierung neu abgespeichert auf meinem 32Bitter.... Gleiches Verhalten...!

Copy und Paste vom Inhalt des 64Bit Schemas in eine neue Datei... Gleiches Verhalten...!!!

Nun bin ich etwas ratlos. Deutet vielleicht auf ein Problem mit Escape Zeichen hin... aber der Austausch von Escape Sequencen für Tab und CR/LF brachte auch keine Lösung.

Äußerst kurios, zumal ich schon vorher mehrfach mit anderen Windows 2003 64Bit Systemen das gleiche tat und XSD Schemas aus einer 32Bit Entwicklungsumgebung migrierte in das dortige Projekt.

Irgendjemand eine Idee?

SAP Adapter in Biztalk 64Bit oder "Retrieving the COM class factory for component with CLSID {XXX} failed..."

Versucht man mit dem normalen vorgehen die SAP-Adapter für Biztalk unter einem 64Bit Windowssystem zu installieren, bekommt man so lustige Fehlermeldungen wie diese hier:Natürlich sagt diese treffend aus wo der Fehler liegt (Ha, HA!). Der Fehler liegt einfach darin das der SAP-Adapter seinen Dienst nur auf 32Bit Systemen nachgeht und auf 64Bit Systemen einfach seine DLLs nicht findet. Um das zu beheben muss man nach der Installation (SAP-Connector und SAP-Adapter) dem SAP Adapter expliziet eine 32Bit Umgebung zuweissen. Dazu legt manin der Biztalk Administration Console unter "Platform Settings/Hosts" einen neuen Host an und konfiguriert diesen auf 32Bit.

Danach noch das ganze im SAP Adapter zuweissen (Send und Receive) und siehe da, es läuft.

Jetzt nur nicht vergessen den Host zu restarten ;)

log4net & 64Bit - Update

Zumindestens einen Teil des Problems aus dem Post http://justacodeblog.blogspot.com/2008/07/log4net-ibasecomponent-64bit-windows.html habe ich inzwischen aufgeklärt.

Unter Windows 2003 64Bit gibt es drei Gac Verzeichnisse: GAC_32 (für 32Bit kompilierte Assemblies), GAC_64 (für 64Bit kompilierte Assemblies) und GAC_MSIL (Assemblies die sowohl als auch ausgeführt werden können).

Mit Hilfe von Filemon habe ich dann herausgefunden das meine Anwendung log4net im GAC_32 verzweifelt sucht. Eigentlich sollte log4net mit Hilfe des Gacutils im GAC_32 Verzeichnis landen, tut es aber nicht, es landete bei mir im GAC_MSIL Verzeichnis.

Ich habe es dann "von Hand" dort hin kopiert und nun funktioniert es, jedoch habe ich keine Ahnung ob man bei Gacutil einen Switch setzen kann der die automatische Entscheidung überstimmt und das Deployment in einem bestimmten Verzeichniss erzwingen kann...

Biztalk SAP Adapter Error 8007007e

Vielleicht "schon wieder" ein 64Bit Enviroment Issue... (?) der Auslöser ist mir nicht ganz klar, aber bei meinem aktuellen Projekt tritt nach der Konfiguration im Biztalk Server 2006 von SAP Ports alle paar Minuten im Eventlog den folgenden Fehler:

Nach etwas Rumforschen und Abgleichen der SAP Adapter Installationsverzeichnisse ergab sich das sowohl die ATL71.dll als auch die MSVCR71.dll fehlten. Offensichtlich hat der Adapter Installer Probleme diese Komponenten unter Windows 2003R2/x64 zu installieren. Ich musste diese von Hand nachträglich reinkopieren nach "C:\Program Files (x86)\Microsoft BizTalk Adapter v2.0 for mySAP Business Suite" Der Fehler stoppte sofort, ohne irgendetwas neu zustarten, von alleine.

64Bit / 32Bit und universelles Postbuildevent mit gacutil

Nur als kleine Notiz für mich selbst, da die Pfade für die Programmordner unterschiedlich sind unter 64 und 32 Bit. Hab ich mir aus den Makros die Pfade zusammengeklickert und da ich allein schon mit dem setzen von " und \ herumeiere leg ich das hier mal lieber ab ;)

"$(DevEnvDir)..\..\SDK\v2.0\Bin\gacutil.exe" /u "$(TargetPath)"
"$(DevEnvDir)..\..\SDK\v2.0\Bin\gacutil.exe" /i "$(TargetPath)"

log4net, IBaseComponent & 64Bit Windows Server

log4net 1.2.10, IBaseComponent & 64Bit Windows Server funktionieren irgendwie nicht zusammen. Das witzige unter 32Bit funktioniert es!

Für eine Biztalk Pipeline habe ich zwei Komponenten entwickelt die aus einem Flatfile Format eine XML Datei erzeugt. Beim einbinden der Komponten war im Browser von VisualStudio bei einer der korrekte Name aus der IBaseComponent zu sehen, bei der anderen der Assembly Name.
Dumm denn auf meiner 32Bit Entwicklungsmaschine war dem nicht so, aber auf dem 64Bit Zielsystem. Nach einer etwas längeren Remotedebuggingsession stellte sich dann heraus das bei der Komponente mit dem "falschen Namen", nicht einmal der Konstruktor angesprungen wird, geschweige denn die Informationen aus IBaseComponent, wenn man diese in VisualStudio "an"browst.

Erst nach der vollständigen Entfernung der log4net Referenzierung (darauf muss man erstmal kommen), wurde der korrekte Name aus dem Interface angezeigt. Befand sich log4net gar im GAC war die Pipeline Komponente überhaupt nicht mehr auffindbar, beim manuellen Browsen gabs dann nur noch den lapidaren Hinweis das wohl etwas mit der Sicherheitseinstellung der Komponente nicht stimmen würde... sehr merkwürdig....

Eine Sicherheitseinstellung in Windows Server? Ein Problem mit log4net? :-/