Today a colleague ask me to help.

On his system all ReSharper menus are grayed out. Also the Visual Studio Add-In Manager does not show this add-in.

He tried:

• a new installation: without success,
• running with administrative privilegeg: without success,
• looking in event- and application-logs: no entries.

After searching a little bit with old buddy google we found this message: Wild World of Visual Studio -- Mysterious Component

We downloaded and installed the latest Microsoft Core XML Services (MSXML) 6.0 Service Pack 1 and ReSharper works fine. :-)

The colleague remembered that he uninstalled SQL Server 2005 – and for this MSXML6 is a installation feature – so a full deinstallation removes MSXML6 also. :-(

Wenn ein Remote-Zugriff auf einen SQL Server 2005 mit der Fehlermeldung

"A connection was successfully established with the server, but then an error occurred during the pre-login handshake.
When connecting to SQL Server 2005, this failure may be caused by the fact that under the default settings SQL Server does not allow remote connections." 

scheitert, dann hilft folgendes

1. Öffnen der SQL Server Surface Area Configuration
2. Anwählen von "Surface Area Configuration for Services and Connections"
   Unter "MSSQLSERVER > Database Engine > Remote" den Zugriff auf "Local and remote connections" mit Unterpunkt "Using both TCP/IP and named pipes" setzen
3. SQL Server neu starten

Beim Installieren des Enterprise Single Sign-On Dienstes kommt folgende Fehlermeldung:

The database server you specified cannot be reached.
Make sure you have specified the correct server name and that the server is currently running.
Login failed for user *** 

Die Domain-Gruppe der "SSO Administratoren" muss in die Gruppe der lokalen Adminstratoren auf der SQL Server Maschine. Der Installations-User bekommt durch die Mitgliedschaft in "SSO Administratoren" dann Admin-Rechte im SQL-Server.

Beim Starten einer Web-Anwendung kommt der Fehler:

Unable to start debugging on the web server.
Debugging failed because integrated Windows authentication is not enabled.
Please see Help for assistance. 

Es wurde vergessen eine Authentifizierung für die Web-Applikation zu setzen.

1. Internet Information Services (IIS) Manager starten
2. Rechtsklick auf Default Web Site
3. Tab Directory Security
4. Edit-Button im Abschnitt "Authentication and access control" anklicken
5. Im Abschnitt "Authenticated access" ein Häkchen bei "Integrated Windows authentication" setzen

Schon eim Aufrufen der Default-Webseite unter http://localhost kommt die Fehlermeldung "Service unavailable" und im Eventlog tauchen Warnings und Errors auf.

Warnings

A process serving application pool 'DefaultAppPool' terminated unexpectedly.
The process id was '5920'.
The process exit code was '0xffffffff'.

Errors

Application pool 'DefaultAppPool' is being automatically disabled due to a series
of failures in the process(es) serving that application pool.

bzw:

The application-specific permission settings do not grant Local Activation permission for 
the COM Server application with CLSID {A9E69610-B80D-11D0-B9B9-00A0C922E750} 
to the user NT AUTHORITYNETWORK SERVICE SID (S-1-5-20).
This security permission can be modified using the Component Services administrative tool.

mögliche Ursache

Grund können verloren gegangene Berechtigungen am DCOM-Object des IIS Admin Services sein.

Zum neuen Setzen die Component Services starten und die Properties von My Computer > DCOM Config > IIS Admin Service öffnen.

Auf dem Tab Security wechseln und die Launch and Activation Permissions editieren.

Nun die Gruppe der Authenticated Users aufnehmen und Local Activiation sowie Remote Activation setzen.

Setzen der SID

Die SID eines Systems zu ändern ist kein Problem dank SysPrep und Co.

Ermitteln

Wie ermittelt man aber die aktuell gesetzte SID?

Das geht ganz fix mit PsGetSid aus den PsTools von SysInternals.

Einfach Auspacken und ohne Optionen starten liefert die SID für das aktuelle System.

Obwohl die Assemblies mit den Schemas im GAC und deployed sind, kommt es beim Aufpicken einer Schemainstanz zu 2 Fehlereinträgen im Eventlog und die Message wird supended.

Fehler

Event Id: 5753
A message received by adapter "FILE" on receive location "XML" with URI "C:File_InORDERS01*.xml" is suspended. 

Error details:
There was a failure executing the receive pipeline:
"Microsoft.BizTalk.DefaultPipelines.XMLReceive, Microsoft.BizTalk.DefaultPipelines, Version=3.0.1.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"
Source: "XML disassembler"
Receive Port: "RpORDERS01"
URI: "C:File_InORDERS01*.xml"
Reason: Loading document specification from assembly failed. Verify that the schema for this document specification is deployed and placed in the Global Assembly Cache.

und

Event Id: 5719
There was a failure executing the receive pipeline: "Microsoft.BizTalk.DefaultPipelines.XMLReceive, Microsoft.BizTalk.DefaultPipelines, Version=3.0.1.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"
Source: "XML disassembler"
Receive Port: "RpORDERS01"
URI: "C:File_InORDERS01*.xml"
Reason: Loading document specification from assembly failed. Verify that the schema for this document specification is deployed and placed in the Global Assembly Cache. 

Lösung

1. Trennung der Solution in jeweils eigene Assemblies für Schemas, Pipelines, Maps und Orchestrations
2. Sicherstellen, dass der Target-Namespace vom Schema (Schema-Node anklicken | Properties | Target Namespace) zu dem in der Instanz passt (Attribut xmlns am Root-Node)
3. Verwenden eines Multi-part Message Type der auf ein Schema verweist. Operations und Messages verwenden dann diesen Multi-part Message Type anstatt selbst das Schema zu referenzieren.

Unterschiedliche Namespaces zwischen Schemas und Instanzen führen immer wieder zu kryptischen Fehlermeldungen.

Die Erfahrung zeigt, dass es einige besonders tückische Stellen gibt, die man sofort verifizieren sollte.

Typische Fehlermeldungen

Namespace-Referenzierung in der Instanz passt nicht zur deklarierten im Schema

There was a failure executing the receive pipeline: "Microsoft.BizTalk.DefaultPipelines.XMLReceive, Microsoft.BizTalk.DefaultPipelines, Version=3.0.1.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"
Source: "XML disassembler"
Receive Port: "RpIn"
URI: "C:File_InMiniTest*.xml"
Reason: Finding document specification by message type "de.MeineFirma.EAI.Schema.FalscherTyp#MyEntity" failed.
Verify that the schema is deployed properly.

Komplette Namespace-Referenzierung in der Instanz vergessen

There was a failure executing the receive pipeline: "Microsoft.BizTalk.DefaultPipelines.XMLReceive, Microsoft.BizTalk.DefaultPipelines, Version=3.0.1.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"
Source: "XML disassembler"
Receive Port: "RpIn" URI: "C:File_InMiniTest*.xml"
Reason: Finding document specification by message type "MyEntity" failed. Verify that the schema is deployed properly.

Receive-Pipeline falsch konfiguriert, z.B. auf PassThruReceive anstatt auf XMLReceive

The Messaging engine failed to process a message submitted by adapter:FILE Source
URL:C:File_InMiniTest*.xml.
Details:The published message could not be routed because no subscribers were found.
This error occurs if the subscribed orchestration schedule or send port has not been started, 
or if some of the message properties necessary for subscription evaluation have not been promoted.

Folgende Einstellungen sollten immer passen

Schema an sich (Auswahl der XSD-Datei)

Namespace: de.MeineFirma.EAI.Schema
Type Name: MeinTyp

macht zusammen für den Full Qualified Name ein de.MeineFirma.EAI.Schema.MeinTyp

Schema-Node (Auswahl von )

Target Namespace: de.MeineFirma.EAI.Schema.MeinTyp

Namespace Referenzierung in der Instanz

...

Encoding der Instanz

ggf die Instanz mit einem Editor neu speichern mit explizitem Setzen eines Encodings

Einheitliche Namespaces

Wenn Schemas und Orchestrations im gleichen Assembly sind, führt das Ändern von Namespaces zu massiven und tückischen Problemen. Das hängt u.a. damit zusammen, dass z.B. die Port Type Definitionen zwar den Namespace des Schema übernehmen, aber nicht den Namespace des Assemblys. Infolgedesse wird im GAC das Schema nicht mehr übers Assembly gefunden.
siehe: http://www.traceofthought.net/PermaLink,guid,cfa8a62a-af33-44b8-a40e-ede8d1b2867c.aspx
Abhilfe: Schema und Orchestration in 2 verschiedene Assembly, dann werden die Assembly-Namespaces bei der Referenzierung mit übernommen

Pivotal erzeugt mittels GenerateSchema.ASP für die Integration Adapter ein XDR-Schema. Dieses Schema ließ sich unter BizTalk Server 2002 auch anstandslos importieren und weiterverwenden.

Der BizTalk Server 2006 erwartet allerdings XSD-Schema. Alle Varianten die XDR- nach XSD-Schema zu wandeln schlugen fehl.

Einzig alleine die Neuerzeugung von XSD-Schema auf Basis übetragender XML-Dokumente war erfolgreich.

Konvertierungsvarianten

Folgende Varianten der XDR zu XSD Konvertierung wurden probiert.

1. Verwendung von XDRtoXSD.xslt (u.a. zu finden im BizTalk-Verzeichnis) von Microsoft mit dem Kommandozeilen-Tool msxsl.exe (Download unter http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnxml/html/msxsl.asp)
   Problem: XSD ist unbrauchbar
2. Verwendung von XDRtoXSD.xslt mit dem Kommandozeilen-Tool cvtschema.exe (Bestandteil von SqlXml seit Version 3.0 im bin-Verzeichnis)
   Fehler: Missing Element
3. Verwendung von XDRtoXSD.xslt mit XmlSpy
   Fehler: xslt enthält ungültige Formel
4. xsd.exe mit vorhandenen XDR-Schema
   Fehler: verschiedene bei der weiteren Verwendung, u.a. Global Namespace, nicht erlaubte Element-Inhalte, Namespace

Neuanlage

Neuerzeugung mittels Visual Studio und BizTalk Schema Generator:

1. Installation des Wizards für Well-Formed XML mittels InstallWFX.vbs (aus dem BizTalk-SDK)
2. Rechtsklick auf BizTalk Server Projekt | Add | Add Generated Items ...
3. Generate Schemas Template doppelklicken
4. Document Type auf Well-Formed XML setzen
5. vorhandene Instanz aus einem alten BizTalk Server 2002 Tracking ziehen und auswählen
6. OK

Eigene Functoide für den BizTalk zu entwickeln ist ziemlich easy. Die Dokumentation mit den Beispielen ist OK und ausreichend.

Trotzdem gibt es ein paar Dinge die man im Eifer des Gefechtes schnell mal übersieht.

1. Das Assembly mit den Functoiden braucht eine GUID. Diese einfach per Attribut [assembly: Guid("...")] in die AssemblyInfo.cs einbinden.
2. Das Assembly in den GAC kopieren.
3. Das Assembly ins Verzeichnis "Microsoft BizTalk Server 2004/Developer Tools/Mapper Extensions" kopieren.

Typische Fehlermeldung

Vergisst man letzteres kommt es beim Testen einer Map zu einer Fehlermeldung:

Exception Caught:
Mapper Compiler: Functoid not found: guid ({..})
with functoid id (..).

Automatisierungen mittels Post-Build-Events

Punkte 2.) und 3.) lassen sich gut über Post-Build-Events realisieren

copy $(TargetPath) "C:/Program Files/Microsoft BizTalk Server 2006/Developer Tools/Mapper Extensions"
"C:/Program Files/Microsoft Visual Studio 8/SDK/v2.0/Bin/gacutil" -i $(TargetPath)

Gerade im Zusammenhang mit nullable Types im .NET FW 2.0 ist es interessant eine XSD-Definition mit leeren (nicht-string) Elementen zu erlauben.
Das Attribut "nillable" reichte dazu nicht aus (zumindest nicht im Zusammenhang mit BizTalk).
Bleibt also noch die Definition eines eigenen Elementes.

Das lässt sich mittels der UNION-Ableitung recht einfach realisieren. Meine Umsetzung sieht wie folgt aus:

Im Zusammenhang mit der Entwicklung eines eigenen BizTalk Adapters trat immer wieder das Problem auf, dass nicht klar war ob ein Assembly geladen wurde oder nicht. Und gerade im Nichtladefall was der Grund dafür war.

Dafür gibt es das SDK-Tool fuslogvw (Assembly Binding Log Viewer).
Dieses Tool erlaubt das Aktivieren des Tracings von Assembly-Ladevorgängen.

Beim Debugging wird der Fehler:

"EXECUTE permission denied on object 'sp_sdidebug', database 'master', owner 'dbo'."

geworfen.

Komplette Fehlermeldung:

[System.Data.SqlClient.SqlException] = 
{"EXECUTE permission denied on object 'sp_sdidebug', database 'master', owner 'dbo'."}

Ein Deaktivieren der Checkbox "Enable SQL Server debugging" brachte keine Besserung.

Eine dedizierte EXEC-Rechtevergabe für den Serviceuser BTServiceHost auf die Stored Procedure "sp_sdidebug" in der Datenbank "master" löste das Problem.

Unklar bleibt warum der o.g. Standard-Tipp aus den einschlägigen Foren nicht geholfen hat.

Nach dem Unzug eines Projektes von einem Rechner auf einen anderen, gab es die Warnung und Fehlermeldung:

The adapter failed to transmit message going to send port "spZ_ESRI_DEBITOR_CREATE.SAP" with URL "sap://AS:xxx/00/800/".
It will be retransmitted after the retry interval specified for this Send Port.
Details:"SAP .Net connector is not installed".

A message sent to adapter "SAP" on send port "spZ_ESRI_DEBITOR_CREATE.SAP" with URI "sap://AS:xxx/00/800/" is suspended.
Error details: SAP .Net connector is not installed

Für die direkte Anbindung von Pivotal PXIE an den BizTalk Server 2006 mittels des HTTP-Adapters ist die Möglichkeit gegeben dies über diverse HTTP-Receive Locations zu handeln.

Leider muss im Falle der Parameterübergabe für jede Variante des Parameters ein eigene Receive-Location vorgesehen werden. Das ist nicht wartbar für viele verschiedene Pivotal-Entitäten, aber für einzelne Entitäten durchaus praktikabel.

Receive Location Properties

Type: HTTP

Receive Handler: BizTalkServerIsolatedHost

Receive Pipeline: jenachdem was man vor hat

HTTP Transport Properties

Virtual directory plus ISAPI extension: /Test5/BTSHTTPReceive.dll?channel=ESRI-DE%20CRM%20T98_UpdatePrimary_8000000000000104

Return correlation handle on success: aktiviert

Suspended failed requests: aktiviert