Microsoft Posters (Bezugsquellen und Links)

Wer kennt sie nicht als Software Entwickler, überall hängen diese schön bunten Poster herum die mal mehr oder weniger sinnvoll Features und Frameworks anschaulich demonstrieren können.

Bei Microsoft kann man einge davon herunterladen. Was ich sehr bedauerlich finde ist, dass ich keine Einstiegsseite auf MSDN kenne, die einem alle Poster zusammenfassend präsentiert. Nun gut, man kann immerhin die Suche bemühen, dennoch bleibt bei mir das Gefühl nicht alle zu erfassen. Natürlich kann man die auch für einen verhältnismäßig günstigen Preis erwerben, z.B. bei Amazon.de wie die das Posterpack für das .NET Framework 2.0, oder auch über Technet (da kann man auch z.B. die Jahresarchiv DVDs des MSDN Magazins ordern).

Empfehlenswert finde ich folgende Poster:

• Ein Namespace und Type Überblick für das .NET Framework 3.5.
• Hochinteressant finde ich die PnP (Patterns and Practices) Poster: Smart Client Architektur und der Overview.
• Für Shortcutfetischisten die C# Keybinding Poster für VS2008 und VS2005 (gibt es auch für Basic und C++. J# und der Rest gehen leider leer aus).
• Wer mit InfoPath oder Sharepoint entwickelt wird hier fündig, inkl. einer Developer Roadmap für Office 2007.
• Für BizTalk2006 Entwickler gibts gleich nen ganzen Schwung an Poster, u.a. die Datenbank Struktur inkl. der SQL Jobs und die Runtime Architektur.

BizTalk Deployment OOM Probleme

Out of Memory ist so eine Totschlag Fehlermeldung beim BizTalk 2006 Deployment, die ziemlich viele Ursachen haben kann, wie diverse Googlesuchsessions bei mir ergaben. Eine kurze Checkliste woran es liegen kann und ich gegenveriferziert habe bei mir selbst: 1. Hat der Host zu wenig (Arbeits-)Speicher: Visual Studio (wenn auf dem Hostsystem) schließen und neu starten (kann schon reichen) und/oder "Services" öffnen (Run Box Command: services.msc) und ein Restart von "SQL Server (MSSQLSERVER)" mit allen daran hängenden anderen Services (geschieht automatisch). Zusammen sollte das jedenfalls den Speicher dramatisch leeren 2. Hat der Host genug (Arbeits-)Speicher, bzw. der Erste Tipp funktioniert nicht: ...dann hilft ein überprüfen der SQL Jobs. Es ist enorm wichtig das der "MessageBox_Message_Cleanup_BizTalkMsgBoxDb"-Job läuft(!!) Jede Message die mehr als EINEN Subscriber hat wird nämlich nicht sofort aus der Message Box intern gelöscht, das macht erst später dieser Job. Zu finden ist dies im "Microsoft SQL Server Management Studio", rechts unter SQL Server Agent->Jobs Langwieriges Deployment... Tipp 2 ist übrigens auch zu prüfen wenn das Deployment sehr lange dauert, bzw. es immer langsamer wird. Hier ist auch gegenfalls zu überprüfen, wenn Visual Studio sich auf dem selben System befindet, ob im Projekt unter Deployment -> BizTalk Group -> Server "(LOCAL)" eingetragen ist und nicht(!) die (lokale) IP Adresse. Warum auch immer, auch dies hat einen "bremsenden" Effekt.

Inconsistent duplicate module attribute

Ein 'Microsoft.XLANGs.BaseTypes.BPELExportable': inconsistent duplicate module attribute Error hat mich ziemlich lange geärgert in Biztalk2006 R2 beim kompilieren. Des Rätsels Lösung war das sowohl in den Projekteneigenschaften unter Build - Code Generation: BPEL Compliance True als auch in einer Orchestration unter Eigenschaften: Module Exportable auf True gesetzt war. Leider natürlich an einer völlig anderen Stelle als im Error Output angegeben. Ein setzen innerhalb der Orchestration auf False behob das Problem... Offenbar ist "doppeltgemoppelt" nicht immer gut ;)

Kenne deine .NET Werkzeuge - HttpUtility Class

Ich denke eines der größten individuellen Mankos ist, dass man (ich) nicht sein Framework und die damit zur Verfügung gestellten Werkzeuge kennt. Ich vermute mal ein ASP.NET Entwickler wird die HttpUtility Class (http://msdn.microsoft.com/en-us/library/system.web.httputility(VS.80).aspx) kennen, ich kannte sie nicht. Es war unerlässlich das ich ein XML von Hand zusammenkleben mußte und mein LoadXML in ein XmlDocument schlug grandios fehl. Das Problem war schnell gefunden im XML Editior von Visual Studio, der hat mir einen Eintrag rot unterringelt der ein & enthielt. Ich wollte schon loslegen eine Hilfsklasse zu schreiben die mir meine Values &, ä, ö, ü, <, > usw. konvertiert nach &amp; etc. ... Doch "Halt!", meinte mein Kollege, da muss es doch was im Framework schon geben. Nach etwas "googeln" fand ich dann die HttpUtility Class. Und die hat eine HtmlEncode Methode die einem das wunderbar erschlägt :)

string encodedValue = System.Web.HttpUtility.HtmlEncode(unencodedValue);

Das Ganze funktioniert auch innerhalb von Biztalk. Die System.Web dll muss hier explizit referenziert werden, das dürfte vermutlich auch für alle Nicht-ASP.NET Projekte gelten.

HowTo: Erstellen von Snippets

Gestern habe ich über .NET-Snippets.de berichtet, wo man eine Vielzahl von nützlichen Snippets finden kann. Nun kennt sich vielleicht nicht jeder mit der Thematik Snippets aus und weiß, wie man heruntergeladene Snippets in Visual Studio verfügbar macht. Oder das Posting hat den Ehrgeiz geweckt, eigene Snippets zu erstellen, doch es fehlt das Wissen, wie das zu erledigen ist.

Deshalb kam mir der Gedanke, ein HowTo zu schreiben, wie man Snippets erstellen und in VS einbinden kann. Doch da kam mir ein heutiges Posting in den MSDN-News zuvor. Es trägt den Namen "Codierungs-Turbos in Visual Studio 2008" und behandelt einige Interessante Themen, wie man mit Hilfe von Visual Studio Programmierarbeit schneller erledigen kann. Netterweise ist unter anderem ein kompletter Abschnitt über Snippets mit an Bord. Dieser behandelt wirklich alles rund um Snippets. Ganz so, als hätte Microsoft gerochen, was mir gerade so im Kopf herum geht.

Zu erreichen ist der gesamte Beitrag hier: Codierungshilfsmittel Der Abschnitt über Snippets ist hier zu finden: Erstellen und Verwenden von IntelliSense-Codeausschnitten

Snippets: .NET-Snippets.de

Eine sehr nützliche Neuerung, die Visual Studio 2005 mit sich brachte, waren die Snippets. Dabei handelt es sich um kleine Codeschnipsel, die auf einfache Art und Weise in den Code eingefügt werden können.Beispielsweise ergibt die Eingabe von f-o-r-TAB-TAB  eine fertige for-Schleife. Die Werte, die angepasst werden müssen (in diesem Fall Indexer und Grenzwert) sind als Felder hervorgehoben und können via Tab sehr einfach angesprungen und verändert werden. Nach Abschluss der Anpassungen reicht ein Tippen auf Enter und die For-Schleife ist fertig (natürlich ohne die interne Logik... ).

Inzwischen benutze ich auch zum Einfügen unseres Firmen-Headers ein Snippet. Das spart mir pro Datei ca. 20 Zeilen "Handschreiben" und dem entsprechend auch Zeit.

Eine ausgesprochen gute Quelle für Snippets aller Art ist die Seite .NET-Snippets.de, die kurz nach Veröffentlichung von Visual Studio 2005 ans Netz ging. Das System von .NET-Snippets.de ist es, dass die angemeldeten Benutzer eigene Snippets hochladen und veröffentlichen können. Weiterhin kann jeder Nutzer jedes Snippet kommentieren und kostenlos herunterladen. Doch nicht nur aufgrund der reinen Fülle an Snippets, die zur Verfügung stehen, ist .NET-Snippets.de immer mal wieder einen Blick wert. Schon des Öfteren habe ich dort sehr schöne Lösungen für alltägliche Probleme gefunden.

Ich kann nur jedem .NET-Entwickler empfehlen, sich hier anzumelden, sich einmal durch die Snippets zu "wühlen" und auch gerne eigene Snippets zu veröffentlichen. Anreize gibt es ab und an mal durch Snippet-Contests, bei denen die bestbewerteten Snippets (respektive deren Ersteller) mit Preisen belohnt werden.

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

Custom Pipeline Components - Update

Seit meinem ersten Eintrag zum selber schreiben von Custom Pipeline Components (http://justacodeblog.blogspot.com/2008/05/custom-pipeline-components-wizard.html) hab ich inzwischen soviel Erfahrungen zu dem Thema gesammelt, das ich hierzu ein Update verfassen muss.

Ein paar Anmerkungen zum arbeiten mit Martijn Hoogendoorn's Component Wizard und Pipeline Komponenten generell:

- Der Beste Ansatz um die erstellten Komponenten stressfrei zu deployen und in der Toolbox des Pipeline Projektes zu verwenden ist es die fertige DLL Komponente: 1.) in den GAC zu deployen 2.) in das Pipeline Component Verzeichnis von Biztalk zu deployen (z.B.: C:\Program Files\Microsoft BizTalk Server 2006\Pipeline Components) Beides kann man gut im Post Built Event erledigen z.B. wie folgt (für 64Bit Windows mit angepasst, darum die relativen Pfade) "$(DevEnvDir)..\..\SDK\v2.0\Bin\gacutil.exe" /i "$(TargetPath)" xcopy "$(TargetPath)" "$(DevEnvDir)..\..\..\Microsoft BizTalk Server 2006\Pipeline Components" /R /Y

- Log4Net und 64Bit Windows können Probleme in Verbindung mit der Biztalk Toolbox Erkennung bereiten. Dabei kann entweder die korrekte Namenserkennung der Komponente, oder gar die komplete Komponenten Erkennung fehlschlagen. Das Problem vermute ich in den Windows Sicherheitseinstellungen (?). Ansonsten hilft als "Workaround" nur das komplette Entfernen von Log4Net aus der Komponente

- Beim Umbennen einer Pipeline Komponente (Namespace und/oder Klassenname) muss man zwei weitere Punkte beachten für die korrekte Anzeige in der Toolbox später. 1.) Unterhalb der Kompenenten Klassendeklaration wird der Name registriert:

   1:  private System.Resources.ResourceManager resourceManager = new System.Resources.ResourceManager(

   2:      "<Namespace>.<Pipeline Komponenten Name>",

   3:      Assembly.GetExecutingAssembly());

2.) Im Ressource File selbst: COMPONENTNAME = <Namespace>.<Pipeline Komponenten Name>

- Für einen rundimentären Test ist das pipeline.exe Tool selbst eine schnelle und schöne Sache. Jedoch empfiehlt es sich unbedingt auch eine BizTalk Test Orchestration zusammenzuklicken! Der Umstand ist simpel. Während die pipeline.exe unsere Komponente direkt aus dem lokalen Filesystem aufruft, wird in BizTalk ein COM Aufruf ausgeführt! Dies verändert den Kontext in dem sich der Stream befindet, den man gerade verarbeitet! Simples Beispiel: solange man über die pipeline.exe testet, kann der Stream nach FileStream gecastet werden, um z.B. den File Namen auszulesen. Führt man den selben Aufruf in BizTalk aus, sind die FileStream Informationen gar nicht mehr vorhanden. Ein Cast schlägt fehl!

- Für das Testen mit der pipeline.exe empfiehlt es sich eine eigene Solution Konfiguration anzulegen (z.B. Debug Pipeline). In den Projekteigenschaften konfiguriert man dann unter Debug:

• Start external program: <pfad zum Pipeline Test Tool>\Pipeline.exe
• Command line arguments z.B.: -pt <namespace>.<biztalk pipeline orchestration> -an <custom pipeline component name>-d <input flatfile> -v
• und ggf. noch die Working directory anpassen wenn nötig

(nicht vergessen bei einer neuen Solution Konfiguration unter der Projekteigenschaft Build - Advanced Button die Debug Info mit erzeugen zu lassen (full))

- Bei der Implementierung ist darauf zu achten das BizTalk die Pipeline bei hoher Last automatisch parallel ausführt!! D.h. VORSICHT beim Umgang mit z.B. statischen Elementen, wer nicht darauf verzichten kann, muß Threadsicher programmieren!

Skype-AddIn für Visual Studio 2005 / 2008

Ein weiterer Schritt in Richtung "Ich geh nie wieder aus meinem VS raus" ist gemacht: Der thailändische Entwickler Keng Pongsathon hat ein AddIn für Visual Studio geschrieben, welches Skype in unser aller Lieblingsspielzeug einbindet. Dieses ist auf Codeplex verfügbar: http://www.codeplex.com/SkypeStudio/

Über Sinn und Unsinn dieses AddIns kann man jetzt diskutieren. Meine Reaktion war eher in Richtung "Wozu", die eines anderen Teilnehmers an diesem Blog ein schlichtes "Goil". Da sollte sich wohl jeder selbst seine Meinung bilden.

Gefunden habe ich das AddIn im Übrigen über den deutschen MSDN Blog.

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? :-/

Hashtable in Key Reihenfolge abarbeiten

Ich hatte in einer Hashtable Strings mit einem Integer Wert als Key abgelegt und wollte die nun in numerischer Folge abarbeiten, mein erster gedankenloser Ansatz war etwas umständlich. Mit etwas nachdenken hatte ich einen eleganteren Weg gefunden.

Dazu hab ich ersteinmal die Hashtable in ein generisches Dictionary umgewandelt, dann die Keys in eine generische Liste geschaufelt und dann einfach den Sort angewendet. Natürlich hätte dies auch mit einer Hashtable und einer Arraylist funktioniert, aber da beide in jeder Hinsicht in der Performance den Generics unterlegen sind hab ich das umgeschrieben nach diesem Beispiel:

   1:  ...

   2:  Dictionary<int, string> ht = new Dictionary<int, string>(10);

   3:  ht.Add(1, "hallo");

   4:  ht.Add(2, "welt");

   5:  ht.Add(3, "!");

   6:  ...

   7:             

   8:  List<int> keys = new List<int>(ht.Keys);

   9:  keys.Sort();

  10:   

  11:  foreach (int k in keys)

  12:  {

  13:     System.Console.WriteLine("key = " + k.ToString() + " value = " + (string)ht[k]);

  14:  }

  15:  ...

Das funktioniert dann auch analog mit anderen Datentypen, ggf. muss dann der Comparer implementiert/überladen werden, je nach Geschmack :)

Custom Pipeline Components Wizard, Toolbox Probleme und Testen

Martijn Hoogendoorn hat einen Wizard geschrieben, der einem viel programmierarbeit abnimmt beim erstellen von custom pipeline components: http://www.codeplex.com/btsplcw

Einfach den Source Code compilieren und im Visualstudio kann man mit einem Rechtsklick auf das Installer Projekt gleich "install" auswählen um den Wizard zu integrieren.

Legt man ein neues Projekt an kann man nun unter BizTalk Projects den BizTalk Server Pipeline Component Wizard auswählen. Dieser erzeugt einem dann ein C# (auf Wunsch auch VB.NET) Projekt wo man nur noch fertig implementieren muss wo ein #error Compilerflag gesetzt wurde.

Ich weiß nicht ob es nur so mir ging, aber ich fand es nicht eindeutig wie man denn nun eine selbst geschriebene Komponente in die Pipeline "hineinbekommt". Alles was ich gefunden habe lief ungefähr immer auf das Selbe hinaus, "einfach reinziehen in die Toolbox" ...das hatte jedenfalls nicht so funktioniert wie ich mir das anfangs dachte ;)

Ersteinmal muss man ein paar Vorraussetzungen schaffen damit es später keine Probleme beim deployen gibt:

1.) Die Komponente muss mit einem key signed sein

2.) Die Komponente sollte im GAC installiert werden

Hat man das muss man in der Toolbox der Pipeline Datei mit Rechtsklick das Menü holen und dort "Choose Items..." auswählen und dort die neue Komponente auswählen. Danach ist sie endlich auch für unsere Custom Pipeline verwendbar.

Zum Testen von Pipelines gibt es übrigens ein nützliches Werkzeug unter "...\Microsoft BizTalk Server 2006\SDK\Utilities\PipelineTools\Pipeline.exe". Damit kann man die .btp Datei direkt oder die .NET Assembly testen ohne zu deployen!!

S# oder wie GENIAL ist das denn?

Absoluter Zufall das ich darauf gestoßen bin... das mußte ich gleich in unserem Blog verewigen

Script# oder S# ist ein C# nach JavaScript "Konverter", die Idee is einfach genial umgesetzt 8-)
Man entwickelt in C# gegen ein Interface und bekommt am Ende JavaScript...

Das Projekt kann man von Codeplex beziehen: http://www.codeplex.com/scriptsharp

Eine kurze Einführung gibt es vom Entwickler selbst hier:
http://www.nikhilk.net/ScriptSharpIntro.aspx

Update 25.08.2008: Das Projekt ist nun unter http://www.codeplex.com/scriptdotnet zu erreichen.

I've joined the Dark Side!

Ja, in der Tat, ich bin heute auf die Dunkle Seite gewechselt, bin jetzt ein Dunkler Entwickler! Aber langsam, von was rede ich da eigentlich? Dunkle Seite von was? Die Dunkle Seite von Visual Studio natürlich!

Wer jetzt keine Ahnung hat, wovon ich rede, hat in letzter Zeit die diversen Blogs bekannter .Net-Entwickler nicht aufmerksam gelesen. Ab in die Ecke dafür! Aber ich will mal nicht so sein und euch verraten, um was es geht. Vor nicht all zu langer Zeit ging es durch die Weiten des Webs, einige Entwickler, die tagtäglich mit Visual Studio arbeiten, wollten sich nicht mehr mit der Standard-Oberfläche abgeben und taten etwas dagegen. Beteiligt waren daran mit Sicherheit Entwickler, die des öfteren in Stunden programmieren, in denen die natürliche Beleuchtung ausgefallen ist und die Ersatzbeleuchtung den Augen viel zu grell. Richtig, ich rede von der Nacht. Das Weiß des standardmäßigen Hintergrunds von Visual Studio hat in eben jenen Stunden den großen Nachteil, sehr grell zu sein und die Augen über kurz oder lang zu ermüden. Daher bestand die Lösung der findigen Entwickler darin, eine Konfiguration für Visual Studio zu erstellen, die die Augen weniger fordert, die Dark Side of Visual Studio war geboren.

Wenn man sich diesen Blog (zumindest im aktuellen Layout, wer weiß, was die Zukunft bringt...) anschaut, fällt einem auf, dass auch hier alles ziemlich dunkel gehalten ist. Da lag es also nahe, dass auch ich mich der Dunklen Seite verschrieb. Die erste Anlaufstelle dafür ist die Website die auffordert: JOIN THE DARK SIDE OF VISUAL STUDIO. Genau hier gibt es die Settings herunter zu laden, die einen auf die dunkle Seite der Programmierung ziehen wollen - allerdings nur für Visual Studio 2008. Die entsprechenden Settings für Visual Studio 2003 (VORSICHT: hier wird ein spezielles Styler-AddIn benötigt!) und 2005 gibt es in diesem Blog zum Download.

Da wahrscheinlich nicht jedem sofort klar ist, wie man diese Settings jetzt in sein Visual Studio bekommt, folgt jetzt eine kleine Anleitung.

Zuerst mal wird das herunter geladene ZIP-File entpackt. Anschließend öffnet man das Studio. Hier geht es weiter mit einem Klick auf Extras --> Einstellungen importieren und exportieren...

Im darauf folgenden Assistenten wird der RadioButton vor Ausgewählte Umgebungseinstellungen importieren aktiviert.

Ein Klick auf Weiter und es präsentiert sich eine Auswahl, die vorschlägt, die aktuellen Settings vor dem Laden der neuen zu sichern. Das halte ich persönlich für absolut sinnvoll, denn was ist, wenn man nicht für die Dunkle Seite gemacht ist? Ok, es gibt eine Option zum Zurücksetzen der Settings, aber dann ist alles wieder wirklich Standard. An dieser Stelle sollte jeder selbst entscheiden, wie er verfahren möchte. Wie auch immer die Entscheidung ausgefallen ist, nach einem Klick auf Weiter erscheint ein Fenster, in dem einige bereits bekannte Settings zum Import zur Auswahl stehen. Die von uns gewünschten sind hier jedoch nicht vorhanden. Da hilft ein Klick auf den Button Durchsuchen. Hat man dann das Setting gefunden, das man verwenden will, geht es Weiter.

Es erscheint nochmal eine Abfrage, die zur Wahl der zu importierenden Einstellungen auffordert. Hier kann man einfach auf Fertig stellen klicken.

Anschließend denkt Visual Studio ein wenig darüber nach, was ihm da jetzt angetan wurde, fügt sich jedoch schlussendlich doch folgsam in sein Schicksal und meldet dies auch netterweise mit der Meldung Importvorgang abgeschlossen. Braves kleines Ding.

Wird jetzt ein Projekt geöffnet, müsste das ganze in etwa so aussehen:

Welcome to the Dark Side!

Mir persönlich ist die Schrift um Längen zu groß, doch das stellt zum Glück kein großes Problem dar. Will man die Schriftgröße verändern, navigiert man zu Extras --> Optionen..., woraufhin sich der Optionen-Dialog öffnet. Hier wird der Punkt Umgebung erweitert und auf den Unterpunkt Schriftarten und Farben geklickt. Auf der rechten Seite kann jetzt die Schriftgröße reguliert werden, welche nach einem Klick auf OK auch prompt angewendet wird.

Damit sind auch schon alle Arbeiten abgeschlossen. Das Endergebnis kann sich sehen lassen, wie ich denke. Eventuell fällt jetzt etwas Eingewöhnungszeit an, schließlich sind die meisten von uns die Standard-Settings doch sehr gewohnt. Ich selbst habe mich erst heute der Dunklen Seite verschrieben, weshalb ich noch keine wirklichen Erfahrungen damit gemacht habe. Jedoch denke ich, dass mein Studio den Rest seiner Tage auf der Dunklen Seite verbringen wird. Eventuell konnte ich ja den ein oder anderen animieren, sich auch mal auf die Dunkle Seite zu wagen, die Gefahren sind dank Sicherung der vorherigen Settings ja durchaus gering. Falls auch der werte Leser sich in das Dunkel gewagt hat, wünsche ich ihm das, was auch die offizielle Seite des "Projekts" wünscht:

May the dark side of Visual Studio be with you!

Noch ein kleiner Nachtrag: Das hier gezeigte Setting eignet sich auch hervorragend für eine Präsentation, wie ich live miterleben durfte.

? unter C# und .NET 2.0

Jeder kennt - denke ich - den folgenden Ausdruck, der eine if/else Abfrage auf das Wesentliche komprimiert:

   1:  public void xyz(string save)

   2:  {

   3:      bool decide = save.ToLower() == "j" ? true : false;

   4:      ...

   5:  }

Ab .NET 2.0 geht aber noch mehr mit ?:

   1:  public void xyz(string save)

   2:  {

   3:      bool? decide = null;

   4:      ...

   5:  }

Huh? Eine null Zuweisung auf einen Value Type? Nein es ist ein Referenztyp in diesem Fall, da es sich der Generics unter 2.0 bedient, das in diesem Fall wie folgt definiert ist:

System.Nullable<t> wofür wiederum ein T? definiert wurde.

Das ist doch schon mal cool, aber wie stell ich fest ob es sich um einen Value oder Referenztyp handelt wenn ich einen solchen Wert zugeschoben bekomme?

   1:  int? i = 0;

   2:   

   3:  Type t1 = typeof(int?);    // System.Nullable...System.Int32

   4:  Type t2 = i.GetType();     // System.Int32

   5:   

   6:  bool eq = t1 == t2;        // false

Also das funktioniert offenbar schon einmal nicht! Und schlägt auch noch fehl, falls i == null gesetzt wurde.
Aber wir können uns folgendermaßen behelfen:

   1:  int x = i.HasValue ? (int)i : 0;

...und dafür gibt es gleich einen noch viel kürzeren neuen Ausdruck ab 2.0:

   1:  int x = i ?? 0;

Um den Generic zu bestimmen geht man wie folgt vor:

   1:  bool eq = t1.GetGenericTypeDefinition() == typeof(Nullable<>);

Doch Vorsicht! Wäre t1 nicht vom Type Generic, bekommen wir eine InvalidOperationException! Daher muß vorher noch abgeprüft werden ob es sich überhaupt um einen Generic handelt und da C# linksassoziativ auflöst, können wir das wie folgt zusammenstöpseln:

   1:  bool eq = t1.IsGenericType && t1.GetGenericTypeDefinition() == typeof(Nullable<>);

Problem mit References in einer BizTalk Orchestration

Bei mir ist vorhin ein ziemlich seltsames Phänomen aufgetreten, das ich nicht eindeutig dem BizTalk Plug-In oder VisualStudio 2005 zuordnen kann. Da mir das aber noch nie unter "normalem" VS passierte rechne ich es eher Ersterem zu.

Ich hab aus einem alten BizTalk Projekt eine Orchestration übernommen. Das hat bisher auch immer wunderbar funktioniert, nach dem alles gerade gezogen wurde.

Diese Orchestration verwendet ein paar Funktionaliäten, die in einem anderen Projekt referenziert werden. Versuchte ich dies einzubinden, zeigt mir der Dialog nichts weiter an als die Standard Referenzen.... Ein Gegencheck der anderen Orchestrations ergab das die benötigten Referenzen einwandfrei in meinem Projekt erreichbar sein müßten.

Alle Refreshs und Compile-Versuche brachten nichts. Die neue Orchestration weigerte sich standhaft, die Referenzen in den entsprechenden Dialogen anzuzeigen.

Umso witziger irgendwie der Workaround:
mit dem XMLEditor in VS (Rechtsklick->Open With..) wurden ein paar der "alten" Referenzen ausgetauscht mit den neuen per Hand... und tadaaa plötzlich wurden auch die Referenzen in der Orchestration wieder allesamt ohne Murren angezeigt... äußerst seltsam irgendwie.

Da ich noch ein paar weitere ältere Orchestrations migrieren muß, werde ich das Phänomen mal im Auge behalten und untersuchen ...

PS: thx @ teratom ;)

Integration FxCop in VisualStudio2005

FxCop ist ein Prüftool um sicherzustellen das das die Richtlinien von Microsoft während des codens eingehalten werden, bzw. um zu überprüfen ob diese eingehalten wurden.

Es gibt mehrere Installationsmöglichkeiten. Zwei möchte ich hier vorstellen.

0. Pfade bitte an Eure Installation anpassen.
1. Nach der Installation von FxCop in VisualStudio im Menue "Tools" das Untermenue "External Tools..." auswählen.
2. Auf "Add" klicken.
3. In "Title:" 'FxCop' eingeben.

Ausgabe im "Output" Window von VisualStudio:
4. In "Commands:" das installierte FxCop mit "C:\Program Files\Microsoft FxCop 1.36\FxCopCmd.exe" anwählen.
5. In "Arguments:" '/c /f:"$(TargetPath)" /r:"C:\Program Files\Microsoft FxCop 1.36\Rules" /consolexsl:"C:\Program Files\Microsoft FxCop 1.36\Xml\VSConsoleOutput.xsl"' eingeben.
6. In "Initial directory:" den Pfad vom installierten FxCop eingeben (bei mir 'C:\Program Files\Microsoft FxCop 1.36').
7. "Use Output window" setzen.
8. "Apply" & "OK" anklicken.

Öffnen eines FxCop Fensters mit aktuellem Projekt:
4. In "Commands:" das installierte FxCop mit "C:\Program Files\Microsoft FxCop 1.36\FxCop.exe" anwählen.
5. In "Arguments:" '$(TargetPath)' eingeben.
6. In "Initial directory:" den Pfad vom installierten FxCop eingeben (bei mir 'C:\Program Files\Microsoft FxCop 1.36').
7. "Apply" & "OK" anklicken.

Das war es schon. Um nun zu sehen ob das eigene Projekt den Microsoftstandarts entspricht, einfach im Menue "Tools" den neuen Punkt "FxCop" anwählen (bei der "Output"-Version muss das Output Fenster (im Menuepunkt "View" aktivierbar) aktiv sein).

Downloadlink: FxCop

Unexpecting Error writing Metadata to file...

Dieser vielsagende Fehler beim Kompilieren in Visual Studio weist darauf hin, dass das Limit für die DLL-Größe erreicht wurde.

In meinem Fall ging es um eine reine Schema Library für ein BizTalk Projekt.
Mehrere Quellen weisen zwar auf ein Limit von 75MB hin, bei mir reichten allerdings schon etwas mehr als 30MB aus um diese Fehlermeldung zu erhalten. Also ein paar Schemas ausgelagert, neu kompiliert und es geht wieder.

Unglaublich wie schnell sich das aufgebläht hat....