Office365 – Primäre Mail Adresse ändern (für den Administrator Account) – Powershell

Nachdem ich im ersten Teil über die Einrichtung eigener Domains für die Nutzung unter Office365,  und im zweiten Teil über Einrichtung von E-Mail Adressen von eigenen Domains,  berichtet habe, geht es nun darum, die primäre Absenderadresse des
Exchange Postfachs ändern zu können.

Und zwar unter den Umständen, dass man nur einen Office365 Account hat und für diesen natürlich auch gleichzeitig der Administrator dieses Accounts ist.

Mit den Bordmitteln von Office365 und der Administrationswebseite ist dies nämlich nicht möglich.

Da sich der Exchange Server aber durch die Windows Powershell steuern lässt, können wir über diesen Weg all die Dinge tun, die uns die Webseite zur Administration nicht im Dialog zur Verfügung stellt.

Ich versuche diese Beschreibung so zu gestalten (Schritt für Schritt). dass auch Leser, die sich mit der Powershell nicht auskennen, die Einstellungen vornehmen können. Ich hoffe das gelingt mir.

Die Windows Powershell ruft man wie folgt auf:

Start Menü –> Programme–> Zubehör –> Windows Powershell –>

Dort dann mit der rechten Maus auf Powershell klicken und “Als Administrator ausführen”

Als erstes müssen wir prüfen, ob die Berechtigungen für die Powershell so eingerichtet sind, dass sie ausreichen um eine Remote Verbindung zum Office365 (Remote Exchange Server) herstellen zu können. Im Standard dürften die Berechtigungen nicht ausreichen und wir müssen diese Berechtigung dann entsprechend anpassen.

Aber eins nach dem anderen.

Prüfen der aktuellen Powershell Berechtigung:

In die Powershell geben wir den nachfolgenden Befehl in die Kommandozeile ein und betätigen dann die Eingabetaste.

Get-ExecutionPolicy

Unbedingt darauf achten, hier ist kein Leerzeichen im Befehl enthalten, es handelt sich im ein Wort.

Wenn vorher noch keine Änderungen an den Berechtigungen der Powershell vorgenommen wurden, sollte folgende Systemantwort zurückgegeben werden “Restricted”:

Wenn anstelle “Restricted”, “RemoteSigned” oder “Unrestricted” zurückgegeben wird, sind die Berechtigungen bereits ausreichend und man kann den nächsten Schritt überspringen.

Setzen der Powershell Berechtigung (nur wenn notwendig)

Der nachfolgende Befehl wird in die Powershell eingegeben und mit der Eingabetaste bestätigt.

Set-ExecutionPolicy RemoteSigned -Force

Eigentlich sollte der Befehl ohne Probleme ausgeführt werden, und es sollte keine Fehlermeldung ausgegeben werden. Zur Sicherheit prüfen wir das noch einmal mit dem Befehl: “Get-ExecutionPolicy

Nun sollte der Rückgabewert wie folgt aussehen:

Powershell Remote an Office356 anmelden

Nachdem wir nun die Berechtigungen geprüft bzw. gesetzt haben, müssen wir nun die Powershell Remote an Office365 anmelden.

Hierzu geben wir den nachfolgenden Befehl in die Powershell ein und bestätigen wie immer mit der Eingabetaste:

$LiveCred = Get-Credential

Nun sollte sich ein Anmeldebildschirm wie nachfolgend öffnen.

In den Dialog muss man nun die Anmeldeinformationen für seinen Office365 Account eingeben und mit OK bestätigen.

Powershell Session mit Office365 (Exchange Server) herstellen

Als nächstes müssen wir eine Powershell Session mit dem Exchange Server von Office365 herstellen. Hierzu muss man den nachfolgenden Befehl in die Powershell eingeben:

$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell/ -Credential $LiveCred -Authentication Basic -AllowRedirection

Wie immer mit der Eingabetaste bestätigen. Dann sollte eine Meldung wie die nachfolgende in der Powershell zurückgegeben werden.

Powershell Commands importieren (Damit die Powershell Exchangich sprechen kann)

Um in der Powershell die Exchange Kommandos verwenden zu können ist es notwendig die Befehle zu importieren.

Das geht mit der Eingabe des nachfolgenden Befehls in die Powershell:

Import-PSSession $Session –AllowClobber

Nachdem man diesen Befehl wie immer mit der Eingabetaste bestätigt hat, sollte eine, der folgenden Abbildung entsprechenden Rückmeldung, ausgegeben werden.

Damit sind nun die Vorbereitungen abgeschlossen und wir können endlich an die eigentliche Aufgabe gehen:

Wie war die noch mal ? :-)

Ach ja richtig wir wollten die Primäre E-Mail Adresse des Exchange Postfachs ändern.

Ändern der primären E-Mail Adresse

Um die Primäre E-Mail Adresse zu ändern, müssen wir folgenden Befehl in die Powershell eingeben:

Set-Mailbox [Office365Benutzernamen] -EmailAddresses SMTP:[myPrimary@mail.de], [meineAktuelleMail@onmicrosoft.com]

Hier die Syntax dieses Befehls:

  • [Office365Benutzernamen] steht hier als Platzhalter für den Office365 Benutzeraccount (der wird und kann nicht geändert werden, ist also der Benutzername)
  • [myPrimary@mail.de] steht als Platzhalter für die E-Mail Adresse die nun die primäre E-Mail Adresse sein soll.
  • [meineAktuelleMail@onmicrosoft.com] steht als Platzhalter für die aktuelle primäre E-Mail Adresse (bei der ersten Änderung ist das gleich mit dem Benutzernamen)

Und hier auch noch ein Beispiel:

Set-Mailbox max@musterman.onmicrosoft.com -EmailAddresses SMTP:max@musterman.de, max@musterman.onmicrosoft.com

Session schließen

Und ganz zum Ende müssen wir dafür sorgen, dass die Powershell Session wieder geschlossen wird.

Dies geht mit der Eingabe des folgenden Befehls in die Powershell:

Remove-PSSession $Session

Das sollte unbedingt gemacht werden, da es sonst bei mehrfachem herstellen einer Session und nicht korrektem Schließen dazu kommen kann, dass keine neue Session mehr geöffnet werden kann, Max Session überschritten.

(Ich glaube der Wert liegt zwischen 3 und max 5 Session)

So und nun viel Spaß mit Office365 und der eigenen E-Mail als primären E-Mail Adresse.

Welche Mail Adresse die Primäre ist, kann man übrigens in den E-Mail Optionen des Exchange Servers kontrollieren.

Wie das geht kann man in dem bereits oben erwähnte Beitrag nachlesen

http://blog.schelian.de/2011/08/office365-einrichtung-mail-adressen-bei-verwendung-eigener-domain/

Posted in Tips und Tricks, Wissenswert | Tagged , , , | 2 Comments

Office365 – Einrichtung Mail Adressen bei Verwendung eigener Domain

Nachdem ich im Beitrag http://blog.schelian.de/2011/08/office365-eigene-domain-nutzen-ohne-die-microsoft-dns-server-zu-verwenden/ darüber berichtet habe, wie man eigene Domains in Office365 einrichtet, könnte man diese Artikel auch mit folgenden Titel überschreiben:

Domain ist auf Office365 eingerichtet, was nun, wo bleiben meine Mails?

Um Mails einer eingerichteten Domain auch empfangen zu können, muss man die Mail Adressen die verwendet werden sollen, erst in Office365 oder konkreter gesagt im Exchange Online Postfach konfigurieren.

Die nachfolgenden Screenshots zeigen den Weg zu den Einstellungen.







Wenn wir es bis hierher geschafft haben, können wir mit der eigentlichen Konfiguration beginnen.

Mit “Hinzufügen” öffnen wird den folgenden Dialog zur Eingabe einer neuen Mail-Adresse:

In der Combo Box, rechts vom @ wählen wir die Domain aus für die eine Mail Adresse erstellt werden soll, links vom @ geben wir die Mail Adresse für die ausgewählte Domain ein die für das ausgewählte Postfach erstellt werden soll.

Fertig !!! Man könnte auch sagen:

Eine neue Mail Adresse ist geboren :-)

Sofort nach der Einrichtung werden Mails mit der angegebenen Adresse im ausgewählten Postfach entgegengenommen.

Leider ist es nicht Möglich (wenigstens nicht wenn man ein P1 Konto) hat die Primäre Mail Adresse des Postfach an dieser Stelle zu ändern.

Wie man dies doch machen kann, werde ich in einem der folgenden Beiträge dieser kleinen Artikelserie Office365 zeigen.

Aber nun erst mal viel Spaß mit Office365 und der E-Mail Adresse der eigenen Domain.

Posted in Tips und Tricks, Wissenswert | Tagged , , | 2 Comments

SQL Server – Nach Neuinstallation SQL Server Express auf Dev Rechner Fehler mit DateTime Formaten

Ich will hier kein riesen Fass zum Thema SQL DateTime Formate aufmachen, dazu gibt es schon ganz viele Fässer im Internet, die das ganz ausführlich beschreiben.

In erster Linie geht es mir in diesem Artikel darum, mir selbst eine Nachricht zu hinterlassen, was ich beim nächsten mal machen muss, wenn ich ein solches Problem nochmal habe.

Eventuell hilft der Artikel auch mal jemand anderem, der das gleiche Problem hat, wie das, welches ich nun kurz beschreibe.

Hier nun das Problem:
Nach der Einrichtung eines neuen Entwickler Rechners, natürlich mit ein wenig aktuelleren Programmversionen als es auf dem bisherigen Rechern der Fall war, bekomme ich beim Versuch eine Windows Forms Anwendung[*1] aus Visual Studio heraus zu Debuggen Fehlermeldungen, wenn ich auf die lokale Datenbank die ich auf einem SQL Server Express 64 BIT, auf dem Rechner installiert habe, zugreifen möchte.

Das Programm läuft jedoch einwandfrei wenn ich Remote auf einen anderen SQL Server zugreife.

Da ich die lokale Datenbank aus einem aktuellen Backup des Servers erstellt habe auf dem es per Remote Zugriff keine Problem gibt, schließe ich schon mal aus das meine Datenbank selbst das Problem ist.

Die Fehlermeldung lautet wie folgt:

{“Bei der Konvertierung eines varchar-Datentyps in einen smalldatetime-Datentyp liegt der Wert außerhalb des gültigen Bereichs.”}

Probleme mit der Konvertierung von DateTime Werten, deutet auf ein Problem mit falschen Formaten hin. Die Standard Formate sind abhängig von der verwendeten Sprache.

Auf dem Rechner habe ich entgegen der bisherigen Installationen eine englische SQL Server Express Version installiert und nicht wie sonst einen deutsche Version.

Sowohl auf dem Produktionsserver des Kunden als auch auf meinem “echten” Server ist aber der SQL Server als Deutsche Version installiert.

Soll das mein Problem sein? (Und es soll sich heraus stellen, dass mein Problem wenigstens damit zusammenhängt)

Mit dem Befehl

SELECT @@LANGUAGE

kann man die aktuellen Spracheinstellungen der aktuellen Verbindung abfragen.

Die Abfrage auf meinem lokalen SQL Express Server ergibt als Antwort English.

Eine Abfrage auf den “echten” SQL Servern ergibt jeweils Deutsch.

Bingo, da liegt das Problem. Doch wie kann ich das ändern, bzw. was ich muss ich da überhaupt ändern.

Ich muss die Standard Sprache (Default Language) des SQL Login (Benutzer) ändern.

Das kann am einfachsten über die Login Eigenschaften mit dem SQL Server Management Studio machen.

Nun möchte ich aber vermeiden, dass beim nächsten Benutzer den ich anlege wieder die “für mich” falsche Standardsprache des Benutzers hinterlegt wird.

Die Standardsprache kann man ebenfalls mit dem SQL Server Management Studio ansehen und auch ändern.

Hierzu öffnet man die Server Eigenschaften indem man im SQL Server Management Studio im Object Explorer auf dem Knotenpunkt des Server mit der rechen Maus das Kontextmenü öffnet und dort das Eigenschaften (Property) Fenster öffnet.

Und dort stellen wir die Default Language von English auf German um. Und schon wird beim nächsten Benutzer den man anlegt die “richtige” Standardsprache für den Benutzer hinterlegt.

Natürlich kann man auch diese Einstellungen per SQL Befehle ausführen, aber wie ich bereits am Anfang sagte, ich möchte hier kein Riesen Fass öffnen, und es gibt ganz viele die sich mit dem SQL Server besser auskennen als ich.

Eventuell ist ja ein Leser des Berichtes so SQL fit und kann die SQL Befehle oder einen direkten Link zu den Befehlen als Kommentar hinterlassen.


[*1] ja die gibt es noch und diese von der ich hier sprechen ist auch schon einige Jahre alt, bzw, wird seit Jahren immer weiter entwickelt

Posted in Development, Tips und Tricks | Tagged , , , , | Leave a comment

Office365 – Eigene Domain nutzen ohne die Microsoft DNS Server zu verwenden

Nachdem (fast) jeder über Office365 spricht, habe ich mich dazu entschlossen, wenigstens in einem größeren Testbetrieb zu versuchen Office365 für meine Mail und Lync Aufgaben zu verwenden.

In dieser Artikel (Serie) werde ich Stück für Stück über die Fallstricke und Problem die dabei auftreten berichten.

In diesem ersten Artikel geht es um die Verwendung einer eigenen Domain.

Aber eben nicht wie es sich Microsoft vorstellt, sondern so wie ich es zur Umsetzung meine Anforderungen benötige. Und dazu gehört auf jeden Fall “nicht”, dass ich die gesamte Domain in Microsoft Hand und deren DNS Server übergeben möchte.

Nachdem man den die Domain Verifizierung durchgeführt hat, möchte Microsoft, dass man als Primärem und Sekundären DNS Server für sein Domain die beiden nachfolgenden Server angibt

  • ns1.bdm.microsoftonline.com
  • ns2.bdm.microsoftonline.com

Damit würde man aber die komplette DNS Verwaltung nur noch über die Office365 Verwaltung vornehmen können.

Man könnte dann über den Verwaltungsbereich –> Domänen –> DNS-Manager zwar weitere Host (A) und CNAME Einträge anlegen, doch was ist wenn man das nicht möchte und eigentlich nur die Mail (Exchange) und eventuell den Lync Dienst aus Office365 verwenden möchte.

Und genau dass möchte ich aber nicht, da ich all meine Domains auf meinen eigenen DNS Servern verwalte und das möchte ich auch für die Domain, welche ich als Mail Domain für Office365 verwende, in Zukunft weiter tun.

Also muss eine andere Lösung her, und diese sieht wie folgt aus:

Man verfährt zuerst einmal wie es Microsoft vorgibt und zwar bis an die Stelle, wo Microsoft einen dazu auffordert den primären und den sekundären DNS Server seiner Domain an die beiden Microsoft Server zu übergeben.

Anstelle die Kontrolle komplett an Office365 zu übergeben ändern bzw. erweitern wie lediglich die Einträge unseres aktuell verwendeten DNS Server wie folgt:

Für Mail Funktionalität an Office365 zu übergeben benötigt man folgenden Einträge:

MX-Eintrag:

SPF-Eintrag (Sender Policy Framework)

CNAME-Eintrag

Und wer auch den Lync Service nutzen möchte, der benötigt noch folgende zusätzlichen Einträge:

SRV-Eintrag _sip

SRV-Eintrag _sipfederationtls

Nachdem diese Einstellungen im DNS Server vorgenommen wurden, werden die Mails für die Domain ihrportal.de an Office365 gesendet und man kann mit der Domain auch den Lync Service verwenden.

Nicht vergessen, darf man aber, in der Verwaltung von Office365 noch die E-Mail Adressen dem Benutzer als zusätzliche E-Mail Adresse einzurichten.

Ich kann schon mal hier nachfolgende Stichworte erwähnen, bei welchen gleich die nächsten Probleme enstehen.

  • Primäre Mail Adresse
  • Sende Als

Aber dazu später sicherlich noch mehr.


Mehr aus der Serie Office365

Einrichtung Mail Adressen bei Verwendung eigener Domain

Posted in Tips und Tricks, Wissenswert | Tagged , , | 2 Comments

Python leicht zu durchschauen – These oder Wirklichkeit ?

Gestern Abend habe ich (als .NET Programmierer) mir einen Vortrag über Python, eine der neuen Hype Sprachen, angeschaut.

Hiefür vielen Dank an Rainer Schuster, der im Rahmen des wöchentlichen ONLINE Stammtisches der .NET Online Usergroup, diesen Vortrag gehalten hat.

Ich hatte mich mit dieser Programmiersprache bisher noch gar nicht auseinander gesetzt, so dass ich mir, nachdem ich mit den gestrigen Vortrag angesehen habe, heute noch ein wenig mehr Informationen besorgt habe um evtl. den Hype um diese Sprache besser verstehen zu können.

Vorweg, kann ich schon mal sagen, dass mir das nicht gelungen ist, und ich nicht verstehen kann, was an einer interpretierten Sprache ohne Verwendung von Klammern so viel besser sein soll, als bei anderen Sprachen die nicht interpretiert werden müssen, und Ihre Konstrukte mithilfe von Klammern darstellt.

Auf diesen Satz mit den Klammern komme ich weil unter anderem über Python folgendes Gesagt wird:

Leicht zu durchschauen

Python hat noch einen weiteren, für Anfänger interessanten Aspekt: Die Syntax der Sprache wird weniger von Klammern als von Zeilenumbrüchen und Tabulatoren bestimmt. Man erkennt schnell, wie das Programm aufgebaut ist und gewinnt auch bei Programmen anderer Entwickler schnell einen Überblick.

Was ist denn an diesem Quellcode leichter  zu verstehen:

for i in range (10):
 print i
 print "zähle noch
for i in range (10):
 print i
print "Hallo"

Als an diesem (Beipiel C# Code)

for (int i = 0; i < 10; i++)
{
    Console.Write(i);
    Console.Write(@"Zähle noch")
}
for (int i = 0; i < 10; i++
{
    Console.Write(i);
}
Console.Write(@"Hello World");

OK OK OK,

das ist nicht alles, Python ist (Hier Argumente von Python Jüngern):

  • Open Source
  • Auf einigen (vielen) Plattformen (darunter auch ein paar exotische) verfügbar
  • Von vornherein auf Objektorientierung ausgelegt (Welchen Vorteil das auch immer mit sich bringen soll)

Auf der anderen Seite muss man doch aber auch ganz klar sehen, wen Python als Platzhirsch ansieht:

Das sind PHP und Pearl, nicht gerade die klassischen .NET Sprachen

Ist Python also die Sprache der Zukunft für uns .NET Entwickler?

Ich denke nein.

Es wird zwar gesagt, man kann mit Python alle arten von Programmen schreiben kann, das wird wohl auch nicht falsch sein.

Aber möchte ich demnächst

  • Desktop Applikationen
  • Web Portale
  • Web Services
  • Windows Dienste
  •  WP7 Apps
  • Android Apps

mit Python entwickeln.

Ich denke, dass ich das nicht möchte. Mir graust sogar davor wenn mir jemand sagen würde er hätte vor mit Python (einem Interpretativen Sprache) einen Windows Dienst, einen Mail Server oder einen Web Service zu schreiben.

Ich bin mir nicht sicher und es lässt Platz für Spekulationen und vermutlich auch für heiße Diskussionen , aber ich denke, dass Python wohl eher im nicht Windows Umfeld seinen rechten Platz hat.

Ich möchte zum Schluss noch eines anmerken:

Auch wenn .NET in den nächsten Jahren an Gewicht verlieren, und das ganze mehr in Richtung HMTL 5, 6 oder 7 zusammen mit JavaSript oder was für einer, mehr oder weniger funktionalen oder prozeduralen Sprache schwenken könnte, werde ich als heutiger .NET Entwickler vermutlich eher in diesen heute noch nicht endgültig abzuzeichnenden Bereich, als zu Python wechseln.

Posted in Allgemeines | Tagged , , | 17 Comments

Google+ – Wer will noch mal, wer hat noch nicht!

Google+ ist nun seit mehreren Wochen ONLINE und so gut wie aus dem Beta Stadium heraus.

Ich finde zwar, dass noch einige Dinge fehlen, aber für ernsthaften Gedankenaustausch, Problemlösung und Diskussionen aller Art, mit Kollegen Freunden und Gleichgesinnten, bietet Google+ aber auch jeden Fall die bisher beste Lösung an.

Nun hat Google seit eingen Tagen das Netzwerk etwas mehr geöffnet und jeder der bereits einen Google+ Account hat, kann 150 weitere Einladungen verschenken.

Entweder, indem man einen Invite an eine E-Mail Adresse sendet oder sei einigen Tagen neu, indem man einfach auf einen von Google freigegeben Link klickt.

Und genau diesen Link möchte ich hier interessierten zur Verfügung stellen.

Wer also noch keinen Google+ Account hat und gerne einen hätte, der kann sich diesen einfach durch anklicken des nachfolgenden Link erhalten.

Das sollte 150 mal funktionieren, wobei ich denke dass mittlerweile die meisten, wenigsten aus meinem Umfeld und somit auch die Leser dieses Blogs, bereits einen Google+ Account haben und daher dieser Link recht lange noch genügend Invites zur
Verfügung stellen sollte.

So hier nun der Link

Google+ Einladung hier klicken

Man sieht sich dann auf Google+

Mich findet man übrigens unter folgendem Link auf Google+

http://gplus.to/schelianhp

Posted in Allgemeines, News | Tagged | Leave a comment

SQL Server Management Studio – Select Top X und Edit Top X Beschränkung

Im Microsoft SQL Server Management Studio (SQL Server 2008) werden im Kontextmenü zu Tables (Tabellen) und Views (Sichten) die beiden nachfolgenden Funktionen angeboten:

  • Select Top 1000 rows (Oberste 1000 Zeilen auswählen)
  • Edit Top 200 rows (Oberste 200 Zeilen bearbeiten)

Über den Sinn oder Unsinn warum man in einer View die Möglichkeit der Bearbeitung angeboten bekommt, möchte ich an dieser Stelle nicht weiter sprechen.

Nun ist es aber so, dass mich, diese Einschränkung stört!

Wenn ich eine Tabelle oder Sicht angezeigt bekomme,  möchte ich diese mit allen Datensätzen und nicht nur mit den ersten 1000 angezeigt bekommen.

Das gleich gilt übrigens auch für die Bearbeitung.

Nun gibt es, “Microsoft sei Dank” die Möglichkeit, diese Einschränkung in den Optionen zum SQL Server Management Studio einstellen zu können.

Diese Option finden wir unter:

Tools -> Options -> SQL Server Object Explorer

oder für die eingefleischten Deutsch Programm Anwender:

Extras -> Optionen -> Objekt-Explorer von SQL Server

Dort finden wir  unter Table and View Options (Tabellen- und Sichtoptionen)

Die beiden Einträge:

Englische Version Deutsche Version

Nun kann man diese Werte beliebig ändern.

Oder wenn man wie ich keine Einschränkung haben möchte (alle Datensätze), kann man den Wert 0 eintragen.

Dann sieht das Kontextmenü wir folgt aus:

Posted in Datenbank, Development, Tips und Tricks, Tools | Tagged , , | Leave a comment

StyleCop – Manchmal muss man auch Regeln brechen – Rule Suppressions

Jemand, der wie ich, StyleCop zur Einhaltung und Durchsetzung von Coding Styles einsetzt, versucht im allgemeinen möglichst viele der vorgegebenen Regeln aktiviert zu lassen und beim schreiben von Source Code diese Regeln um und einzusetzen um einheitlichen Source Code zu produzieren.

Je nach Einsatzgebiet, globalen Vorgaben oder Absprachen der Entwicklerteams kann es natürlich vorkommen, dass einzelne Regeln generell deaktiviert werden.Dies sollte dann aber wirklich gut überlegt sein, und auch nicht ständig geändert werden und sozusagen zum eigenen Regelwerk werden.

Nun kann es aber trotz dem größten Willen alle aktiven Regeln einzuhalten, an der einen oder anderen Stelle dazu kommen , dass man Code schreibt, der in diesem speziellen Fall genau so gewünscht ist,  aber so wie er geschrieben wurde gegen eine Regel verstößt.

Wenn man ein Tool wie StyleCop einsetzt, dann ist dass Ziel das ein Projekt ohne StyleCop Warnungen durchläuft. Also ohne einen Bruch der Regeln. Wenn aber an einer bestimmten Stelle bewusst eine Regel gebrochen wird, dann sollte dies Möglich sein, sollte aber genau dokumentiert sein.

Um diesem Umstand gerecht zu werden, gibt es die Möglichkeit bestimmte Regeln auf verschiedenen Ebenen zu unterdrücken.

Mit Ebenen sind hier jede Art von Code Elementen gemeint wie:

  • Klassen
  • Methoden
  • Felder
  • Eigenschaften
  • usw.

Doch zuerst möchte ich mal ein solches Beispiel zeigen, bei dem StyleCop eine Warnmeldung ausgibt, ich aber den Code aus genau so und nicht anders schreiben möchte. Wir müssen an dieser Stelle nicht über den Code diskutieren, da er hier lediglich als Beispiel dienen soll.

Hier nun die gewollte Code Variante, die aber von StyleCop angemeckert wird:

string cmd = new StringBuilder("PORT ").
  Append((short)hostBytes[0]).Append(",").
  Append((short)hostBytes[1]).Append(",").
  Append((short)hostBytes[2]).Append(",").
  Append((short)hostBytes[3]).Append(",").
  Append((short)portBytes[0]).Append(",").
  Append((short)portBytes[1]).ToString();
 

StyleCop gibt bei diesem Code die nachfolgenden Meldungen aus:

StyleCop kommt hier nicht mit der Aufteilung der Methodenaufrufe auf mehrere Zeilen klar.

Ich möchte aber auf keinen Fall den folgenden Code in meinem Source Code haben, der würde zwar den Ansprüchen von StyleCop entsprechen aber nicht meinen.

string cmd = new StringBuilder("PORT ").Append((short)hostBytes[0]).Append(",").Append((short)hostBytes[1]).Append(",").Append((short)hostBytes[2]).Append(",").Append((short)hostBytes[3]).Append(",").Append((short)portBytes[0]).Append(",").Append((short)portBytes[1]).ToString();

Alternativ würde StyleCop auch mit dem nachfolgenden Code zufrieden sein. Doch den möchte ich auch nicht.

StringBuilder stringBuilder = new StringBuilder("PORT ");
stringBuilder.Append((short)hostBytes[0]);
stringBuilder.Append(",");
stringBuilder.Append((short)hostBytes[1]);
stringBuilder.Append(",");
stringBuilder.Append((short)hostBytes[2]);
stringBuilder.Append(",");
stringBuilder.Append((short)hostBytes[3]);
stringBuilder.Append(",");
stringBuilder.Append((short)portBytes[0]);
stringBuilder.Append(",");
stringBuilder.Append((short)portBytes[1]);
stringBuilder.ToString();
string cmd = stringBuilder.ToString();

Wenn ich also dich den Code verwenden möchte den StyleCop angemeckert ohne das dadurch der Code angemeckert wird, muss ich StyleCop dazu bringen genau an dieser Stelle die Meldungen zu unterdrücken.

Hierzu verwenden wird aus dem NameSpace System.Diagnostics.CodeAnalysis ein Attribut mit dem Namen SuppressMessage und packen dieses Attribut an die Methode, Klasse oder was auch immer, um die StyleCop Regel genau an der gewünschten Stelle zu unterdrücken.

Nähere Informationen zur Verwendung der “Rule Suppression” für StyleCop findet man hier auf der Codeplex Seite von StyleCop

Nun aber das Beispiel anhand einer Methode um die StyleCop Meldungen für diese Methode zu untedrücken.

[SuppressMessage("StyleCop.CSharp.SpacingRules", "SA1019:MemberAccessSymbolsMustBeSpacedCorrectly")]
internal static string TestRule(byte[] hostBytes)
{
    string cmd = new StringBuilder("PORT ").
        Append((short)hostBytes[0]).Append(",").
        Append((short)hostBytes[1]).Append(",").
        Append((short)hostBytes[2]).Append(",").
        Append((short)hostBytes[3]).Append(",").ToString();

    return cmd;
}

Wobei fogendes gilt:

Für die StyleCop Regeln kommen folgende Kategorien in betracht:

  • StyleCop.CSharp.DocumentationRules
  • StyleCop.CSharp.LayoutRules
  • StyleCop.CSharp.MaintainabilityRules
  • StyleCop.CSharp.NamingRules
  • StyleCop.CSharp.OrderingRules
  • StyleCop.CSharp.ReadabilityRules
  • StyleCop.CSharp.SpacingRules

Als Rule ID muss die jeweilige Rule ID bestehend aus der Nummer und dem Text ab besten aus dem Rules Konfigurations Bereich des SyteleCop Add In herause gelesen werden. (Siehe nachfolgende Abbildung)

Posted in Allgemeines | 7 Comments

DotNetNuke 6.0 Final Release – Ein letztes großes VB.NET Projekt wird zu Grabe getragen

Mit dem Finalen Release 6.0 des Open Source CMS Frameworks DotNetNuke wird unter anderem auch eines der letzten großen VB.NET Open Source Projekte sein Ende finden.

Da eine Migration eines DotNetNuke 5 Portals nach 6.0 keine größeren Umstände bereiten sollte, ist zu vermuten und auch zu hoffen, dass mit der Version 5.6.3 die letzte VB.NET Version von DotNetNuke veröffentlicht wurde und die zukünftige Entwicklung komplett auf Basis der C# Version fortgeführt wird.

Die Highlights sind:

  • Umstellung des Framework von VB.NET auf C#
  • Die UI/UX wurden komplett überarbeitet (wem es gefällt)
  • Windows Azure kompatibel
  • SQL Azure kompatibel

DotNetNuke 6 kann direkt über das Open Source Community Portal Codeplex heruntergeladen werden.

Hier geht es direkt zum Download

Posted in News, Open Source | Tagged , , , | Leave a comment

DotNetNuke 6 RC (Release Candidate) steht zum Download bereit

Nach 8 Monaten Entwicklungszeit steht nun seit Gestern Abend der Release Candidat der Version 6, der ersten C# Version von DotNetNuke zum Download zur Verfügung.

Der Release Candidate hat die Build Nummer 2962 und kann auf www.codeplex.com heruntergeladen werden.

Hier geht es direkt zum Download auf Codeplex

Posted in News, Open Source | Tagged , , , , | Leave a comment