Namics erfolgreich Yammer zertifiziert.

YCEPP Badge

Wir freuen uns, bekannt zu geben , dass Bernd Langkau und Vanessa Malke  die Zertifizierungen des Yammer Customer Engagement-Partner-Programm (YCEPP) erfolgreich abgeschlossen haben! Dieses invite-only -Programm dient zur Ausbildung und Zertifizierung wichtiger Partner, um Kunden noch besser bei der Einführung … Weiterlesen

Resource Management mit WinRT

Resource Management ist ein Werkzeug zur Übersetzung von Texten in unterschiedliche Sprachen. Vielfach werden nicht nur GUI-Texte übersetzt, sondern auch Fehler- und Statusmeldungen aus dem Programmcode. Dieser Artikel beschreibt, wie grundsätzlich das Resource-Management für das GUI funktioniert und wie eine Lokalisierung für Code-Komponenten implementiert werden kann.

GUI Lokalisierung

WinRT bietet in Bereich GUI-Lokalisierung bereits heute zahlreiche Features an. So können die Texte im Ordner [WinRT GUI Projekt]\strings\[Sprach-Code] als resm-Files abgelegt werden. Die resm-Files sind im selben Format wie die aus .NET bekannten resx-Files aufgebaut.

Gui Lokalisierung

Eine Referenz über die Sprach-Codes und deren Bedeutung findet sich unter http://msdn.microsoft.com/en-US/library/windows/apps/hh965324.aspx.

Im WPF XAML-Code werden die Texte anschliessend mit x:Uid-Attribut eines beliebigen Controls referenziert. Der Compiler verknüpft anschliessend die Attribute des Controls mit den Texten aus dem referenzierten Sprach-File:

Die Sprachumschaltung zwischen den verschiedenen im \strings\ Ordner abgelegten Sprachen kann über die Systemsteuerung -> Sprache getestet werden.

Die WPF Lokalisierung ist in der MSDN unter http://msdn.microsoft.com/library/windows/apps/Hh965329(v=win.10).aspx detailliert beschreiben.

Der eigene Weg für Code-Lokalisierung

Weniger zahlreich sind die gebotenen Features im Bereich Code-Lokalisierung. Hier muss für eine wartbare Lösung selbst Hand angelegt werden, da, die aus dem .NET bekannten resx-Files, mit dem Compile Time Code Generator den Weg ins WinRT noch nicht gefunden haben. Daher ist hier ein möglichst .NET ähnlicher Weg anzustreben, da anzunehmen ist, dass entsprechende Features zu einem späteren Zeitpunkt noch nachgeliefert werden.

Dabei stellt sich die Frage, warum Code-Fragmente wie beispielsweise Fehlermeldungen überhaupt lokalisiert werden, da die englische Version der Meldung zumeist weit aussagekräftiger ist. Die Antwort darauf ist ähnlich wie bei der Benutzerschnittstelle: Auch Fehlermeldungen bergen das Risiko, bis zum Benutzer vorzudringen. Gerade bei wiederverwendeten Komponenten sollten die Texte also in separaten Files abgelegt werden, da Apps für verschiedene Sprachen und Regionen erstellt werden können.

Der einfachste Weg, die Code-Resourcen zu implementieren ist das Anlegen eines resm-Files und anschliessendes referenzieren über den Resource-Manager. Dies geschieht beispielsweise wie folgt:

Dies hat allerdings zum Nachteil, dass die Resources über Strings lose an die Eigenschaft im  resm-File gebunden werden. Bei einem Rename der Resource von resourceToFind auf resourceToRetrieve muss an allen Stellen im Programm-Code per Search & Replace der String „Resources/resourceToFind“ ersetzt werden. Falls nur eine Stelle vergessen wird, kann das Programm zur Laufzeit abstürzen.

Aus diesem Grunde ist es empfehlenswert, die Resourcen möglichst typisiert und automatisiert aus dem resm-File auszulesen und in ein Code-File als Property zu übertragen. Dies wird mittels Visual Studio .tt (T4) Templates erreicht. Sie finden eine Auflistung der T4-Template-Möglichkeiten unter http://msdn.microsoft.com/en-us/library/vstudio/dd820620.aspx . Das folgende C# Code-Schnipsel des Templates stellt dies sicher:

Die Resourcen werden aus dem angegebenen ReswFile geladen und damit anschliessend die C# Properties generiert. Die Variable resources muss im Vorfeld, wie im Resource-Manager Beispiel oben beschrieben, belegt werden:

Der einzige Nachteil dieser Lösung ist, dass der Entwickler den Template-Run manuell ausführen muss:

Mehr Informationen über das Resource-Management in WinRT können Sie unter http://msdn.microsoft.com/en-us/library/windows/apps/jj552947.aspx nachlesen.

Fazit

WinRT  bietet eine gute Lokalisierung im UI Bereich. Für die Lokalisierung des Programm-Codes muss sich der Entwickler selbst eine Lösung suchen, da die gebotenen Features noch nicht vollständig dem heutigen .NET Standard entsprechen.

Das Beispiel oben hat aufgezeigt, dass das Nachrüsten der Code-Lokalisierung keine grossen Aufwände mit sich bringt. Das Template-File einmalig mit minimalem Aufwand zu erstellen ist sicherlich eine lohnenswerte Investition – in der Hoffnung, dass beim nächsten WinRT Release eine ausgereifte Code-Lokalisierung mitgeliefert wird.

Logging für Windows Store Apps mit WinRT

Logging ist in der Programm-Entwicklung eine der wesentlichsten Methoden zur Fehlerverfolgung. So nimmt die Bedeutung von Logging mit den neuen .NET 4.5 Features (speziell async/await) zu, da im asynchronen Programmcontext bei unsachgemässer Implementation nicht deterministische Fehler „geschluckt“ werden können. Die Nachverfolgung solcher Fehler gestaltet sich, ohne Protokollierung, als äusserst schwierig.

Was WinRT bietet

Als rudimentäres Logging-Feature hat Microsoft zu diesem Zweck in WinRT die Event Tracing for Windows (ETW) Library für das Mobile- und Desktop-App Framework integriert. Dieses entfaltet vor allem für kleinere Entwicklungen seine Stärken, ist allerdings für den Einsatz von grösseren und komplexeren Lösungen nur bedingt geeignet. Es fehlen markante Features wie das Uploaden der Log-Files auf einen zentralen Server. Zusätzlich enthält das von Microsoft gebotene Beispiel Multithreading-Probleme, welche beim Save des Log-Files zum Tragen kommen können.

MetroLog kann Abhilfe schaffen

Das MetroLog Framework als OpenSource Projekt nimmt sich dieser Problematik an. Dieses basiert auf NLog und bietet neben der klassischen Logging-API auch den besagten Upload zum Server an. Weiterhin bietet MetroLog die Features zum Loggen von Daten ins ETW oder in eine lokale SQL-Lite Datenbank. Ein Beispiel zu MetroLog findet sich unter: https://github.com/mbrit/MetroLog/blob/master/Samples/ConsoleSample/Program.cs

Wunsch-Framework: log4net und noch mehr…

Persönliche habe ich eine Vorliebe für das log4net Framework. Dieses wurde bereits bei diversen .NET Projekten eingesetzt und ist entsprechend in der .NET Community etabliert. Ebenfalls setzen bereits bestehende interne Basis-Funktionalitäten log4net ein. Diese Funktionalitäten sollen nach und nach zu WinRT migriert werden, ohne hierbei ein grosses Rewrite zu generieren.

Leider exisitiert im Moment noch keine Implementierung des log4net Frameworks für WinRT. Aus diesem Grunde heisst die Lösung im Moment: Facade-Pattern der GoF. Mit Hilfe dieses Patterns, kann die effektive Logging-Implementierung im Nachhinein ohne Probleme ausgetauscht und so beispielsweise durch log4net Komponenten ersetzt werden.

Die Anwendung der Facade (Klasse Logger<T>) sieht wie folgt aus:

Durch die Facade kann ebenfalls die Logging-API minimiert werden. Im Beispiel werden direkt die Logger<ExampleClass>-Methoden aufgerufen. Diese loggen anschliessend die Mitteilung im Namen der Klasse ExampleClass. Der Compiler sorgt implizit dafür, dass genau eine Instanz des Templates Logger<ExampleClass> existiert, daher muss der Logger nicht explizit in jeder Anwender-Klasse instanziiert werden. Dank der Verwendung des Compiler-Features müssen auch keine Performance-Einbussen hingenommen werden.

Die Implementation der Logger<T> sieht im Prinzip sehr einfach aus:

Fazit

WinRT bietet im Moment erst rudimentäre Logging-Funktionalitäten. Dafür stehen Frameworks wie MetroLog zur Verfügung. Wer sich allerdings an ein zukunftssicheres API binden möchte, ist gut beraten, eine eigene Entwicklung anzustreben.

Im Beispiel oben wurde auf einfache Art und Weise gezeigt, wie das Logging mit WinRT mit den heutigen Mitteln zukunftssicher implementiert werden kann. Sicherlich ist die gebotene Implementierung aus aktueller Sicht noch ausbaufähig, doch bietet sie einen Grundstein für den späteren Einsatz einer mächtigeren Library.

Informationsquellen SharePoint 2013

 Der folgende Artikel enthält eine Liste von Quellen zu SharePoint 2013 (aktuell vom 11.01.2013).

1. Microsoft Quellen

Die folgende Darstellung zeigt eine Übersicht über die Microsoft Quellen und deren Inhalt. Microsoft bietet zum Thema SharePoint 2013 drei Hauptseiten an: Für It-Professionals das Technet, für Developer MSDN und eine SharePoint Produkte Site für Consultants und Consumer.

 

 

 

Das Technet beinhaltet bereits eine grosse Sammlung von SharePoint 2013 Artikeln, unter denen die Bereiche „What’s new?“, die „Plan-Worksheets“ und die Technischen Diagramme besonders zu erwähnen sind.

 

Die Wiki-Einträge sind aktueller Weise noch zu weiten Teilen auf SharePoint 2010 bezogen.

 

Im Forum Bereich muss nach „SharePoint 2013″ gesucht werden, das Resultat zeigt dann – eingeschränkt auf Foren – eine Anzahl von SharePoint 2013 Foren.

 Auch im Blog Bereich muss zuerst nach „SharePoint 2013″ gesucht werden und auf Blogs eingeschränkt werden. Die Technet Blogs enhalten IT Professional relevante Blogs von Microsoft Mitarbeitern.

 

Interessante Adressen im MS Technet
Technet Library Entry for SharePoint 2013
SharePoint for IT-Pros
SharePoint TechCenter
SharePoint Technet Wiki Portal
SharePoint IT Pro Blog
IT Pros Videos
IT Pros Learning Powerpoint Presentations
Changes from 2010 to 2013
Discontinued Features
Resources for IT Pros
Physical architecture and logical architecture of SharePoint 2013
Technical Diagrams

MS Technet Blogs
SharePoint Comic
To the SharePoint – SharePoint IT Pro Blog
Stefan Gossner Blog

 

MSDN enthält das für Entwickler interessante Material zu SharePoint 2013. Das Erstellen von Apps und die generelle Entwicklung von SharePoint Elementen wird hier von Microsoft dokumentiert.

 Auch für Developer existieren in MSDN Foren für SharePoint 2013. Um sie zu finden muss auf der Einstiegsseite der MSDN Foren nach „SharePoint 2013″ gesucht werden und das Resultat auf „Forums“ eingeschränkt werden.

 Blogs für Developer finden sich mit dem Suchbegriff „SharePoint 2013″ und einer Einschränkung auf „Blogs“. Die Blogs sind von Microsoft Mitarbeitern und sogenannten „Most Valuable Professionals“, also von Microsoft anerkannten externen SharePoint Spezialisten.

 

Interessante Adressen im MS Developer Network (MSDN)
MSDN Entry for SharePoint 2013 Developers
SharePoint Development Overview
SharePoint Server Developer Portal
MSDN SharePoint 2013 Evaluation Center
Resources for SharePoint 2013 Developers
SharePoint Dev Blog
SharePoint Dev Forums
MSDN SharePoint Team Blog
Choose the right API set in SharePoint 2013
.NET client class libraries in SharePoint 2013
Apps for SharePoint Overview

Andere interessante Microsoft Adressen
SharePoint Product WebSite
SharePoint Team Blog
Official Twitter Account
Office 365 Community
SharePoint Conference 2012
SharePoint Bereich in der Microsoft Office WebSite (Benutzer Informationen)
Neuerungen in Microsoft SharePoint Server 2013

2. Andere Quellen

Neben Microsoft als Quelle existieren im Internet viele Sites, die sich SharePoint 2010/2013 als Thema widmen. Hier eine kurze Zusammenstellung.

3rd Party Blogs
2xx SharePoint Blogs – updated hourly
25+ SharePoint Bloggers to Follow
SharePoint Solutions Team Blog
SharePoint Joel (Joel Oleson’s Blog)
SharePoint MVP Blog – Andrew Connell
SharePoint Automation
Coll@bnet
Best SharePoint Blogs (List of Blogs – but only up to 2008)

3rd Party WebSites
Secrets of SharePoint
Go4Sharepoint
TopSharePoint
Top 25 SharePoint Influencers
Stackoverflow
NothingButSharePoint
Learning SharePoint
SharePoint Saturday
Harbar Net

Cloud Computing und Microsoft Online Services

An den diesjährigen Tech days in Basel letzte Woche, war einer der Hauptthemen die Cloud Computing. Mit dem offiziellen Starttermin am 12.05.2010 von Office 2010 will Microsoft erstmals webbasierte Versionen seiner Bürosuite anbieten und damit vor allem die wachsende Konkurrenz durch Google abfangen. Vor kurzem haben die Redmonder den Cloud-Dienst Azure als kommerzielles Produkt gestartet. 70 Prozent aller Microsoft-Mitarbeiter würden an Projekten rund um Cloud Computing arbeiten, so die Aussage von Beat Schwegler von Microsoft Western Europe.

Dass durch Cloud Computing jedermann den sofortigen Zugang zu hochskalierbaren Computerressourcen und diese ohne vorhergehende finanzielle Investitionen erhält, fand ich sehr interessant. Die Märkte, die sich immer schneller verändern, gehören zu den zentralen Herausforderungen, denen sich Unternehmen stellen müssen. Erfolg entsteht, wenn Unternehmen frühzeitig Marktfenster erkennen und schnell darauf reagieren. Sie werden zu Thementreibern und Marktgestaltern. Organisation und Geschäftsprozesse sind deshalb in erfolgreichen Unternehmen auf Agilität und Flexibilität getrimmt. Genau diese Vorteile bringt die Cloud Computing im Bereich Hardware- und Softwareressourcen. Die Unternehmen können ihre Computerressourcen innerhalb kurzer Zeit erweitern und die Software die sie benötigen, mieten.

Apropos mieten, Microsoft lanciert mit BPOS(Business Productivity Online Suite) zugeschnittene Softwarepakete die Unternehmen übers Netz beziehen und mieten (online Services) können. Die BPOS umfasst dabei folgende Komponenten Exchange Online, SharePoint Online, Office Communications Online und Office Live Meeting.

Mit SharePoint Online, bietet Microsoft einen zentralen, integrierten Ort, an dem

– Mitarbeiter effizient mit Teammitgliedern zusammenarbeiten,
– Organisationsressourcen finden,
– ihre Website durchsuchen,
– Inhalte und Arbeitsabläufe verwalten und
– Berichte nutzen können,

um besser informiert Entscheidungen zu treffen. Basierend auf Office SharePoint Server 2007, ermöglicht es diese von Microsoft gehostete Lösung Mitarbeitern, benutzerdefinierte Teamwebsites und projektorientierte Websites für die Zusammenarbeit − einschliesslich gemeinsamer Nutzung von Dokumenten − einfach zu erstellen und zu verwalten. Microsoft handhabt Setup, Bereitstellung, laufende Wartung und Upgrades der SharePoint Server-Infrastruktur. Die IT-Mitarbeiter der Unternehmen sind dadurch weniger belastet und können vermehrt an wichtigen strategischen Initiativen arbeiten.

mein Fazit

Über Cloud Computing wird derzeit viel diskutiert, und das aus gutem Grund. Cloud Computing eröffnet Unternehmen potenzielle Wettbewerbsvorteile, die sich positiv auf das Geschäft auswirken: kürzere Zeiten bis zur Markteinführung, Services, die sich kurzfristig hoch- oder runterfahren lassen, sowie geringere vorab anfallende IT-Kosten, um nur einige zu nennen.
Der Markt verspricht sich vor allem Effizienz- und Kostenvorteile, wenn er seine Hardware- und Softwareressourcen nicht mehr selbst betreiben, sondern aus dem Internet als Service beziehen kann. Und tatsächlich adressiert Cloud Computing mit Microsofts Online Services – neben den technologischen Mehrwerten wie Skalierbarkeit, Performance etc. – vor allem Kostenreduktion und Flexibilität.

Seite 1 von 512345