Marko Apfel

EAI, BizTalk, SQL Server, C#

  Home  |   Contact  |   Syndication    |   Login
  61 Posts | 2 Stories | 22 Comments | 4 Trackbacks

News



Article Categories

Archives

Post Categories

BizTalk

C#

Enterprise Library

SAP

SQL Server

Technologie

Tuesday, November 17, 2009 #

During a refactoring we searched for full type names in our IoC-config files. The filter was setted to *.xml and Visual Studio does not found all occurrences of the search string in these xml-files.

Setting the filter to *xml without the dot solves this problem – however.


Thursday, November 12, 2009 #

if you see the following warnings in your code:

You have two choices:

  • deactivate the rule
    but this disables this rule for all documentations – also the wanted
  • tune the detail settings
    In the settings editor you see additional options if you select the “Documentation Rules” root node

Normally i want to ignore the warnings for missing private and internal documentations and also for documentation of fields.


Installing StyleCop for ReSharper under an administrative account does not activate this ReSharper plugin under my developer account.

A system analysis show, that this plugin is installed under

%userprofile%\Local Settings\Application Data\JetBrains\ReSharper\v4.5\vs9.0\Plugins\Microsoft StyleCop for ReSharper

This gives the hint, that the msi must be started for each individual user separately – maybe the is the possibility to move the stuff to all users or that there is also an administrative installation possible.


If AgentSmith throws a warning that some term is not spelled correctly for this term the spell checking could be suppressed with:

//agentsmith spellcheck disable
...
//agentsmith spellcheck enable


Wednesday, November 11, 2009 #

see also Working with Microsoft FxCop

As described in the previous post a custom dictionary could be referenced in a FxCop-call of a target by using the option:

/dictionary:"$(ProjectDir)..\FxCop.CustomDictionary.xml"

But how is it possible to publish this custom dictionary for the Visual Studio integrated code analysis?

This analysis runs an other FxCop.exe than my special FxCop-target. So the custom dictionary which is specified in the FxCop-call of my target is not used.

The solution is very simple. Because every project gets the FxCop-target the information about the custom dictionary could be inserted there.

This is done with the section:

<ItemGroup>
<CodeAnalysisDictionary Include="&quot;$(ProjectDir)..\FxCop.CustomDictionary.xml&quot;" />
</ItemGroup>

Visual Studio code analysis uses this information. So with one line all projects are satisfied.


Run FxCop as a post build event

Since FxCop 1.36 it is possible to include FxCop in a post-build event.

So FxCop runs after compiling in Visual Studio and allows you directly jumping to the warned line.

 

Description of the command line

In the sample above the command line is

IF $(ConfigurationName) == Debug $(ProjectDir)..\..\..\..\tools\FxCop\FxCopCmd.exe
/console  
/file:"$(TargetPath)" 
/directory:"$(ProjectDir)..\..\..\..\lib\Primary Interop Assemblies" 
/directory:"$(ProjectDir)..\..\..\..\lib\ArcGIS\9.2.0.1324" 
/dictionary:"$(ProjectDir)..\..\..\CustomDictionary.xml"

 

Parameter Description
/console Outputs messages to console, including file and line number information.
/file

Assembly file to analyze.

$(TargetPath) is a makro-variable of Visual Studio which points to the compilation.

Wrap it in quotations to avoid problems with spaces in path names.

/directory

Location to search for assembly dependencies. This parametes could occurs multiple times.

$(ProjectDir) is a makro-variable of Visual Studio which points to the *.csproj-file of the project.

/dictionary

Custom dictionary to allows own abbreviations and own words for syntax checking.

 

Integration as a build target

Integration as an own target

Instead running FxCop as a post build event the using of build targets is a good and since using of Hudson the recommended way.

In the csproj file therefore a new target must included. You could name it De.Esri.FxCop.targets for instance.

Place the call of this target beneath the normal build target.

<Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" />
<Import Project="..\De.Esri.FxCop.targets" />

And now we need this target. Important is the FxCopCmd-call. Therefore we use the Exec tag.

The whole call must made in one line. Only for documentation purposes every option has a own line.

<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<BuildDependsOn>$(BuildDependsOn);FxCop</BuildDependsOn>
<RebuildDependsOn>$(RebuildDependsOn);FxCop</RebuildDependsOn>
</PropertyGroup>

<ItemGroup>
<CodeAnalysisDictionary Include="&quot;$(ProjectDir)..\FxCop.CustomDictionary.xml&quot;" />
</ItemGroup>

<Target Name="FxCop">
<Exec Command="..\..\tools\FxCop\FxCopCmd.exe
/file:&quot;$(TargetPath)&quot;
/dictionary:&quot;$(ProjectDir)..\FxCop.CustomDictionary.xml&quot;
/out:&quot;$(OutDir)..\$(ProjectName).FxCopReport.xml&quot;
/console /forceoutput"

WorkingDirectory="..\..\tools\FxCop\" ></Exec>
<Message Text="FxCop finished." />
</Target>
</Project>

Because the filesystem ressource parameters could contain spaces (e.g. )Program Files) these parameters must be quoted. Thats why we need the cryptical &quot; there.

Integration as a MSBuild-Community target

John Rayner's Blog

Complex build script run FxCop:

Integrating FxCop into CruiseControl.NET


Monday, November 09, 2009 #

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. :-(


Thursday, February 23, 2006 #

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

Thursday, March 16, 2006 #

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.


Monday, March 20, 2006 #

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.

Thursday, March 23, 2006 #

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


Sunday, April 09, 2006 #

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