Ilker Cetinkaya: FAKE Everywhere

One of my recent work areas was to improve the maintenance and automation of software builds. In this little blog I want to summarize the challenges, reasoning and insights I gained from the decision to implement all .NET build scripts using FAKE.


Our reasons to think about alternative build scripts were manifold. We had to support ~25 .NET Software repositories, ranging from desktop applications, system services, web services up to web applications. Our repository sizes vary a lot, ranging from a few KLOC up to a few MLOC, from dozens to hundreds of .NET projects. The majority of those repositories contained custom MSBuild build scripts, using specific tasks and even custom tasks. The remaining repositories built their software using PSake (Powershell) or Nant.

Our tactical roadmap requires us to heavily increase the number of repositories (and thus build units). Within just a few months, we would like to have at least ~100 repositories. On mid-term scale (~1 year) we target to have ~500 repositories, all of them requiring to have their own build and deployment scripts.

In past, a few brave developers started to build their systems using PSake for a very common reason: the infamous inflexibility of MSBuild. Although MSBuild is quite a powerful build system, it inherently has drawbacks due to the nature of using a declarative XML language. First and foremost, there is lack of flexibility. Both in terms of developing quick extensions as well as for custom solutions. A great level of customization is crucial for any build system since all software is different. Second, MSBuild does not by default have a suite of supplementary tools for specific, yet frequently encountered build concerns. It is a big pain with MSBuild to customize web application builds, let custom tools build images with timestamps, perform custom XDT transformations and many other things.

From my personal point of view, the biggest disadvantage of MSBuild builds is the sheer inabilitiy of being maintainable. The build scripts are not readable (hence: hard to comprehend) at all due to the overwhelming declarative XML ceremony and the "interesting" $() @() operators. Maintaining such an XML forest is like playing Mikado on a sailing boat in north sea.

PSake surely is a great improvement with regards to the above mentioned disadvantages we were facing using MSBuild. With PSake, clarity and flexibility were greatly improved. That is, PSake scripts are backed up by a full programming language (Powershell) and thus implicitly deliver great customization capabilities. But still, using PSake does come with quite a large cost. PSake in essence is not a build system, but a task runner. It just delivers the task infrastructure and their dependency management, nothing more. In consequence, PSake users often need to reinvent a lot of things which are obvious and very common in the context of .NET builds. Prominent examples are assembly versioning, code generation, test execution and many more.

We as software development department knew: there must be a better build system to satisfy our current needs and even help us in scaling our repositories up to 2000% of the initial build systems volume. That's how we started to be very interested in FAKE.


In evaluation phase, we deliberately chose FAKE. Simply because we had two engineers suggesting FAKE. They were the only developers by that time with (moderate) experience using FAKE. All other developers (4 Teams with 4-6 members) did not have any experience with FAKE. Even more, all of the developers being not familiar with FAKE did not know anything about F#, the underlying language for FAKE.

(Side note Most of them hardly know the F# language even by today.)

From our two FAKE experience sources, we got to know that FAKE could meet all our expectations. We wanted a build system that

  • is highly readable, thus easy to understand and maintain,
  • is very flexible in terms of customization and adding individual logic
  • is backed by a robust language with a well-supported infrastructure
  • is supportive with a library of common build tasks and procedures

Although we do have a very good level of trust for our team members, we wanted to assess FAKE as well. Our assessment especially was geared towards three aspects:

  1. Adoption: How simple is it to migrate existing build scripts and/or create new build scripts for total beginners?
  2. Maintenance: How much invest is required to maintain FAKE build scripts?
  3. Scalability: How easy it is to spread the build system to a reasonable number of software systems?

For two of three questions, we gained experience in past with other build systems (PSake and Nant), That is, we did have data to more or less correlate the "performance" of FAKE to other build systems and rank it according to our subjective environment.

Chapter 1: Adoption

In order to assess the simplicity of adoption, we took 2 C# repositories with different build systems (MSBuild and PSake) to port over to FAKE. The build script migration were done by pairs of developers. All of them with no prior experience in F# or FAKE. They got a quick introduction to FAKE only by reading the online documentation before migrating the scripts.

The complexity of both builds can be considered mildly moderate. Both of them having 10-20 projects, with need for the following fundamental build tasks:

  • building all C# source projects
  • setting a proper software version number
  • executing all unit tests
  • executing all integration tests
  • creating a Nuget package
  • publishing a Nuget package

We had repositories with comparable complexity were we already gained experience migrating from MSBuild to PSake and NAnt, with exactly the same setting on knowledge and capacity. Hence, we had a somewhat sufficient comparative context for our individual requirements.

  • PSake: Migrating from MSBuild to PSake took ~6 hours.
  • NAnt: Migrating from MSBuild to NAnt took ~10 hours.
  • FAKE: Migrating from MSBuild to FAKE took ~2 hours.
  • FAKE: Migrating from NAnt to FAKE took ~2 hours.

(Keep in mind that all migrations were made by absolute novice users.)

Apart of the pure time to migrate the scripts, we investigated on how the developers approached the migration. While the migration to PSake required nearly no lookup in PSake documentation, the FAKE migration made significant use of the online documentation. The reason for this is that PSake was quickly perceived to have no build tasks supplied. The migration pair then decided to utilize the command line tools directly. In contrast, FAKE was immediately perceived as a complete build system with a set of build tasks within.

Chapter 2: Maintenance

After this initial migration of a small subset of repositories, we kept on using FAKE in those repositories. We wanted to gain experience about the level of maintenance in terms of frequency (commits), effort (time) and complexity (comprehensiveness).

For that matter, we did not have any comparative settings with PSake or MSBuild. However, we already had a fair amount of experience maintaining MSBuild and PSake scripts. With very different results. The MSBuild maintenance can be pictured as infrequent (very few changes), effortful (time-consuming changes) and highly complex (barely readable). PSake on the other side of the river got a lot higher change frequency, is less effortful and moderately complex.

The maintenance situations we faced with FAKE were:

  • Run multiple test runners (MSpec, XUnit) alongside the existing NUnit tests
  • Compile multiple units in one repository (Client and Server components)
  • Add XML transformations to the build

For all three tasks we gained data for our three dimensions frequency, duration and complexity. It turned out that the change frequencies on FAKE build scripts were quite high. For the change duration, FAKE scripts surprisingly were more time-consuming than expected. With regards to complexity, the scripts partly got even simpler than before the maintenance change.

From a very subjective standpoint, we felt that

  • FAKE scripts were changed even more often than PSake scripts.
    MSBuild scripts got the fewest commits
  • FAKE script changes took longer than changing PSake scripts,
    but significantly less than changing MSBuild scripts
  • FAKE scripts kept the comprehension complexity very low, followed by PSake.
    MSBuild script complexity grew significantly with every change

Chapter 3: Scalability

This aspect is probably the most individual. So it does not make sense to even try to relate the widespread use of FAKE to any other widespread usage. Nonetheless, our experience might be worth sharing. FAKE was the first build system we decided to use for all of our .NET repositories. We went down this path after around 6 weeks of evaluation. While our total .NET repository count by that time was ~30 repositories, FAKE was just operating on 2 repositories. Our scaling strategy was quite simple: whenever someone works on a repository not having FAKE, he would migrate to FAKE. We managed to use FAKE for 80% of all our .NET repositories within 6 weeks. In total, the entire process of moving to FAKE and using it on the entire software development took ~12 weeks.

Interestingly, we experienced that the adoption was performed by the entire team rather than a few "experts" (mostly developers interested in functional programming). Even more, we observed that the fastest transitions towards FAKE were made by developers with no knowledge in functional programming at all.

Bonus Chapter: Coding Dojo

Albeit we do not have gathered any data about it, we do believe that one of the crucial adoption measures we made was a coding dojo entirely dedicated to FAKE. This coding dojo was performed on the second week of the FAKE evaluation. Before we held the dojo, we introduced all participants to FAKE by showing the examples from the website, replaying the examples in F# interactive and letting the participants read the documentation for a limited time-period.

Right after this introduction, we made a coding dojo with 3 groups, all of them free to choose any repository of their choice (either closed or open-source), trying to migrate the build script to FAKE within 90 minutes. For this dojo, we insisted in pair rotation (Randori), while we suspended the rule of TDD for this exceptional case. Two of the teams succeeded to migrate the build system of the (more or less complex) repositories. One team was so confident of the quality of their resullts that they even managed to make a complete pull request to repository owner.

What's not nice?

During the entire adoption phase, we did experience both beneficiary and misfortunate moments with FAKE. The most affecting hurdles we faced by that time were:

  • The documentation is complete, but not comprehensive.
  • Most error messages require (fairly solid) F# knowledge to understand.
  • The FAKE library API is perceived as inconsistent.
  • Task dependency definition is not easy to grasp for beginners.
  • Footprint of FAKE library is very large, although only a minor subset is used.

Of course, all of the above mentioned issues are very individual. We quite often received feedback that the documentation lacks examples and explanatory usage scenarios. An equally often mentioned hurdle is that error messages (mostly type errors) are quite hard to understand for people with no F# knowledge.

What's great?

On the flip side of things, we noticed a few positive effects we did not anticipate:

  • The learning curve was surprisingly low.
  • Type-safety on build script level is a huge advantage.
  • The FAKE library tasks are very stable and reliable.
  • F# was feared more to be incomprehensive than it turned out to be.

One of the most striking insights during the evaluation phase was definitely that using FAKE is not a matter of F# knowlegde, but really a matter of reading the documentation (and reading the most fundamental things about F#). All developers were able to create and change FAKE scripts. The second, not so obvious insight we gained was that type-safe build scripting is a big advantage. During all of our maintenance efforts, the F# compiler did assist with great precision in getting things right. This might not be a big deal for regular software development. However, for build scripting it is indeed a huge advantage. It lowered the error rate to close to zero, which was never achieved before using MSBuild or PSake scripts.


After the evaluation period, we realize with no big surprise that we definitely want to use FAKE instead of MSBuild or PSake. Our main arguments for using FAKE are:

  • FAKE brings clarity to build scripts with type-safety and easy notation
  • FAKE is by far the most readable and maintainable build system for .NET
  • FAKE ships with a large library of reliable build tasks
  • FAKE is easy to learn and comes with a good documentation

FAKE is a perfect match for us and I do want to encourage you to try FAKE. Chances are very high that FAKE will make your builds even more simple and reliable than they are today. If there can be any advice to be given for FAKE beginners, it surely is that FAKE is simple enough to learn in a very short time if you read the documentation and do the tutorial. To master FAKE in daily life, you don't need to learn F#, but need to understand the fundamental concepts of the F# language, such as value bindings, functions, core types and the type signature notation.

Conclusion: FAKE most probably is the best .NET build system of today.

Ralf Westphal: Praktische Führung

Es wird ja viel über Führung und Management geschrieben. Die einen sind dafür, die anderen dagegen. Aber was ist eigentlich die Aufgabe von Führungspersonen? Eine sehr gute Erklärung liefert aus meiner Sicht Reinhard K. Sprengers Buch “Radikal führen”. Danach hat Führung fünf Kernaufgaben: Zusammenarbeit organisieren - Klar, das ist der Ausgangspunkt. Verschiedene Aktivitäten müssen so “

Marco Scheel: Links for 2014-11-21 []

Ralf Westphal: Hacker-Tool für Gedanken

Wie soll ich wissen, was ich denke, solange ich es nicht aufgeschrieben habe? So geht es mir oft. Deshalb schreibe ich Blog-Postings und Zeitschriftenartikel und auch Bücher. Das Schreiben hilft mir beim Denken. Aber welches Werkzeug benutzen für das Schreiben? Für den Zeitschriftenartikel ist MS Word der Standard. Aber muss das so sein? Wie könnten Redaktion und Autor vielleicht noch besser

Thomas Bandt: JavaScript: Promises mit Mocha testen

Es sind die kleinen Dinge, die einem bei einer dynamischen Sprache wie JavaScript das Leben schwer machen können, wenn man nicht genau aufpasst.

Gestern habe ich für mein kleines Node-Demoprojekt begonnen, ein paar Tests zu schreiben. Die Wahl fiel hierbei auf Mocha als Testframework und zunächst Should, danach Chai für die “Assertions”. Chai deshalb, weil mir die Expect-Syntax besser gefällt, da sie auch mit Werten umgehen kann, die null oder undefined sind.

Jedenfalls habe ich mich auch dazu entschieden, asynchronen Code mit Promises (Q) zu schreiben und selbst wo möglich auf Callbacks zu verzichten.

Ein typisches System under Test sieht deshalb beispielsweise so aus:

(function(module) {
    "use strict";

    var Q = require("q");

    module.asyncFoo = function() {
        var deferred = Q.defer();

        setTimeout(function() {
            deferred.resolve("Hello World.");
        }, 100);

        return deferred.promise;

Die Methode asyncFoo() liefert ein Promise zurück, das nach 100 Millisekunden mit dem Wert “Hello World.” aufgelöst wird.

Mein erster Test hierfür sah so aus:

(function() {
    "use strict";

    var expect = require('chai').expect;

    describe("Demo", function() {
        var demo;

        before(function() {
            demo = require("./demo");

        it("returns Hello World", function() {
            demo.asyncFoo().then(function(result) {
                expect(result).to.equal("Hello World!");

Und hurra, er läuft durch und ist grün. Aber … man beachte das Satzzeichen. Eigentlich müsste er rot sein.

Mocha kann mit asynchronem Code umgehen, auch wenn es erst ma leine kleine Weile gebraucht hat, bis ich verstanden habe, dass der done()-Callback in die entsprechenden Methoden, in dem Fall it(), gesteckt werden muss … tut man das, wartet das Framework für jeden Test standardmäßig 2 Sekunden.

In diesen 2 Sekunden, die man auch hoch- oder runtersetzen kann, hat der Test Zeit, ausgeführt zu werden. Wichtig ist, dass am Ende der done()-Callback aufgerufen wird, damit das Framework weiß, dass die Ausführung beendet wurde.

Überschreitet man die Ausführungszeit oder ruft man den Callback nicht auf, gibt es glücklicherweise eine passende Exception, die einen darauf hinweist - das wird also nicht verschluckt.

So wird nun ein Schuh draus und der Test wird - korrekterweise - rot:

it("returns Hello World", function(done) {
    demo.asyncFoo().then(function(result) {
        expect(result).to.equal("Hello World!");

Doch die Fehlermeldung passt nicht: Der Test wird deshalb rot, weil der Timeout erreicht ist.

Denn dadurch, dass Chai einen Fehler wirft, da die Erwartung nicht erfüllt ist (! statt .), wird der done()-Callback nicht aufgerufen. Das bedeutet, dass jeder Test, der fehlschlägt, auf diese Art genau 2 Sekunden läuft und keine passende Fehlermeldung geworfen wird.

Abhilfe kann hier schaffen, den done()-Callback in die Catch-Methode des Promises zu stecken:

it("returns Hello World", function(done) {
    demo.asyncFoo().then(function(result) {
        expect(result).to.equal("Hello World!");

Sauberer wäre es zudem noch, statt then() done() zu verwenden, Zitat:

The Golden Rule of done vs. then usage is: either return your promise to someone else, or if the chain ends with you, call done to terminate it.

it("returns Hello World", function(done) {
    demo.asyncFoo().done(function(result) {
        expect(result).to.equal("Hello World!");
    }, done);

Wer kein Problem damit hat, noch eigene Erweiterungen einzubringen, die von den Standards der eingesetzten Frameworks abweichen, könnte den Aufruf auch noch rausziehen und so das Risiko minimieren, einmal done() zu vergessen.

function evaluateTestResult(promise, assert, done) {
        function(result) {

it("returns Hello World", function(done) {
        function(result) {
            expect(result).to.equal("Hello World!");

Das war zunächst intuitiv mein erster Schritt - nachdem es aber außer dem sicheren Aufruf von done() keinen weiteren Mehrwert bietet, werde ich erst mal die vorletzte Variante verwenden.

| Kommentieren | © 2014 Thomas Bandt

Sven Hubert: AIT goes Open Source

Following a request of our customers, we are glad to announce that we will host some of our free projects as open source software on GitHub! This way the projects can profit from a great community and the progress and releases become more transparent.

The first project we publish is the AIT EF Oracle Identity Patch (GitHub), which is also available as NuGet package.

AIT goes Open Source is a post from: AIT Blog

Sven Hubert: AIT stellt ausgewählte Projekte unter Open Source Lizenz

Wir freuen uns bekannt zu geben, dass wir einige unserer freien Projekte als Open Source Software auf GitHub bereitstellen. Damit folgen wir den Anfragen unserer Kunden. Durch diesen Schritt können die Projekte von einer großartigen Community profitieren und die Fortschritte und Releases werden transparenter.

Als erstes Projekt veröffentlichen wir den AIT EF Oracle Identity Patch (GitHub), welcher auch als NuGet-Paket erhältlich ist.

AIT stellt ausgewählte Projekte unter Open Source Lizenz is a post from: AIT Blog

Fabian Deitelhoff: Let Me Introduce: Demo Project for Bézier Curves

From day to day it is very frustrating to develop projects, stuff for my study and things like that and then… yes then… just let the source code rot in my code repositories. Or delete them right away because I know that I do not need those projects anymore. That’s very frustrating. And as Scott Hanselman wrote – dozen of others wrote that too – it’s time to publish those countless open source projects. That’s my new mindset and goal for all those hundreds thousands of lines of code. In whatever language I wrote them. Whatever technology and IDE I was using at that time. I try to publish all of those projects, separated into single blog post with some screenshots, code examples, explanations or whatever it take to show what I’ve done or tried to achieve :).

The Application

As already mentioned, the application was build just for demo purposes. As far as I remember as a side project to learn the calculation of bézier curves within the module “Mathematics III” in my Bachelor of Computer Science. That was in the end of 2010. The demo is implemented as an Windows forms application with a single split window and some controls in a toolbar. The two figures 1 and 2 shows some example curves created with the demo.

Fig. 1: Example bézier curve with four control points. Fig. 2: Example bézier curve with nine control points.

Through the buttons and the text field in the toolbar you can control some characteristics of the application itself or the calculated bézier curve. You can clear all visible control points on the drawing area, activate the real time calculation, connect the calculated points and change the control variable called t. The real time calculation means, that, if you drag a control point, the bézier curve gets instantly recalculated. The control variable t is the amount of points, that is calculated or in other words: how many points will create that curve, because every pixel of those bézier curves are calculated separately within a loop.

On the left side you can see all control points in the same order as they were created. Select them and hit delete to remove a control point. Or right click on a control point to delete this point.

That’s all. There’s nothing more in this demo application.

The Project

The project is divided into three Visual Studio projects. One as a startup project, another one for the GUI and last but not least a project for the business logic layer. Latter contains the calculation for the bézier curves.

There’s not NuGet package or other external dependencies. All is self implemented.

You can use Visual Studio to build the solution or the integrated build script called build.cmd. This script calls the fake.exe that is responsible for the complete build procedure. So this projects using the awesome FAKE build tool. And Paket is on board too, because the FAKE dependency is resolved with the Paket dependency manager that can handle NuGet packages.

The source code is available at GitHub.

Known Bugs

At this stage I’m not really aware of many bugs. Not because I’ve searched or tested a lot :). Just because I did not look very closely. The main reason is, that I tried to release this project as soon as possible. It’s waiting for four years within a dark and cold Git repository.

But I found a bug with a simple test. The following two figures 3 and 4 are showing this very obvious bug.

Fig. 3: Malformed bézier curve after the 14th control point. Fig. 4: Wrong bézier curve after the 15th control point.

Maybe someone wants to dig into my code to find this bug :). To be honest: I haven’t looked yet what could be the reason for this.

And just to be clear: the code is not really good, four years old and not documented at all. Just to be fair. I’ve warned you ;).


That’s all. As far as I can remember, this project was really fun. Not that much effort nor time consuming, but just fun. And I hope this is just the first blog post in a beginning series of post where I can show some small and old side projects of mine. Maybe they are helpful for someone.

ppedv Team Blog: SmartUnitTests in Visual Studio 2015 – PEX is back

Schon mit Visual Studio konnte man Pex & Moles als AddOn installieren und verwenden (siehe: Dieses, ursprünglich von MS Research entwickelte, Projekt bestand aus zwei Teilen. Moles ist ein Mocking Framework. Dieses hat unter dem Namen “Fakes-Framework” nun Einzug in Visual Studio 2012 gehalten (

Allerdings hat bis vor kurzem der zweite Teil gefehlt. PEX schaffte es nicht ins VS 2012 oder VS 2013. Nun mit der Preview von Visual Studio 2015 kommt nun kehrt das Tool “PEX” unter dem Namen “Smart Unit Tests” wieder zurück.

Smart Unit Tests erstellen von einem bestehenden Code aus die dazu passenden Unit Tests. Es werden Parametrisierte Unit Tests angelegt.  Da der Code schon vorher bestehen muss, eignet sich dieses Tool nicht für Test Driven Development. In der Praxis werden aber die meisten Tests, wenn überhaupt, erst nach dem Code geschrieben. Und bei dieser Vorgangsweise kann das Tool sehr hilfreich sein.

Nehmen wir für einen ersten Test eine ganz simple Funktion die in der Klasse “Berechnungen” implementiert wurde und schreiben für diese einen Unit Test:

1 public decimal Dividieren(int a, int b) 2 { 3 decimal erg = a / b; 4 return erg; 5 }


Im Visual Studio kann nun bei jeder Funktion im Kontext Menü der Punkt “Smart Unit Tests” aufgerufen werden.


Das Projekt wird kompiliert und Visual Studio sucht nun für die Funktion jene Parameter, die es wert sind getestet zu werden. Die gefundenen Werte werden in einem eigenen Fenster ausgegeben:


Gleichzeitig wurde im Projekt eine weitere Klasse angelegt. Diese nennt sich “BerechnungenTest” und enthält keine Testmethoden sondern PexMethoden. Die Methode die für die Tests der Dividieren-Funktion zuständig ist sieht so aus:

1 public partial class BerechnungenTest 2 { 3 [PexMethod] 4 [PexAllowedException(typeof(DivideByZeroException))] 5 public decimal Dividieren( 6 [PexAssumeUnderTest]Berechnungen target, 7 int a, 8 int b 9 ) 10 { 11 decimal result = target.Dividieren(a, b); 12 return result; 13 // TODO: add assertions to method BerechnungenTest.Dividieren(Berechnungen, Int32, Int32) 14 } 15

Diese Methode ist aber noch nicht die TestMethod die von MS Test ausgeführt wird. Die Testmethoden werden zunächst dynamisch erstellt. Im Smart Unit Test Fenster kann die erstellte Methode angesehen werden. Wenn eine Zeile im Fenster ausgewählt wird, erscheinen im rechten Teil die “Details” und hinter diesen sieht man die entsprechende Test-Methode:


Diese Methode wurde dynamisch erstellt und ausgeführt. Möchte man diese als Test dauerhaft in das Projekt aufnehmen, muss aus dem Kontext-Menü der Punkt “Save” gewählt werden. Damit wird eine .g.cs Datei erstellt und diese enthält nun die Testmethode:

1 [TestMethod] 2 [PexGeneratedBy(typeof(BerechnungenTest))] 3 public void Dividieren598() 4 { 5 decimal d; 6 Berechnungen s0 = new Berechnungen(); 7 d = this.Dividieren(s0, 0, 1); 8 Assert.AreEqual<decimal>(default(decimal), d); 9 Assert.IsNotNull((object)s0); 10 } 11 } 12 }

Die Einrückung der Klammern stimmt noch nicht ganz, aber das ist ja nur Formsache.

Je komplexer der Code ist der getestet werden soll, umso umfangreicher werden die gefundenen Testfälle. Bei einer “erweiterten” Rechne-Methode werden es schon 7 Fälle.

1 public decimal Rechne(int a, int b, string rechenoperation) 2 { 3 decimal erg = 0; 4 switch (rechenoperation) 5 { 6 case "+": 7 erg = a + b; 8 break; 9 case "-": 10 erg = a - b; 11 break; 12 case "*": 13 erg = a * b; 14 break; 15 case "/": 16 erg = a / b; 17 break; 18 } 19 return erg; 20 }




um bestehenden Code einfach zu testen, ist dieses Tool perfekt. Es ermittelt zuverlässig die “interessanten” Parameter der Funktionen. Allerdings widerspricht das komplett dem Test-First-Ansatz. Aber zumindest sind ein paar Tests besser, als gar keine Tests. Und dieses Tool, erleichtert das Erstellen der Unit Tests ungemein.

ppedv Team Blog: XAMARIN Tools in Visual Studio 2013 installieren

Die XAMARIN Developer Tools bieten die Möglichkeit, auf Basis von .NET/C# Mobile Applikationen “Cross-Plattform”, also für verschiedene mobile Plattformen zu erstellen. Im Konkreten können Entwickler, auf Basis von Mono, der Cross-Plattform Implementierung der Common Language Infrastructure (auch bekannt als Microsoft .NET) native Apps für iOS, Android und Windows mit nativem User Interface Komponenten erstellen und dabei die selbe ‘'Shared-Codebasis” auf den unterschiedlichen Plattformen nützen. In seinem Produktsortiment hat das Unternehmen aus San Francisco aktuell die XAMARIN Plattform für Windows und iOS auch eine XAMARIN Test Cloud sowie den .NET Mobility Scanner. Die Test Cloud ermöglicht es, Applikationen online auf physischen Geräten zu testen. Der .NET Mobility Scanner ist ein freies Web-basiertes Tool, auf Basis von Silverlight, der sich insofern als nützlich erweist, um den Entwicklern zu zeigen, wie viel von ihrem Code auf anderen Plattformen, also im Speziellen auf iOS, Android und Windows Phone verwendet werden kann.


In einem vorigen Blogbeitrag sind wir auf die unterschiedlichen Szenarien in der mobilen Entwicklung eingegangen. In diesem Blogbeitrag zeigen wir Ihnen, wie Sie bequem das Add-on XAMARIN für Visual Studio in die Entwicklungsumgebung Visual Stuido 2013 integrieren können, Zunächst muss auf das entsprechende Angebot ausgewählt werden. Visual Studio Integration, bieten derzeit nur die Lösungen INDIE, ENTERPRISE und die BUSINESS. Natürlich bietet XAMARIN auch einige Rabatt Aktionen: So können Entwickler mit einer gültigen MSDN Lizenz 20% jährlich sparen. Den Link zur MSDN Aktion finden Sie hier: Für Studenten gibt es derzeit sogar ein Lern-Programm, dass ihnen XAMARIN für iOS und Android weitestgehend gratis zur Verfügung stellt. Studenten können sich hier mit ihrer offiziellen Uni E-Mail Adresse für eine XAMARIN Indie Lizenz - leider ohne Visual Studio Add-on - bewerben (VS Support für Studenten gibt es aber dann um $99 pro Jahr).

Ist der Registrierungsprozess einmal abgeschlossen, kann man sich im persönlichen Portal auf der Webseite des Herstellers, im Bereich Downloads die aktuellen Versionen von XAMARIN Studio (aktuell 5.5.3) und dem XAMARIN Visual Studio Add-On (aktuell 3.7.248) laden.


Das Visual Studio Plugin für Android und iOS Entwicklung kann als .msi Datei bequem mithilfe eines Assistenten zu MS Visual Studio hinzugefügt werden.

Installation XAMARIN Visual Stuido

Anschließend muss, um die Registrierung abzuschließen, im XAMARIN Account auf der Webseite die E-Mail Adresse des Entwicklers registriert werden. Dazu werden unter dem Reiter XAMARIN.Android und XAMARIN.iOS die jeweiligen E-Mail-Adressen als “Seat” zum Account hinzugefügt.


In der Entwicklungsumgebung Visual Studio 2013 können nun Anwendungen für die unterschiedlichen Plattformen als neues Projekt angelegt werden.


In diesem Beispiel wird eine neue Android Applikation angelegt. Die dann auf dem aktuellen Android Betriebssystem “KitKat” auf einem installierten Emulator oder dem mit dem PC verbundenen Android Smartphone ausgeführt werden kann.

Mithilfe von Visual Studio 2013 und XAMARIN können nun Apps für iOS, Android und Windows Phone auf Basis von C#/.Net erstellt werden. Aktuell gibt es jedoch noch eine Einschränkung bei der Entwicklung von iOS Anwendungen: Es wird für die Erstellung der Installationsdatei für iOS ein MAC Rechner benötigt, da das MAC OS rein rechtlich nur auf Apple Geräten funktionieren darf und auch kann. Das Betriebssystem wird von Apple offiziell nur als Update für MAC Rechner über den ITunes Store ausgeliefert.

ppedv Team Blog: Custom Code Activity für SharePoint 2013 Workflow

Der Workflow Manager bringt schon einige Activities mit. Jedoch ist es manchmal wünschenswert eigene Activities mit C# Code zu erstellen und nicht alles nur im Designer “zusammen zu klicken”

Im großen Überblick sind die notwendigen Steps einfach.

1) Die Activity ist eine von “CodeActivity” abgeleitete Klassen. Die Methode “Execute” wird vom Workflow aufgerufen.

2) das Assembly mit der Klasse muss auf der Maschine mit dem Workflowmanager deployed werden.

So schnell der Teil 1 erledigt ist, so mühsam ist Teil 2, weil hierfür kein Template bereitgestellt wird.

Zunächst legen wir ein neues Visual Studio Projekt an. Als Vorlage wird “Activity Library” ausgewählt. Dieses Template ist im Bereich “Workflow” zu finden. Die automatisch angelegte “Activity1.xaml” kann gelöscht werden.

Danach wird mit “Add-Item” eine neue Code-Activity in das Projekt eingefügt. Im Beispiel nenne ich diese “SimpleActivity.cs”


Mit dieser Vorlage wird die Klasse “SimlpeActivity” angelegt und die Methode Execute überschrieben.

1 public sealed class SimpleActivity : CodeActivity 2 { 3 4 public InArgument<string> Text { get; set; } 5 public OutArgument<string> Result { get; set; } 6 7 protected override void Execute(CodeActivityContext context) 8 { 9 10 string text = context.GetValue(this.Text); 11 12 Result.Set(context, text.ToUpper()); 13 } 14 }

In den Zeile 4 und 5 werden ein Input und ein Output Parameter für diese Activity angelegt. Innerhalb der Excecute Methode kann über Context.GetValue ein Inputparameter abgerufen werden.

Mit Result.Set kann der Output-Parameter gesetzt werden. In diesem simplen Demo wird der Inputwert in Großbuchstaben in den Output geschrieben. In der Realität wird wohl die Execute-Methode etwas komplexer werden.

Teil 2 – Das Deployment

Das Assembly muss mit einem “strong name” versehen sein, daher muss das Assembly signiert werden. Dafür wird in den Properties des Projektes, die Checkbox “Sign the assembly” gesetzt und somit ein neues Keyfile im Projekt angelegt.

Als nächstes muss eine Datei mit dem Namen “allowedtypes.xml” erstellt werden. In dieser Datei werden die Typen beschrieben, welche vom Workflowmanager geladen werden. Der Dateiinhalt sieht wie folgt aus:

1 <AllowedTypes> 2 <Assembly Name="SimpleActivityDemo"> 3 <Namespace Name="SimpleActivityDemo"> 4 <Type>SimpleActivity</Type> 5 </Namespace> 6 </Assembly> 7 </AllowedTypes>

Nachdem das Projekt kompiliert wurde müssen die erstellte DLL und die Datei “AllowedTypes.xml” in ein Verzeichnis des Workflowmanagers kopiert werden. Das Zielverzeichnis ist: “C:\Program Files\Workflow Manager\1.0\Workflow\Artifacts”

Möchte man die Activity nun in einem Visual Studio Workflow verwenden, muss die Activity in die Toolbox aufgenommen werden. Im Context-Menü der Toolbox kann mit dem Menü Punkt “Choose Items…” die DLL ausgewählt werden und damit die enthaltene Activity in die Toolbox aufgenommen werden.


Danach kann die Custom-Activity wie jede andere in Workflow Projekte aufgenommen werden. Die beiden Parameter “Text” und “Result” sind wie gewohnt über das Eigenschaftenfenster im Visual Studio zu setzen.

image [MS]: Xamarin.Forms, oder: Knapp 100% Code-Reuse auf mobilen Plattformen

Aus gegebenem Anlass möchte ich euch gerne den Einstieg in die mobile Entwicklung mit Xamarin und speziell Xamarin.Forms näherbringen. Ihr fragt euch möglicherweise, was denn dieser „Anlass“ sein könnte?


Nun, zum Ersten ist es so, dass die Visual Studio 2015 Preview den Android Emulator mitliefert, was die Entwicklung vereinfacht und die Developer-Experience merklich erhöht, mehr dazu findet ihr hier.

Zum Zweiten ist es so, dass ich nächste Woche wieder einen Xamarin Kurs abhalte und ich gerade wieder einmal meine Unterlagen überarbeite und ich dabei meine treuen Blog-Leser auch teilhaben lassen möchte.


Drittens, und das ist für euch bestimmt noch interessanter, ist die Draft-Version des Xamarin.Forms Buches von Charles Petzold in der Microsoft Virtual Academy als Gratis-Download verfügbar. Und zwar genau hier. clip_image003

Alles gute Gründe, sich Xamarin und Xamarin.Forms genauer anzusehen, aber zuvor sollten wir die Frage klären:


Was ist Xamarin und was kann es für mich tun?

Nun, jeder Entwickler, der mobile Applikationen mit

· C# und
· nativer Performance und
· nativem Look & Feel

für Windows Phone UND iOS UND Android erstellen möchte, sollte sich Xamarin genauer ansehen. Xamarin stellt 100% der nativen APIs für iOS, Android und Windows zur Verfügung.

Als Entwicklungsumgebung liefert Xamarin zwar auch das Xamarin Studio zur Entwicklung mit, aber es ist auch möglich, den gesamten Code in Visual Studio zu erstellen, allerdings benötigt ihr dann auch zumindest die Business-Lizenz. Der Vorteil ist, dass eure gewohnten Tools, wie z. B. Resharper, weiterhin verwendet werden können, ihr aber eben mit dem Xamarin SDK die mobile Plattform eurer Wahl anprogrammiert.

Es werden immer native und keine interpretierten Applikationen für die gewählte Zielplattform erstellt.


Dies wurde dadurch ermöglicht, dass 100% des Android SDKs und 100% des iOS SDKs auf C# gemappt wurden. Kurz gesagt: wenn man es in Java für Android programmieren kann, klappt das auch mit Visual Studio, C# und Xamarin.Android. Das Gleiche gilt eben genauso für XCode mit Objective-C und Visual Studio, C# und Xamarin.iOS.


Was benötige ich, um mit Xamarin zu entwickeln?

Das kommt jetzt ein klein wenig darauf an, auf welche mobile Plattform ihr mit eurer Entwicklung abzielt:

· Android: das Android SDK, optional eine Google Developer Subscription (einmalig $25), mehr dazu findet ihr hier – falls ihr die App veröffentlichen wollt, dann ist diese natürlich zwingend notwendig.

· iOS: einen MAC, der als sogenannter Build-Host dient, auf diesem muss XCode installiert sein und ihr benötigt ZWINGEND eine Apple Developer Subscription (jährlich €83), mehr dazu hier. Der Grund ist, dass die Erstellung nativer iOS Applikationen zwingend auf dem MAC mit den Tools von Apple erfolgen muss.

Dann natürlich noch Xamarin selbst, eine der 4 Editionen, oder die Trial Lizenz - diese ist 30 Tage ohne Einschränkungen lauffähig und findet ihr hier zum Download.


Was kostet Xamarin?

Es gibt 4 verschiedene Lizenzen:

· Starter (kostenlos, aber bez. Funktionen in sehr eingeschränkter Form)
· Indie ($25/Monat)
· Business ($83/Monat)
· Enterprise ($158/Monat)

Für Studenten gibt es die Indie-Version gratis, mehr dazu findet ihr hier. Für MSDN-Abonnenten gibt es ebenfalls spezielle Rabatte, momentan kostet die Business Edition $799/Jahr und pro Plattform.

Den genauen Unterschied in den Funktionen könnt ihr hier nachlesen, ich empfehle euch zumindest die Indie-Version zu verwenden, ich persönlich habe die Xamarin Business Edition für iOS und Android.


Wie funktioniert die Entwicklung mit Xamarin?

Es gibt zwei Möglichkeiten, um mit Xamarin eine native, mobile Applikation zu erstellen:

1. Die GUI wird für die jeweilige Plattform extra erstellt, die Applikations-Logik kann wiederverwendet werden
2. Die GUI wird mit Xamarin.Forms erstellt, damit kann im Idealfall auch die GUI nahezu zu 100% auf jeder der mobilen Plattformen wiederverwendet werden.


Ersteres wird auch der sogenannte Silo-Approach genannt: Drei Säulen – für jede Plattform eine unterschiedliche Implementierung der grafischen Oberfläche.


Was ist Xamarin.Forms?

Mit Xamarin.Forms ist es – im Gegensatz zum Silo-Approach – möglich, eine Applikation 1x zu entwickeln, auch die GUI, und zwar mit nahezu 100% gleichem Code. Das heißt, kaum extra Code-Zeilen für eine der drei führenden mobilen Plattformen (Android, iOS und Windows Phone). Möglich wird das, indem Xamarin.Forms die nativen Controls durch eine Zwischenschicht abstrahiert. So gibt es z. B. einen Xamarin.Forms.Button, dieser wird letztendlich ein UIButton, wenn es sich um eine iOS App handelt, zu einem Android Button bei einer Android App und zu einem Windows Phone Button bei einer Windows Phone App (aber dazu später noch genaueres).


Zusätzlich werden von Xamarin.Forms gewisse Unterschiede der mobilen Plattformen per Default eingebaut. So ist eine iOS-Applikation per Default weiß, eine Android App aber eher in schwarz gehalten. Das bedeutet, dass es eben z. B. per Default ein anderes Farbschema für Schriften und Texte verwendet werden muss. Das kann man zu Beginn getrost links liegen lassen, Xamarin.Forms kümmert sich darum.

Um Xamarin.Forms auch für Windows Phone einsetzen zu können, benötigt ihr zumindest eine Xamarin Lizenz für eine der beiden anderen Plattformen.


Wie wird eine Xamarin.Forms App erstellt?

Xamarin liefert in der Business-Edition Visual Studio Templates mit, wenn ein neues Projekt angelegt wird. Da eine Xamarin.Forms Applikation erstellt werden soll, sind 3 Templates von Interesse:

· Eine „Blank App (Xamarin.Forms.Portable)“,
· eine „Blank App (Xamarin.Forms.Shared)”,
· eine „Class Library (Xamarin.Forms.Shared)”


Also prinzipiell entscheidet man sich, ob man das Projekt als „Shared Project“, oder als „Portable Class Library“ aufsetzen möchte.

Eine Shared Application kompiliert die Klassen in jede einzelne App. Sollten Unterscheidungen für eine spezielle Plattform notwendig sein, wird häufig eine Kompiler-Direktive verwendet. Der Vorteil ist hier, dass nur eine einzige Quelldatei für alle drei Plattformen existiert.

clip_image013Quelle: Xamarin docs

Die Portable-Class Library vereint den kleinsten gemeinsamen Nenner aller verwendeten Plattformen, es ist also im Prinzip keine Unterscheidung für eine der drei mobilen Plattformen von Nöten, da diese PCL für alle drei Apps die Gleiche ist.

clip_image015Quelle: Xamarin docs

Aber warum eine Entscheidung treffen? Ich erstelle üblicherweise eine „Blank App (Xamarin.Forms.Shared)“ und füge danach eine „Class Library (Xamarin.Forms.Portable)“ hinzu. Damit kann ich alle Vorteile aus beiden Lösungen verwenden. Das sieht dann im Endeffekt so aus:


Es ist das Shared Project zu finden, die Android, sowie die iOS App, danach die PCL und am Ende die Windows Phone App. Die PCL wurde als Referenz zu den drei App-Projekten hinzugefügt.

Es lohnt sich, nach dem Anlegen der finalen Projektstruktur das Xamarin.Forms-Package auf die aktuelle Version zu aktualisieren.



XAML-Layout und Datenbindung?

Unter iOS und Android gibt es an und für sich keine MVVM-Unterstützung, wie sie in WPF existiert, aber Xamarin.Forms macht das nun für eben diese beiden Plattformen möglich. Inklusive XAML.

Um das in der Praxis zu testen, habe ich mir eine bestehendes MVVM Beispiel geholt, nämlich die „Simple MVVM and Windows Phone 7“-Applikation von hier und diese mit Xamarin.Forms umgesetzt.

Dieses ursprüngliche Beispiel zeigt die Verwendung von MVVM anhand einer Länderliste. Wenn ein einzelnes Land angewählt wird, so gelangt man zu den Details, bzw. erhält weitere Informationen über dieses Land. Da es sich um ein MVVM-Einführungsbeispiel handelt, verwendet es natürlich Models, ViewModels und Views und verwendet die zugehörige Datenbindung. Außerdem beinhaltet die Applikationen ein Verzeichnis mit Bilder, wo die zu jedem Land zugehörige Flagge enthalten ist.

Das Endresultat der Konvrtierung der Windows Phone 7 App mittels Xamarin.Forms sieht auf den drei Plattformen (Android, iOS; Windows Phone 8) so aus:


Das ist jetzt noch ganz ohne „Tweaks“ für eine bestimmte Plattform, d. h. eine Code-Basis für alle 3 mobilen Clients. Das gilt sowohl für die Business Logik, ALSO AUCH für das Frontend.

Ich möchte hier nur einige der Anpassungen aufgreifen, die gegenüber der originalen Windows Phone 7 App durchzuführen waren:

Generell gilt: WPF, bzw. Silverlight XAML != Xamarin XAML, das ist am deutlichsten an den Controls zu erkennen. Nachfolgend ein Beispiel:

Windows Phone 7 XAML:


Xamarin.Forms XAML


Auffallend, dass wir statt dem StackPanel ein StackLayout sehen, statt dem TextBlock ein Label und ich die Styles einfach entfernt habe. Erstens gibt es diese nicht mehr und zweitens haben wir hier es nicht nur mit einer Plattform zu tun, sondern mit drei verschiedenen – und da ist es erst einmal schwierig mit einem bestimmten Style „ins Rennen zu gehen“. Xamarin.Forms nimmt uns per Default schon einiges ab, wie es in den Screenshots zu sehen ist, konkret spiele ich auf die Hintergrundfarbe und die Vordergrundfarbe der Controls an.

Generell würde ich empfehlen, wenn es sich um eine Applikation, die mit Xamarin-für mehrere mobilen Plattformen entwickelt wird, eine Plattform als „führende“ zu definieren. Sobald diese einen Stand hat, der für den Test frei gegeben werden kann, kann man die zweite und danach die dritte Plattform anpassen, bzw. feintunen. Damit ist sichergestellt, dass zumindest eine Plattform quasi fertig ist und funktioniert. Die anderen beiden folgen in sehr kurzem Abstand. In dem oberen – zugegeben relativ einfachem - Beispiel wurde wie erwähnt absolut NICHTS angepasst.

Grund für diese eigenen Controls ist die Funktionsweise von Xamarin.Forms. Durch die Plattform-abhängigen Bibliotheken verwandeln sich die Xamarin.Forms-Controls in die jeweils passenden der jeweiligen Zielplattform, wie das nachfolgende Bild anschaulich zeigt.


So wird also aus einem Xamarin.Forms.Button ein UIButton, bzw. ein Android.Widget.Button unter Android und ein System.Windows.Controls Button unter Windows Phone.

Die Datenanbindung wurde von Xamarin gleich umgesetzt, wie wir das schon von WPF, oder der Windows Phone Entwicklung gewohnt sind. Das ViewModel und das Model habe ich nahezu ohne Änderungen übernommen, ich habe nur mit dem Bild getrickst und ein weiteres Property, um den Applikations-Titel nur unter Windows Phone darzustellen eingefügt.

Als Beispiel hier die Liste der Flaggen in der Windows Phone 7 App (der Trigger aus dem Originalcode wurde hier entfernt, da Trigger in Xamarin.Forms noch nicht offiziell unterstützt sind):


Und hier die Xamarin.Forms App:


Wichtig zu erwähnen ist noch, dass XAML mit Xamarin.Forms nur in einer Portable Class Library funktioniert und nicht in einem Shared Asset Project. Des Weiteren gibt es noch keinen XAML Designer, das könnte euch das Einarbeiten in Xamarin.Forms etwas erschweren, wenn ihr bisher eure XAML-GUI mit Blend, oder in Visual Studio mit dem Designer gebaut habt.



Generell kann man sagen, dass Xamarin mit den Xamarin.Forms ein großer Wurf gelungen ist. Es ist zwar erst die erste Version, es lassen sich aber bereits hervorragend Business-Applikationen damit entwickeln. Wir dürfen gespannt sein, was das Xamarin-Team in den nächsten Monaten noch für Überraschungen für uns bereithält.

Berndt Hamböck ist seit 2007 MCT, darüber hinaus befasst er sich mit Lösungen für komplexe Anwendungsszenarien mit den neuesten Microsoft Technologien. Die Erfahrungen aus der Projektarbeit gibt er in Vorträgen und Trainings weiter und begleitet Entwicklerteams in Softwareunternehmen bei Projekten im Microsoft Umfeld.

Das ist ein Gastbeitrag. Die Meinung des Autors muss sich nicht mit jener von Microsoft decken. Durch den Artikel ergeben sich keinerlei Handlungsempfehlungen. Microsoft übernimmt keine Gewähr für die Richtigkeit oder Vollständigkeit der Angaben.

Marco Scheel: Links for 2014-11-19 []

ppedv Team Blog: Windows 10 Technical Preview: Die Dritte!

Am 11. November veröffentlichte Microsoft die nächste (und dritte) Technical Preview-Version von Windows 10: Build 9879. Nach den Neuerungen muss man allerdings geduldig suchen!

Neben kleineren Optimierungen und Fehlerkorrekturen, wurden einige Änderungen an den visuellen Effekten bei Animationen von Fenstern (beim Öffnen, Minimieren und Maximieren) und Übergängen zwischen virtuellen Desktops vorgenommen - diese sind jetzt etwas dezenter.

Die “größte” Neuerung ist die Individualisierung von zwei Icons auf der Taskleiste. Mit Windows 10 wurde eine neue Suche und virtuelle Desktops implementiert. Die Icons zu diesen Features sind standardmäßig auf der Taskleiste zu finden.

Windows 10 - 01

Da viele User die Icons als störend empfanden, besteht jetzt die Möglichkeit diese von der Taskleiste zu entfernen. Hierzu muss man einfach einen Rechtsklick auf die Taskleiste vornehmen. In dem dann erscheinenden Kontextmenü findet man dann die passenden Einträge “Show Task View button” und “Show Search button”.

Windows 10 - 02

Entfernt man die Haken vor den Einträgen, verschwinden auf der Taskleiste die entsprechenden Icons.

Windows 10 - 03

Kay Giza [MS]: Poster: Microsoft Entwickler-Welt: Services & Ressourcen fuer professionelle Developer

Kostenloses Poster zum Download: Microsoft Services und Ressourcen für Entwickler; Poster .NET Universum... [... mehr in diesem Blog-Post auf]

This post is powered by | RSS Feed
© Copyright 2006-2013 Kay Giza. All rights reserved. Legal

Uli Armbruster: Seminarabsage bei Lutz und Grub

Ich nehme regelmäßig die Gelegenheit wahr und rezensiere Bücher, bewerte Dienstleister oder berichte von Konferenzen. Egal, ob positiv oder negativ.

Heute möchte ich über eine für mich sehr negative Erfahrung bei der Firma Lutz und Grub in Karlsruhe berichten. Bei dieser hatte ich ein 2-tägiges Seminar zum Thema Projektmanagement gebucht. Um das Ergebnis vorweg zunehmen: Um 9.30 Uhr waren alle Teilnehmer pünktlich im Seminarraum; der Trainer jedoch fehlte. Um 9.40 Uhr wurde das Seminar dann krankheitsbedingt abgesagt.

Nun störe ich mich nicht daran, dass das Seminar abgesagt wurde, weil der Trainer erkrankte und kein Ersatz zur Verfügung stand. Ich störe mich erheblich daran, dass dies erst nach Seminarbeginn festgestellt wurde. Dies hätte sich doch problemlos vermeiden lassen. Zum einen hätte bereits am Vortag eine Benachrichtigung (E-Mail, Telefon) rausgehen können, dass der Termin ggf. nicht gehalten werden kann und dass die Teilnehmer am nächsten Morgen vorher eine finale Zu- oder Absage erhalten werden. Es sei angemerkt, dass es der Trainer laut Aussage von Lutz und Grub bereits am Vortag angeschlagen war. In unserer abteilungsinternen Organisation haben wir dieses Vorgehen sogar schriftlich im Wiki fixiert (siehe Screenshot).




Selbst wenn der Trainer aber morgens aufwacht und aus gesundheitlichen Gründen kurzfristig absagen muss, würde ich mir immer noch wünschen, dass versucht wird die Teilnehmer möglichst schnell telefonisch oder schriftlich zu informieren. Wenn um 9.30 Uhr Seminarbeginn ist, dann ist eine Meldung um 9.40 Uhr nicht hinnehmbar. Ein kleines Rechenbeispiel soll verdeutlichen, welche hypothetischen Kosten dadurch hätten vermieden werden können: Die Reisezeit für mich betrug insgesamt 3 Stunden. Als Freelancer mit einem Stundensatz von 90€ hätte ich somit 270€ verdienen können. Hinzu kommen die Fahrtkosten, welche bei mir knapp über 10€ betrugen. Damit sind wir bei insgesamt 280€. Welche terminliche Verrenkungen bei mir notwendig waren, um 2 Tage freizuschaufeln, will ich gar nicht erst bewerten.

Generell hatte ich bisher einen guten Eindruck von Lutz und Grub, aber das war für mich doch mehr als ärgerlich. Die Schulung wurde auf nächste Woche verschoben. Diese kann ich weder, noch möchte ich sie wahrnehmen.

Hält der geneigte Leser meine Reaktion für übertrieben?

Einsortiert unter:German, Misc Tagged: Produktbewertungen

Lars Keller: Gesten, Gesten, Gesten :-)

Heute Abend bin ich bei der .NET User Group Oldenburg. Ich werde einen Vortrag über das Thema "Herr der Gesten - Leap Motion, Kinect, Perceptual Computing!" halten.

Hierzu schauen wir uns die Kinect, Leap Motion und das Intel Perceptual Computing an und ich zeige auf, welche Geräte für was geeignet sind und wie sich diese anprogrammieren lassen.

Wir sehen uns dort!


Marco Scheel: Links for 2014-11-18 []

Code-Inside Blog: Easy ways to customize Bootstrap

So, you are using Bootstrap? Fine, but what do you do if you would like to change some color, font-sizes, font-families, paddings etc.? This blogpost highlights some (free) tools for people who don’t write or know a lot of CSS/LESS. If you are a front-end dev and already know advanced toolings this blogpost is not ideal for you.

Don’t customize the CSS/LESS files

Here might be dragons! A big warning upfront: Don’t pollute the generated CSS files and only change the variables.less file from Bootstrap - otherwise you are running a your own fork and might not be able to upgrade.

As far as I know all Customizer will only alter the variables.less file - this is the only way to customize Bootstrap.

If you only want to change certain elements try to override it with your own CSS.

The Default Customizer

Well - this one might be obvious - but there is the official Customizer on This works well, but you there is no direct feedback and you need to know the variables and their behavior. If you start using this customizer you will be able to get a “config.json” file which you can reuse later. This file saves all your settings and you can change it later.


Bootstrap Magic

This one comes with a live editor and in theory you should be able to import an existing variables.less, but it didn’t worked for me.

But the live changing elements makes it very easy to see the changes in action and if you don’t need to upload existing variables this one might work for you.


My recommendation: Bootstrap Live Customizer

Like Bootstrap Magic this one comes also with “Live” rendering. With this editor I was able to change some variables, generate the CSS/LESS, reuploaded the variables.less file at a later time and continue my editing.

Awesome and definitely worth trying out! Great work Istvan!


Hope this helps!

If you know other tools, please let me know. Thanks!

Thomas Bandt: Stolperfalle: Module in Node.js sind statisch

Baut man sich seine eigenen Module, wie das die Philosophie von Node.js vorsieht, muss man aufpassen, dass man bei mehrfacher Verwendung nicht in Konflikte gerät. Denn diese sind faktisch statisch und funktionieren wie Singletons.

Als Beispiel soll dieses simple Demo-Modul dienen:

(function(module) {
    "use strict";

    var _name = "Foo";

    module.getName = function() {
        return _name;

    module.setName = function(name) {
        _name = name;

Der private Member _name ist zunächst “Foo” und kann über die Methode setName(name) beliebig geändert werden.

Ein kleines Beispiel:

(function() {
    "use strict";

    var http = require("http");

    var demo1 = require("./app/demo");
    var demo2 = require("./app/demo");

    var server = http.createServer(function(request, response) {
        response.write("1 - " + demo1.getName() + "\n");
        response.write("2 - " + demo2.getName() + "\n");


        response.write("1 - " + demo1.getName() + "\n");
        response.write("2 - " + demo2.getName() + "\n");



Erzeugt werden zwei “Instanzen” des Demo-Moduls: demo1 und demo2. Zunächst wird für jede “Instanz” der Name ausgegeben, was erwartbar zur Ausgabe von “Foo” und “Foo” führt.

Anschließend wird für die erste “Instanz” demo1 der Name auf “Bar gesetzt”, was vermuten lassen könnte, dass die folgende Ausgabe nun aus “Bar” (demo1) und “Foo” (demo2) besteht.

1 - Foo
2 - Foo
1 - Bar
2 - Foo

Tut sie aber nicht: stattdessen ist der Wert nun für beide “Instanzen” auf “Bar” gesetzt.

1 - Foo
2 - Foo
1 - Bar
2 - Bar

Aktualisiert man die Seite im Browser, bestehen gar alle Ausgaben nur noch aus “Bar”.

1 - Bar
2 - Bar
1 - Bar
2 - Bar

Der Grund dafür ist, dass Module nur ein einziges Mal instanziiert werden - egal wie häufig man sie irgendwo per require() einbindet. Damit gibt es also faktisch keine Instanzen und alle Aktionen, die auf demo1 durchgeführt werden, betreffen auch demo2, da demo1 faktisch demo2 entspricht.

Keine revolutionäre, für Einsteiger in Node.js aber eine wichtige Erkenntnis ;-).

| Kommentieren | © 2014 Thomas Bandt [MS]: Mobile Developer After Work #6

Weiter geht es mit dem nächsten Termin für das angesagte Mobile Developer After-Work von Mopius und Tieto.

Diesmal findet das ganze bei IBM am 10.12.2014 um 17:00 Uhr statt.

Wie immer gibt es ganz spannende Vorträge mit IBM, aber auch von der Community. Die große Überaschung: ein Stimm- und Körpersprachenvortrag für Techniker!

Die genaue Agenda:

17:40: Build a mobile app with IBM Bluemix

18:45: AngularJS für Universal Apps
Erstellen einer Universal Agenda App mit angular.js und Web API backend. Vom leeren Projekt zur fertigen Agenda App mit Daten aus der Cloud.
Hannes Mayer, GPN-Telecom
Stefan Kern, GPN-Telecom

19:25: Techniker-Präsentationen: stimmlich + körpersprachlich kompetent
Präsentieren von Technik? Mit Sprechtechnik und Körpersprache, die stimmt!
Petra Chiba, Sängerin, Stimm- und Persönlichkeitstrainerin

Es gibt nur mehr 12 Restplätze!!! Wer also die letzte Chance in diesem Kalenderjahr für das After-Work nutzen will, muss sich schnell anmelden!

Holger Sirtl: Regelmäßige Video-Serie rund um Microsoft Azure: TechTalk.Cloud

Seit dem 20. Oktober ist sie nun live: unsere TechTalk.Cloud Serie. Zusammen mit meinen Evangelisten-Kollegen möchte ich in der Serie (geplant wöchentlich) Aktuelles, Interessantes und Wissenswertes zu Microsoft Azure präsentieren. Nach mehreren Aufnahme-Sessions in unserem Webcast-Studio in Unterschleißheim sind bereits einige Episoden online.

Die Serie kann über folgenden Link auf Channel 9 erreicht werden:

Hier die bereits aufgenommenen und veröffentlichten Episoden…

Weitere Informationen

Thomas Bandt: Vielversprechend: Promises in JavaScript

Wer sich eine Weile mit JavaScript beschäftigt, wird bei der Verwendung einer Library oder eines Frameworks über kurz oder lang Code-Fragmenten begegnen, die einen starken Hang dazu aufweisen, nach rechts zu wachsen. Willkommen in der Callback-Hölle.

Die Ursache liegt darin, dass in JavaScript seit jeher versucht wird, asynchron zu arbeiten, da zur Ausführung nur ein Thread zur Verfügung steht.

Kommuniziert man also z.B. aus einer Website heraus mit einem Server, so will man ja nicht, dass die komplette Seite im aktuellen Browserfenster bzw. -Tab lahmgelegt ist, solange die Antwort vom Server noch aussteht. Gleiches gilt für den Zugriff auf das Dateisystem in Cordova oder die Verbindung zu einer Datenbank in NodeJS.

Das kann sich dann in seiner hässlichsten Schreibweise z.B. so auswachsen:

(function(homeController) {
	var mongodb = require("mongodb");
	var mongoUrl = "mongodb://localhost:27017/demodb";
	homeController.init = function(app) {
	    app.get("/", function(request, response) {
	        mongodb.MongoClient.connect(mongoUrl, function(error, db) {
	            db.users.find().toArray(function(error, result) {
	                response.render("index", {
	                    error: error,
	                    result: result

Hier werden alle User abgerufen und zurück zum Client gegeben. Das kann man natürlich noch ein wenig angenehmer schreiben, in dem man die Callbacks nicht inline definiert, sondern als eigene Funktionen rauslegt, was sich ein wenig besser liest:

(function(homeController) {
	var mongodb = require("mongodb");
	var mongoUrl = "mongodb://localhost:27017/demodb";
	var _response;
	homeController.init = function(app) {
	    app.get("/", handleRequest);
	function handleRequest(request, response) {
	    _response = response;
	    mongodb.MongoClient.connect(mongoUrl, connectedToMongoDB);
	function connectedToMongoDB(error, db) {
	function mapUsers(error, result) {
	    _response.render("index", {
	        error: error,
	        result: result

Aber für jeden einzelnen Schritt eine eigene Funktion – auch das zieht sich sehr schnell in die Länge und lässt einen irgendwann orientierungslos im eigenen Code herumspringen.

Eine Alternative hierzu ist es, Promises einzusetzen. Eine beliebte Library hierfür wäre z.B. q.

(function(homeController) {
	var mongodb = require("mongodb");
	var mongoUrl = "mongodb://localhost:27017/demodb";
	var $q = require("q");
	homeController.init = function(app) {
	    app.get("/", function(request, response) {
	        getDemoData().then(function(result) {
	            response.render("index", {
	                users: result
	        }, function(error) {
	            response.render("index", {
	                error: error,
	                users: []
	function getDemoData()) {
	    return getDb().then(function(db) {
	        var deferred = $q.defer();
	        db.users.find().toArray(function(error, results) {
	            if (error) {
	            } else {
	        return deferred.promise;
	function getDb() {
	    var deferred = $q.defer();
	    mongodb.MongoClient.connect(mongoUrl, function(error, db) {
	        if (error) {
	        } else {
	    return deferred.promise;

Was sich vielleicht auf den ersten Blick noch nicht erschließt, macht sich gerade bei komplexeren Szenarien positiv bemerkbar:

Bei den eigenen Funktionen kann man auf Callbacks verzichten, sie kommen nur noch bei den externen Komponenten zum Einsatz, deren API man selbst nicht ändern kann (in dem Fall der Datenbankprovider für MongoDB in NodeJS).

Stattdessen gibt jede Funktion etwas Erwartbares zurück: nämlich das Versprechen, sich nach erfolgreicher oder fehlgeschlagener Ausführung mit dem Ergebnis zurückzumelden.

Das funktioniert, grob gesagt, in dem innerhalb der Funktion ein Objekt erzeugt und direkt an den Aufrufer der Funktion zurückgegeben wird, das quasi einen Vertrag besiegelt - indem es “verspricht”, sich zu melden, sobald die Arbeit innerhalb der Funktion erledigt ist.

Wie lange es auch dauert, was da dann intern passiert - sobald alles getan ist, kann das Versprechen über resolve([Ergebnis]) oder reject([Fehler]) eingelöst werden.

Darauf reagiert dann der Aufrufer - denn der hat zu diesem Zeitpunkt über die then()-Funktion bereits festgelegt, was im Erfolgs- und was im Fehlerfall passieren soll.

Noch mal an einem simpleren Beispiel:

asyncFoo().then(success, failure);

function asyncFoo() {
	var deferred = $q.defer();

	setTimeout(function() {
	}, 1000);

	return deferred;

function success(result) {
	console.log("Yeah: " + result);

function failure(error) {
	console.warn("Oops: " + error)

Nach genau 1.000 Millisekunden wird hier “Yeah: Fertig” ausgegeben.

Das ist nur ein sehr kleiner Einblick in die Funktionsweise von Promises - aber der wie ich finde wichtigste Part. Die Einarbeitung lohnt sich. async await in C# ist zwar durchaus eleganter, aber wenn man das Konzept einmal verinnerlicht hat, lässt sich auch in JavaScript deutlich lesbarerer Code schreiben.

| Kommentieren | © 2014 Thomas Bandt

Holger Sirtl: Neues Azure Whitepaper: Eigene Anwendungen auf Microsoft Azure

Ich habe die letzte Woche des TechSummits abseits der vielen Vorträge auch dazu genutzt, um aus meiner recht erfolgreichen Blog-Serie zu den verschiedenen Ausführungsoptionen für eigene Anwendungen auf Microsoft Azure in ein Whitepaper zu gießen. Dieses enthält nun die wichtigsten Informationen zu den Möglichkeiten, eigene Anwendungen in der Public Cloud auszuführen.


Eigene Anwendungen auf Microsoft Azure (

Natürlich stehen dabei die Alternativen

  • Virtual Machines
  • Cloud Services
  • Websites
  • Mobile Services

im Mittelpunkt. Zu den einzelnen Optionen habe ich zusammengefasst, wie die einzelne Option funktioniert, wann diese Option verwendet werden sollte und wie eine Migration zu einer anderen Ausführungsoption aussehen könnte.

Inhaltsverzeichns des Whitepapers

Das Inhaltsverzeichnis gestaltet sich wie folgt:

1 Überblick
2 Virtual Machines
2.1 Konzept der Virtual Machines
2.2 Fazit zu Virtual Machines
2.3 Weitere Informationen zu Virtual Machines
3 Cloud Services
3.1 Konzept der Cloud Services
3.2 Entwicklung von Cloud Services
3.3 Fazit zu Cloud Services
3.4 Weitere Informationen zu Cloud Services
4 Websites
4.1 Konzept der Websites
4.2 Entwicklung von Websites
4.3 Fazit zu Websites
4.4 Weitere Informationen zu Websites
5 Mobile Services
5.1 Konzept der Mobile Services
5.2 Entwicklung von Mobile Services
5.3 Fazit zu Mobile Services
5.4 Weitere Informationen zu Mobile Services
6 Auswahl des besten Ausführungsmodells
6.1 Vergleich der wichtigsten Funktionalitäten
6.2 Fazit
7 Wechsel des Ausführungsmodells
7.1 Einzelne Migrationsszenarien
7.2 Fazit
7.3 Weitere Informationen zu den Ausführungsmodellen
8 Erste Schritte mit Microsoft Azure

Weitere Informationen

Stefan Henneken: IEC 61131-3: The Pattern ‘Abstract Factory’

If instances of a function block have to be created, the exact type of the function block should be known before compiling. Properties of an application can hardly be expanded by this fixed assignment. For example, this will be the case when the function block is located in a library and the access to the source code is thus not possible. The instance variable is constrained by a specific type. A class factory can help to break these stiff structures.

The term class factory denotes an object in object-oriented programming, which generates other objects. A factory can be implemented in different ways. One of them is abstract factory, which is employed in the following example. As an example, a small PLC library for message logging is created. An abstract class factory allows the user to adjust the library range of functions without changing the sources.

Variant 1: A simple function block

The first (most obvious) step implicates developing a function block for logging or messaging. In the course of this, the Write() method receives the text and the function block writes the message in a text file.


Furthermore, the Write() method expands the text by the word Logger. As a check, the whole text is returned.

    sMsg    : STRING;

sMsg := CONCAT('logger: ', sMsg);
// open file
// write the message into the file
// close file
Write := sMsg;

The implementation of the function block is relatively easy.

    fbLogger     : FB_Logger();
    sRetMsg      : STRING;

sRetMsg := fbLogger.Write('Hello');

However, if the user would like to use optionally a CSV or XML file instead of the simple text file, the developer should expand the block.

Variant 2: A function block with function selection

One possible approach would be to give a file path to each instance of FB_Logger through the FB_init() method. This path defines in which file the messages are saved. The file extension serves as an identifier of the file format in this case.

The FB_init() method gets not only both implicit parameters bInitRetains and bInCopyCode, but also an additional parameter sFilename.

    bInitRetains  : BOOL;
    bInCopyCode   : BOOL;
    sFilename     : STRING;

sFilenameExtension := F_ToLCase(RIGHT(sFilename, 3));

The file extension is stored in the variable sFilenameExtension.

    sFilenameExtension : STRING;

In the Write() method, an IF statement distinguishes different variants and calls the compatible private method respectively. Thus, the function block is capable to store the messages in different file formats.

    sMsg    : STRING;

sMsg := CONCAT('logger: ', sMsg);
IF (sFilenameExtension = 'txt') THEN
    Write := WriteTxt(sMsg);
ELSIF (sFilenameExtension = 'csv') THEN
    Write := WriteCsv(sMsg);
ELSIF (sFilenameExtension = 'xml') THEN
    Write := WriteXml(sMsg);

In this way, FB_Logger gets five methods.


FB_init() is called automatically when an instance of FB_Logger is created. In this example, on startup of the application. The method can be expanded by its own parameters, which are forwarded as an instance is declared.

WriteTxt(), WriteCsv() und WriteXml() have been declared as private methods and thus can be called only within FB_Logger.

Write() is a method that the user of FB_Logger can utilise to write the messages.

The result is a function block, which covers all necessary cases internally. The user can specify the desired behaviour by the file name, when creating an instance.

    fbLoggerTxt    : FB_Logger('File.csv');
    sRetMsg        : STRING;

sRetMsg := fbLoggerTxt.Write('Hello');

However, the block becomes bigger with each memory type and occupies space in the program memory. If the reports are written in a CSV file, the program code for the TXT file and XML file is also loaded in the program memory, although it is not required.

Variant 3: A function block with dynamic instantiation

In this case, the concept of the dynamic memory management is helpful. Instance of the function block are created at run-time as well. In order to be able to use it in our example, the methods WriteTxt(), WriteCsv() and WriteXml() are transformed into separate function blocks. In this way, each variant has its own function block which contains the Write() method.

    sMsg    : STRING;

Write := CONCAT('txt-', sMsg);
// open txt file
// write the message into the txt file
// close txt file

The operator __NEW() gets a standard data type as a parameter, allocates the necessary memory and returns a pointer to the object.

pTxtLogger := __NEW(FB_TxtLogger);

pTxtLogger is a pointer to FB_TxtLogger.

pTxtLogger : POINTER TO FB_TxtLogger;

If __NEW() is successfully executed, the pointer is unequal to zero.

An instance of a desired function block can be now dynamically created in the FB_init() method. As a consequence, it is not anymore necessary to create an instance of all possible function blocks statically.

In order to simplify an access to the Write() method of the respective logger block, the interface ILogger is defined. FB_TxtLogger, FB_CsvLogger and FB_XmlLogger implement this interface.

FB_Logger contains a variable of the type ILogger in addition to the three pointers to the three possible function blocks.

    pTxtLogger   : POINTER TO FB_TxtLogger;
    pCsvLogger   : POINTER TO FB_CsvLogger;
    pXmlLogger   : POINTER TO FB_XmlLogger;
    ipLogger     : ILogger;

The respective instance of the function block is created and is assigned to the corresponding pointer in FB_init().

    bInitRetains : BOOL;
    bInCopyCode  : BOOL;
    sFilename    : STRING;
    sFilenameExtension : STRING;

sFilenameExtension := F_ToLCase(RIGHT(sFilename, 3));
IF (sFilenameExtension = 'txt') THEN
    pTxtLogger := __NEW(FB_TxtLogger);
    ipLogger := pTxtLogger^;
ELSIF (sFilenameExtension = 'csv') THEN
    pCsvLogger := __NEW(FB_CsvLogger);
    ipLogger := pCsvLogger^;
ELSIF (sFilenameExtension = 'xml') THEN
    pXmlLogger := __NEW(FB_XmlLogger);
    ipLogger := pXmlLogger^;
    ipLogger := 0;

The dynamically created function block is assigned to the variable ipLogger in lines 14, 17 and 20. This is possible, because all function blocks implement the interface ILogger.

The Write() method of FB_Logger accesses the Write() method of FB_TxtLogger, FB_CsvLogger or FB_XmlLogger through ipLogger:

    sMsg    : STRING;

IF (ipLogger <> 0) THEN
    Write := ipLogger.Write(CONCAT('logger: ', sMsg));

In the same way as FB_init() is called each time as a function block is created, FB_exit() is executed respectively one time when deleting. The memory previously allocated with __NEW() should be released again with __DELETE().

    bInCopyCode : BOOL;

IF (pTxtLogger <> 0) THEN
    pTxtLogger := 0;

IF (pCsvLogger <> 0) THEN
    pCsvLogger := 0;

IF (pXmlLogger <> 0) THEN
    pXmlLogger := 0;

The UML diagram of the example looks as follows:


Thus, the example contains four function blocks and one interface.


The interface ILogger simplifies developing further variants. However, attention should be paid that the new function block implements the interface ILogger, and the method FB_init() in the function block FB_Logger creates an instance of the new function block. The Write() method of FB_logger doesn't have to be adopted.

Example 1 (TwinCAT 3.1)

Variant 4: An abstract factory

As an instance of FB_Logger is created, it is set through the file extension, in what format the messages are logged. You could choose so far between a TXT file, CSV file or XML file. If further variants have to be added, the function block FB_Logger should still be adjusted. If the source code can not be accessed, it is not possible to expand FB_Logger.

A class factory offers an interesting opportunity to construct the function block FB_Logger distinctly more flexible. In this case, a function block is defined (the actual class factory), which provides a reference to another function block through a method. Parameters, which were previously transferred to the class factory, determine which sort of reference is generated.

The functionality, which was contained in the FB_init() method of FB_Logger up to now, is transferred into a separate function block, the class factory FB_FileLoggerFactory. The class factory FB_FileLoggerFactory gets the file path to the log file through the FB_init() method.

A reference to the class factory is passed to the FB_init() method of FB_Logger. The class factory provides the reference to the respective function block (FB_TxtLogger, FB_CsvLogger or FB_XmlLogger) through the GetLogger() method. Creating of the instances is carried out by the class factory and not by the function block FB_Logger().

Since the class factory always supplies the GetLogger() method in this example, it is derived from an abstract base function block, which specifies this method.

Abstract function blocks do not obtain any functionalities. The methods' bodies stay void. In this way, an abstract function block can be compared with an interface.

Since the class factory is derived from an abstract class (here: abstract function block), it is referred as abstract class factory.

The UML diagram looks as follows:


Here is the representation of the single POUs:


To use FB_Logger, a reference has to be passed to the wanted class factory in case of creating an instance.

    fbFileLoggerFactory   : FB_FileLoggerFactory('File.csv');
    refFileLoggerFactory  : REFERENCE TO FB_FileLoggerFactory := fbFileLoggerFactory;
    fbLogger              : FB_Logger(refFileLoggerFactory);
    sRetMsg               : STRING;

sRetMsg := fbLogger.Write('Hello');

The class factory FB_FileLoggerFactory determines in the FB_init() method, whether an instance of FB_TxtLogger, FB_CsvLogger or FB_XmlLogger should be created.

    bInitRetains  : BOOL;
    bInCopyCode   : BOOL;
    sFilename     : STRING;
    sFilenameExtension : STRING;

sFilenameExtension := F_ToLCase(RIGHT(sFilename, 3));
IF (sFilenameExtension = 'txt') THEN
    pTxtLogger := __NEW(FB_TxtLogger);
    ipLogger := pTxtLogger^;
ELSIF (sFilenameExtension = 'csv') THEN
    pCsvLogger := __NEW(FB_CsvLogger);
    ipLogger := pCsvLogger^;
ELSIF (sFilenameExtension = 'xml') THEN
    pXmlLogger := __NEW(FB_XmlLogger);
    ipLogger := pXmlLogger^;
    ipLogger := 0;

The GetLogger() method of FB_FileLoggerFactory() returns the interface ILogger. The Write() method of the logger can be accessed through this interface.

METHOD PUBLIC GetLogger : ILogger

GetLogger := ipLogger;

In such a way, an access to the wanted logger is obtained by FB_Logger in FB_init().

    bInitRetains       : BOOL;
    bInCopyCode        : BOOL;
    refLoggerFactory   : REFERENCE TO FB_AbstractLoggerFactory;

IF (__ISVALIDREF(refLoggerFactory)) THEN
    ipLogger := refLoggerFactory.GetLogger();
    ipLogger := 0;

The call in the Write() method of FB_Logger() is carried out indirectly through the interface ILogger.

    sMsg    : STRING;

Write := 'Error';
IF (ipLogger <> 0) THEN
    Write := ipLogger.Write(sMsg);

Example 2 (TwinCAT 3.1)

Advantages of an abstract factory

As a result of passing a class factory to FB_Logger(), the functionality is expandable without having to adjust any function block.

As an example, the foregoing program is extended in such a way, that the messages are written in the database through the Write() method of FB_Logger.

For this purpose, two steps are necessary:

1. A new class factory is defined, which is derived from FB_AbstractLoggerFactory. In this way, the new class factory obtains the GetLogger() method.
2. A function block for logging is created. This block implements the interface ILogger and consequently the Write() method.

The new class factory (FB_DatabaseLoggerFactory) is created in such a way, that different kinds of databases are available. The FB_init() method gets three parameters of type string. Two parameters define the user name and the password, while the third one contains connection data for the database.

FB_SQLServerLogger is a logger block for SQL server databases. Further variants can follow, for example, FB_OracleLogger for Oracle databases.

Thus, the program expands by the function blocks FB_DatabaseLoggerFactory and FB_SQLServerLogger.

The left section represents the blocks, which can be located in a PLC library. Both function blocks on the right side are necessary to change the behaviour of FB_Logger.



The implementation of the new function blocks is very simple:

    fbDatabaseLoggerFactory  : FB_DatabaseLoggerFactory('MyDatabase', 'User', 'Password');
    refDatabaseLoggerFactory : REFERENCE TO FB_DatabaseLoggerFactory := fbDatabaseLoggerFactory;
    fbLogger                 : FB_Logger(refDatabaseLoggerFactory);
    sRetMsg                  : STRING;

sRetMsg := fbLogger.Write('Hello');

Example 3 (TwinCAT 3.1)

Neither FB_Logger nor any other block from a PLC library has to be adjusted in order to expand the block FB_Logger in it's function. This is possible, because the dependencies of the function blocks between themselves were changed.

In the 3d variant, all logger function blocks (FB_TxtLogger, FB_CsvLogger, ...) are created directly by FB_Logger. Thus, a strong dependency exists between these function blocks.


In the 4th variant, there is a further layer between the logger function blocks and FB_Logger. This layer is however an abstract one. The reference, which is passed to FB_Logger through the FB_init() method, is a reference to an abstract function block.



The user determines which specific class factory to apply only when using blocks, i.e. when the application is developed. The function block FB_Logger sees only one function block, which is derived from FB_AbstractLoggerFactory and contains the GetLogger() method. This method returns the interface ILogger, behind which the Write() method of the actual logger is located.

It is not relevant for the block FB_Logger, where the specific class factory is defined: within the same PLC library or elsewhere. It is also irrelevant for FB_Logger, how the class factory creates the logger blocks.

The used blocks (FB_TxtLogger, ...) are not directly passed to the using block (FB_Logger). But controlling is rather transferred to a further module (FB_FileLoggerFactory, ...) through generating of the used blocks.

Dependency Injection

The function block FB_Logger obtains a reference to the class factory through the FB_init() method. Thus, functionality is added to the function block through this reference. This concept is denoted as Dependency Injection.

Open Closed Principle

Object-oriented programming defines several so-called principles. Following these principles should help to keep software structure clean. One of these principles is Open Closed Priciple, i.e. open for extension, but closed for modification.

Open for extension:

It means that the original functionality of a module can be changed through the usage of the extension modules. At the same time, the extension modules contain only the adjustments of the original functionality.

Closed for modification:

It means that no modifications of a module are necessary to extend it. The module provides defined extension points, through which the extension modules can be connected.

As the example shows, a class factory helps by implementing this Open Closed Principle.


The functionality of the block FB_Logger could be extended without modifying the block itself through the application of an abstract factory. The new language features of IEC 61131-3 have made it possible. Interfaces, inheritance and dynamic memory management offer entirely new approaches in design of PLC libraries.

Marco Scheel: Links for 2014-11-15 []

Alexander Schmidt: Entity Framework in der Praxis (Teil 1)

Ein paar weiterführende Tricks beim Umgang mit Entity Framework Database First.

Fabian Deitelhoff: Debuggen von Visual Studio Erweiterungen nicht möglich

In letzter Zeit schreibe ich recht viele Erweiterungen für Visual Studio. Oder ich befasse mich zumindest viel damit, denn es dauert schon eine ganze Zeit, bis so eine Erweiterung mal auf die Menschheit losgelassen werden kann. Selbst für eine einfache Alpha-Version, die noch gar nicht viel kann. Der Workflow für die Entwicklung einer Erweiterung und auch der dafür notwendige Code sind noch recht starr. Da könnte Microsoft noch einiges vereinfachen.

Während der Entwicklung bin ich auf die Fehlermeldung “The breakpoint will not currently be hit. The source code is different from the original version.” gestoßen. Im Grunde eine sehr klare Fehlermeldung die besagt, dass Haltepunkte im Code nicht angesprungen werden können, da sich die Code-Versionen in Visual Studio und der kompilierten Extension unterscheiden. Wie es dazu gekommen ist, kann ich nur vermuten. Ich denke, es hat mit der Umbenennen des Projekts zu tun und das dadurch sowohl der alte als auch der neue Code vorhanden waren. Die Klasse, in der die eigentliche Arbeit stattfindet, behielt nämlich den ursprünglichen Namen bei. Dadurch könnte das Problem verursacht worden sein. Wirklich sicher bin ich mir aber nicht.

Ich habe länger gesucht und zahlreiche Tipps von Google, Stack Overflow und Co. ausprobiert. Aber geholfen hat das alles nichts. Beiträge wie dieser hier gibt es im Web viele. Ebenso Tipps und Tricks, Visual Studio wieder zum Anspringen von Breakpoints zu bewegen. Bis ich auf die Idee gekommen bin mal in dem Verzeichnis zu schauen, wo Visual Studio die Daten zu den einzelnen Extensions ablegt. Damit ist ein Pfad ähnlich diesem hier gemeint:


Wobei der Platzhalter <Version> gegen die entsprechende Visual Studio auszutauschen ist. In meinem Fall bei Visual Studio 2013 ist das die Version 12.0. Damit ist aber die Hauptinstallation von Visual Studio gemeint. Für die Entwicklung von Erweiterungen wird Visual Studio mit dem Parameter rootsuffix gestartet. Die genaue Syntax lautet im Standardfall /rootsuffix Exp. Dort befinden sich alle Daten der Erweiterung. Sowohl Assemblies, als auch XML-Dateien und sonstige Dateien, die in Visual Studio so markiert worden sind, dass sie auch bei der VSX-Installation mit ausgeliefert werden.

Nach dem Löschen und dem erneuten Kompilieren der Extension war wieder alles in Ordnung. Darauf hätte ich vielleicht auch früher kommen können, denn dann hätte ich einiges an Zeit und Aufwand eingespart. Aber so ist das nun mal. Vielleicht hilft dieser Beitrag jemand anderes :). [MS]: Kinect v2 für Windows und Unity -die SDK-Releases sind verfügbar

Das Kinect v2 für Windows SDK wurde Ende Oktober (endlich) in der finalen Version veröffentlicht. Wenn das kein Grund ist sich das einmal näher anzusehen…..

Was braucht man dazu?

Also ganz sicher einmal einen Kinect v2 Sensor, den bekommt ihr um 199,99 €.


Hier ist der Link zum Microsoft Store Österreich.

Falls ihr schon ein glücklicher Besitzer einer XBOX-One mit Kinect seid, dann reicht euch der Kinect-Adapter für Windows, für €49,90.


Hier ist ebenfalls der Link zum Microsoft Store Österreich.

Wenn das mit der Hardware einmal erledigt ist, dann kann es fast schon mit der Programmierung losgehen.

Kinect V2 SDKs

Zuerst benötigt ihr das Kinect for Windows SDK 2.0 (von 22. Oktober 2014, derzeit nur in Englisch). Dieses findet ihr hier. Das ist ein Download von ganzen 275 MB. Da ist nicht nur das SDK dabei, sondern auch einige Beispiele und Zusatzprogramme:

· Den SDK-Browser, da findet ihr (tonnenweise) nützliche Beispiele.

· Den Visual Gesture Builder, um eigene Gesten abzubilden.

· Kinect Sudio, welches euch beim Testen eurer eigenen Applikation hilft, da es Szenen für euch abspielt, damit erspart ihr euch das nach einiger Zeit lästige herumhüpfen beim Test.


Solltet ihr das Ganze gerne unter Unity ausprobieren wollen, steht dem auch nichts im Wege (wenn ihr davon eine Pro-Version euer eigen nennt). Dazu gibt es ebenfalls gleich ein SDK aus erster Hand.

Dieses findet ihr hier.

Ein schnelles Unity Beispiel

Nachdem ihr das KinectSDK-v2.0_1409-Setup.exe ausgeführt habt und die Datei entpackt habt:

1. Startet ihr Unity

2. Beginnt ein neues Projekt

3. Importiert das Kinect.2.0.1410.19000.unitypackage über das Menü
Assests -> Import Package -> Custom Package

4. Danach solltet ihr die beiden Demos importieren, die in der enthalten sind (beide Verzeichnisse mit dem File Explorer und Drag & Drop i Unity)

Wenn ihr erfolgreich wart, dann könnt ihr die beiden Szenen laufen lassen, die sich im GreenScreen, bzw. im KinectView-Verzeichnis befinden. Untenstehend seht ihr, wie die KinectView/MainScene live aussieht.


Unity und Kinect v2 sind eine sehr gute Kombination um tolle Anwendungen zu schreiben und wie man sehen kann ist das Grundgerüst schon einmal vorhanden.



Kinect v2 für Windows mit dem veröffentlichten finalen SDK macht nun richtig Spaß. Sei es in einer Desktop Anwendung (in C#, VB.Net, C++), oder aber auch in einer Windows Store App - sowohl Xaml, als auch HTML finden Unterstützung im SDK. Ich hoffe ich sehe demnächst eine coole Store App, welche Kinect v2 verwendet, die von euch stammt! Abschließend vielleicht noch der Link zur Dokumentation und der gesamten Download-Übersicht: hier und ein Beispiel für eine Store App mit Unity findet ihr auf dem CodeFest-Blog auch schon, nämlich hier.

Berndt Hamböck ist seit 2007 MCT, darüber hinaus befasst er sich mit Lösungen für komplexe Anwendungsszenarien mit den neuesten Microsoft Technologien. Die Erfahrungen aus der Projektarbeit gibt er in Vorträgen und Trainings weiter und begleitet Entwicklerteams in Softwareunternehmen bei Projekten im Microsoft Umfeld.

Das ist ein Gastbeitrag. Die Meinung des Autors muss sich nicht mit jener von Microsoft decken. Durch den Artikel ergeben sich keinerlei Handlungsempfehlungen. Microsoft übernimmt keine Gewähr für die Richtigkeit oder Vollständigkeit der Angaben.

Alexander Schmidt: Bugfix für Azure-Login-Problem nach Update auf VS 2013 Update 4

Behebung eines Fehlers für Azure-Login aus Visual Studio nach dem Update auf Version 4.

Ralf Westphal: Wunderlist für Personal Kanban

Ein Tool ist kein Selbstzweck, sondern soll dienlich sein. Das trifft auf Software zu wie auf Methoden. Um meine Arbeit zu organisieren, wenn es mal wieder etwas mehr wird, habe ich vor einiger Zeit Personal Kanban eingeführt. Naja, “einführen” kann man da nicht viel ;-) Ich habe also angefangen, nicht nur eine Aufgabenliste zu führen, sondern die Aufgaben über ein Brett zu ziehen. Das [MS]: Visual Studio 2015 Preview, Xamarin und der integrierte Android Emulator

Die Neuigkeiten der Microsoft Connect sind für Xamarin-Entwickler durchwegs positive Nachrichten gewesen. Aber es waren ja nicht nur „Nachrichten“, nein, es steht ja auch gleich einiges zum Ausprobieren zur Verfügung. Z. B. Visual Studio 2015, inklusive verfügbaren Xamarin Projekt-Templates UND einem integrierten Android Emulator.

Letzteres ist besonders großartig, da es bisher einer gewissen Leidensfähigkeit bedurfte, um mit den Android-Emulatoren aus dem SDK zu arbeiten (Stichworte: langsam, verlorene Verbindungen, usw.).

Also war ich gespannt wie ein Regenschirm und wollte mir das gleich einmal ansehen. Was dabei herausgekommen ist, möchte ich euch gerne nachfolgend beschreiben.

Die Installation von Visual Studio 2015

Dazu erst einmal der übliche Download des Installers, diesen findet ihr hier:


Ich habe nur „die notwendigsten“ Features ausgewählt, da auf meiner Maschine z. B. bereits die Windows Phone 8.1 Emulatoren installiert sind, es bleibt euch aber überlassen, gleich einmal alles auf die Festplatte „zu schmeißen“.


Wichtig ist nur, dass ihr nach dem üblichen Setup auch das zweite Setup durchlaufen lässt, um den Android Emulator zu installieren. Solltet ihr etwas zu vorschnell gewesen sein und den Installer bereits geschlossen haben, so könnt ihr das über „Programs and Features“ beheben, indem der „Secondary Installer“ noch einmal mittels „Change“ aufgerufen wird.


Nachfolgend wiederum meine Auswahl, ich habe aber auf der Maschine schon das Android SDK - ihr wollt möglicherweise wieder alles installieren:


Wichtig ist in jedem Fall der Microsoft Visual Studio “Emulator for Android”.

Neues Android Projekt – Versuch 1

Nachdem auch diese Installation durchgelaufen war, dachte ich mir, ich rufe gleich einmal Visual Studio 2015 auf und lege sofort mit einem Beispielprojekt los.


Gesagt, getan – und dann sogleich ein neues Projekt anlegen – soweit der Plan. WOW, es gibt unter Visual C# ein Android Projekt, nun, mir nichts, dir nichts, unverzüglich dieses anwählen und noch einen passenden Namen verpassen.


Soweit so gut, nur…..schade, das war es noch nicht. Ein netter Dialog weist mich darauf hin, dass ich Xamarin installieren sollte.


Xamarin Installation

Gut, auf Download Xamarin geklickt - dafür scheint der Button ja da zu sein - diese Aktion bringt mich zu diesem Link:

Ah, ja. Als Xamarin-Entwickler kennt man diese Webseite bereits, hier kann man sich, falls noch kein Xamarin-Login vorhanden ist, die Xamarin-Trial herunterladen – unter Angabe einiger weniger Informationen.


Gut, ich habe bereits meine Lizenz, aber trotzdem habe ich noch einmal alles eingegeben und den „Download Xamarin for Windows”-Button gedrückt. Das ist wohl eine weise Entscheidung, da die Datei “XamarinInstaller-VS2015.exe” heruntergeladen wird und es somit gut aussieht mit der VS 2015 Integration. Gleich mal „das Ding“ starten und der tollen Dinge harren, die da noch kommen mögen…


Nach der bekannten Installation (Android SDK, IOS-Integration,…) – welche ein klein wenig laaaaaange dauert, wenn man bisher noch kein Java und kein Android SDK installiert hatte, ist alles erledigt und der große Moment ist gekommen.

Nun, das dachte ich zumindest, der Xamarin-Installer verrichtet seine Arbeit sehr brav, allerdings sind in VS 2015 weit und breit keine Templates zu sehen – das dürfte allerdings nur auf Maschinen passieren, wo Xamarin bereits installiert ist.

VS 2015 Xamarin AddIn aktivieren

Um das zu beheben, erst einmal VS 2015 schließen und dann wiederum in „Programs and Features“ und „Xamarin“ anpassen.


Es wurde nämlich nicht automatisch die Integration für VS 2015 installiert, schade, aber das sind ja nur ein paar Mausklicks.

clip_image016 clip_image018

Neues Android Projekt – Versuch 2

So, jetzt aber, gleich wieder VS 2015 gestartet und die (erwarteten Templates tauchen wieder auf.


Sehr gut, dann kann es ja gleich losgehen mit einem neuen Xamarin.Forms Projekt.

Das sieht jetzt aber wirklich alles sehr gut aus, aber wiederum VORSICHT, falls Xamarin schon installiert war, das Xamarin SDK ist aus dem BETA-Channel und hat die Version 3.9.41 – falls die Meldung kommt, dass ein anderes SDK zur Verfügung steht, dann drückt bitte unbedingt “Abbrechen”, denn dann hattet ihr den Release, oder Beta Channel (wie ich z. B.) für Updates eingestellt.

Wenn alles gut geht, dann ist unser Projekt verfügbar.


Der Android Emulator

Wow, das klappt jetzt offenbar ohne Probleme, aber es wäre ratsam, dem Browserfenster, mit dem Link:

welches nach der Installation von Xamarin aufgepoppt ist, etwas Aufmerksamkeit zu widmen, hier steht nämlich:

“Please make sure that the following project property is NOT checked: Project -> Properties -> Android Options -> "Use Fast Deployment (debug mode only)"

Nun, wenn das schon ausdrücklich erwähnt wird, dann sollte man sich auch daran halten. ACHTUNG! Die Checkbox IST per default gesetzt, also weg mit dem Häkchen!


Jetzt fällt mir nicht mehr viel ein, außer:

· Das Android Projekt als Startprojekt festlegen und

· die Solution komplett erstellen.

Nun noch den Android Emulator starten - dieser scheint zu etwaigen bereits existierenden Emulatoren in dem (gewohnten) Dropdown in der Toolbar als “VS Emulator Android Phone“ bzw. “"VS Emulator Android Tablet” auf.


Gleich einmal auf den “VS Emulator Android Phone” draufgeklickt und was dann zu sehen ist, freut den “mobile Developer” gleich einmal ungemein: Es passiert wirklich etwas - nämlich im Output Fenster – und es kommt auch gleich eine Dialogbox dazu.


Nun, was ist ein Emulator für ein Android Device, ohne Internet? Eben, also auf den „Yes“-Button geklickt und ein wenig gewartet (eine gefühlte Ewigkeit, es waren aber dann doch nur ca. 2 Minuten), das Resultat aber nahezu BERAUSCHEND:

clip_image029 clip_image031

Der Emulator wie er sein sollte, mit der Xamarin.Forms Applikation!



Visual Studio 15 und Xamarin waren schon bisher eine sehr gute Kombination, wenn es um mobile, native Entwicklung gegangen ist. Mit der Integration des Android Emulators ist das Erlebnis für Entwickler noch einmal besser geworden. Ich freue mich auf viele weitere Applikationen, die mit dieser Kombination erstellt werden.

Berndt Hamböck ist seit 2007 MCT, darüber hinaus befasst er sich mit Lösungen für komplexe Anwendungsszenarien mit den neuesten Microsoft Technologien. Die Erfahrungen aus der Projektarbeit gibt er in Vorträgen und Trainings weiter und begleitet Entwicklerteams in Softwareunternehmen bei Projekten im Microsoft Umfeld.

Das ist ein Gastbeitrag. Die Meinung des Autors muss sich nicht mit jener von Microsoft decken. Durch den Artikel ergeben sich keinerlei Handlungsempfehlungen. Microsoft übernimmt keine Gewähr für die Richtigkeit oder Vollständigkeit der Angaben.

Hans-Peter Schelian: Microsoft Technical Summit 2014 in Berlin

2014-11-14_08-04-57Microsoft Technical Summit 2014 in Berlin – Mein ganz persönliches Resume

Zum ersten mal wurden von Microsoft (Deutschland) zwei Konferenzen für verschiedene Zielgruppen (IT-Pros und Developer) zu einer „großen” Konferenz zusammengelegt.

Der Microsoft Technical Summit.

Die Veranstaltung fand vom 11-12.11.2014 in Berlin im Hotel Moa mit ingesamt 800 Teilnehmern und einer stattlichen Anzahl von Gästen (inkl. dem neuen Mann an der Spitze bei MSFT Satya Nadella) statt.

Ich, der in früheren Jahren (fast) jede Microsoft Veranstaltung, egal ob diese in Deutschland oder USA stattgefunden hat, besucht hat um Neuigkeiten aus erster Quelle zu erfahren und um Kollegen zu treffen (ja das war früher noch mehr notwendig wie heute, da man nicht über soziale Netzwerke quasi ständig in einer großen WG gelebt hat), habe das in den letzten Jahren nicht mehr gemacht.

Diese „neue“ Veranstaltung in Berlin hat mich aber gleich aus mehreren Gründen dazu bewogen mal wieder an einer Microsoft Veranstaltung teilzunehmen.

  • Berlin, Berlin wir fahren nach Berlin
  • Netzwerken (auch mal wieder mit MSFT Mitarbeitern persönlich ein Gespräch führen)
  • MSFT ist seit 2 Jahren in einer tiefen Windows 8 Krise (so ist meine Meinung) und muss zeigen wie sie da raus kommen
  • Weil ich einfach Bock drauf hatte :-)

Kurz bevor der Trip nach Berlin los gehen sollte, dann aber „Streikankündigung“ durch die GDL.

HDNGDL GDL sag ich da nur, aber dann hat die GDL (sicher nicht wegen mir) Ihren Streik früher als angekündigt beendet und alles konnte wie geplant beginnen.

Nun da ich gerade im Zug nach Hause sitze kann ich aber sagen, dass nicht nur die Fahrt nach Berlin sondern auch die Rückreise mit der Bahn ziemlich planmäßig und problemlos funktioniert hat..

So nun aber (erst mal kurz) zum eigentlichen Event!

Der Tag 1 wurde eröffnet von einer Keynote mit einem “Special Guest Satya Nadella“!

2014-11-14_08-06-55Scheinbar wurde aber dessen Ankunft und der Zeitpunkt seines Auftritts im Vorfeld nicht so ganz 100 prozentig abgesprochen. Die Moderation der Keynote hat es deswegen nicht ganz leicht gehabt diese Ungewissheit um den tatsächlichen Zeitpunkt des Auftritts zu verbergen. Obwohl, ich sagen muss, dass sie es ganz gut gemacht haben.

Der eigentliche Auftritt von Satya Nadella war professionell, auch wenn man an seiner Körpersprache (ständig zappelnder Fuß) ein wenig Nervosität ablesen konnte.

Die fragen die man in der Q&A mit Satya Nadella gestellt hat, waren natürlich vorher (sicherlich von einem Team von Satya Nadella) ausgewählt und auch schon die Antworten vorbereitet. Auch wenn es nicht abgelesen oder auswendig gelernt wirkte, konnte man doch feststellen dass die Antworten im Vorfeld wohl überlegt ausgearbeitet wurden (OK, man hätte sich auch nichts anderes vorstellen können).

Auf die Session an beiden Tagen will ich nicht im einzelnen eingehen.

Es gab solche und solche. die einen mit mehr Informationsgehalt (für mich) die andere mit etwas weniger (für mich).

Aber bei Vorträgen, egal ob fachliche Vorträge oder andere, es gibt halt Menschen die könnten einfach aus dem Telefonbuch ablesen und es wäre kurzweilig und interessant und es gibt die anderen, die könnten das achte Weltwunder verkünden und man würde dabei einschlafen.

Ich möchte nun aber zuerst einmal auf die Organisation der Veranstaltung und auf den Veranstaltungsort zu sprechen kommen.

Microsoft hat mit dem Austragungsort Berlin sicherlich nichts falsch gemacht, beim Tagungshotel hingegen, bin ich mir nicht so sicher ob diese Wahl wirklich das Optimum war.

Folgende Dinge sind mir (negativ) aufgefallen.


Auf einem technischen Event (fast nur Nerds am Start) darf es doch heute nicht mehr sein, dass es kein W-LAN für die Teilnehmer gibt. Klar ist W-LAN für mehrere hundert Teilnehmer, mit vermutlich auch noch immer gleich 2 oder 3 Geräten (Es gab sicherlich den einen oder anderen der mit wesentlich mehr Gadgets aufgeschlagen war), eine Herausforderung, aber wir waren ja nicht beim Verband der Bäcker oder Metzger, sondern bei einer Veranstaltung von Microsoft, der Firma die “Mobile First Cloud First“ auf Ihre Fahne geschrieben hat. Hinzu kommt, das Microsoft die Teilnehmer dazu animiert sich unter Verwendung des Hashtag #msts14 sich auf Twitter und Facebook über die Veranstaltung zu äußern.

So geht „Social Media“ nicht.


Das Catering …. weiß gar nicht wo ich da Anfangen soll.

Das Catering war völlig überfordert.

Am ersten Tag war das Mittagessen teilweise völlig kalt (Kartoffel wie aus dem Kühlschrank), Fleisch (Schweinefleisch) mehr Rare als leicht rosa.

Was aber ganz besonders negativ aufgefallen ist, das war die Unfreundlichkeit mit der das Personal vom Catering mit uns den Teilnehmern umgegangen ist.

Hier ein Beispiel was ich mit unfreundlich meine:

Unsere Session vor dem Mittag war etwas früher zu Ende und ich wollte mit ein paar Kollegen noch vor dem Mittag einen Kaffee trinken und über die Session sprechen.
Dazu haben wir uns nach oben begeben und wollten uns einfach an einen der Tische stellen (an denen wir auch sonst zwischendurch gestanden haben um einen Kaffee zu trinken) und dort den eben bereits erwähnten Kaffee zu uns nehmen, bevor wir anschließend wenn das Buffet eröffnet, sicherlich auch etwas zu Mittag zu essen (Dieses bereits erwähnte kalte Essen). Beim Versuch uns an einen dieser Tische zu stellen (die nicht direkt am Catering standen) wurden wir (fast mit körperlicher Gewalt) dazu genötigt, dass wir bis ganz hinten ins anschließende Restaurant durchgehen sollte. Es würden gleich 800 Leute kommen und da könnten sich nicht die ersten hier vorne aufhalten.


  • Wir standen nicht ganz vorne (übrigens standen da schon andere an den Tischen rum)
  • Wir standen auch nicht im Bereich des Catering

Aber das wichtige ist eigentlich: Ganz egal was die sagten und welche Anweisungen auch immer die von wem auch immer bekommen hatten, hier wurde vollkommen vergessen wer Gast ist, „so“ kann und darf man nicht mit Gästen umgehen.

Das „Abendessen“ Burger war dann aber noch schlimmer als das Mittagessen.

Wie kann man bei 800 Personen, 2 Ausgabestellen mit jeweils 1 Person die Burger belegt, OK es war auch noch eine Person die vorher Ketschup auf die kalten Brötchen geschmiert hat, aufbauen.

Das war so unprofessionell

Die Schlangen, an die man sich anstellen musste um einen dieser „Burger“ zu erhaschen, wurden überhaupt nicht kleiner, schlimmer war dann nur noch das Essen selbst, die Burger lauwarm, das Brötchen ganz kalt.
Aber die absolute Krönung waren das was als Pommes Frites dazu gereicht wurden. Die Pommes wurden nicht frittiert sondern scheinbar in einer lauwarmen Fritteuse aufgetaut. Innen Roh und außen nur voll Öl gesaugt in etwa die Konsistenz einer zu lange gekochten Maccaroni.

Ich konnte das wirklich nicht Essen und ich glaube gut daran getan zu haben, da einer unserer Mittstreiter tatsächlich kurze Zeit später den Abend mit Magenkrämpfen frühzeitig beenden musste.


Wenn ich weiß, dass sich 800 Personen in meinem Hotel aufhalten und diese zu festen Zeiten sich in Tagungsräumen befinden und zu festen Zeiten Pause haben, dann „muss“ ich als Veranstalter (Hotel) dafür sorgen (können), dass die Sanitären Anlagen zu jeder zeit in einem einwandfreien sauberen Zustand sind.

In den Session Zeiten muss dann jemand in den Toiletten dafür sorgen dass die Eimer mit Papierhandtücher geleert und frische Handtücher und Seife aufgefüllt werden. Dann muss eben auch mal ein Putztrupp (oder eine Klofrau/Mann) dafür sorgen dass man sich nicht ekelt wenn man die sanitären Anlagen aufsucht.

Das ging gar nicht

Nachdem ich mich aber am zweiten Morgen (da sah es schon wieder so aus) per Twitter über den Zustand bei MSFT beschwert habe, nehme ich an dass man hier das Hotel darauf aufmerksam gemacht hat, da sich der Zustand in den Toiletten danach etwas gebessert hat.

Aber noch einmal zurück zum eigentlichen Event (den ich viel mehr hätte genießen können wenn die Rahmenbedingungen besser gewesen wären).

Unterm Strich bereue ich es trotzdem nicht einige hundert € in die Hand genommen zu haben und ein paar Tage die Arbeit im Büro ruhen habe lassen um an diesem Event teilgenommen zu haben.

Ich hatte sicherlich auch nicht, wie jemand auf Twitter meinte, “zu hohe Erwartungen” an die Veranstaltung.

Es hatten sicherlich auch nicht alle Sprecher Ihren besten Tag (OK, es gab auch einen der hatte wohl einen schwarzen Tag – Ich habe das mit „Ups die Pannenshow“ bezeichnet – Es hat einfach keine einzige Demo funktioniert), aber vielleicht war ich auch nur in der einen oder andere falschen Session.
Immerhin hatte ich sowohl am ersten als auch am zweiten Tag das Glück die eine oder andere „gute Session“ zu erwischen.

Dank Dariusz und Kollege Gunter hatte ich am ersten Tag einen guten Einstieg in die Sessions und am zweiten Tag hatte ich das Glück (auch wenn ich den Vortrag eigentlich schon kannte) einen wie immer gut aufgelegten Christian Weyer in einer voll besetzen Session bei seiner Aufführung anschauen zu dürfen.

Wenn mich heute jemand fragen würde ob ich beim nächsten Event dieser Art von MSFT (im gleichen Veranstaltungsort) wieder teilnehmen würde, wäre die Antwort vermutlich „eher nicht“. Was aber wirklich nicht an MSFT direkt und schon gar nicht an dem Format der Veranstaltung liegt, sondern einfach an mangelnder Professionalität der im Veranstaltungsort beschäftigen Mitarbeiter und des Managements dass diese Mängel in Ihrem Haus zulassen.

Nachdem ich einmal mehr gesehen habe das “Geld und große Namen” nicht unbedingt dazu führen dass eine Veranstaltung ein Selbstläufer wird muss ich auf jeden Fall zum Schluss all denen noch mehr Respekt zollen die es immer wieder schaffen geile Community Veranstaltungen in Eigenregie mit ganz kleinen Budgets auf die beine zu stellen.

Vielleicht sind auch 800 Leute einfach zu viel!

Christian Binder [MS]: Connect(); Visual Studio 2015 - .NET 5.0 - Azure

Auf dem Connect(); Event in NY wurden eine ganze Reihe von wichtigen Ankündigungen rund um Visual Studio 2015 – .NET 5.0 und Azure gemacht. Die Kurzfassung ist, dass Visual Studio Developer nun für alle Plattformen entwickeln können. .NET 5.0 ist OSS und wir werden eine .NET Server Framework auch Linux und OS X bereitstellen. Die Visual Studio Community Edition 2013, eine neue kostenfreie Visual Studio Version für nicht Enterprise Entwickler mit PlugIn Support, bietet im Team mit Visual Studio Online für kleine Teams eine kostenfreie ALM Lösung und IDE an. Besser gehts nicht.

Visual Studio 2015 Preview Downloads

Schaut Euch die Videos an:

Keynote: Developers in the mobile-first, cloud-first era


Visual Studio in a world of multiple devices


Cloud development with Azure and Visual Studio


Evolving software engineering practices

image [MS]: Microsoft Educator Grant Program–Azure für den Klassenraum

Mit unserem Microsoft Educator Grant Programm haben Lehrkräfte die Möglichkeit für sich und Ihre SchülerInnen/StudentInnen Zugang zu Microsoft Azure zu erhalten.

Jetzt zum Microsoft Educator Grant Programm anmelden!Und das sind die Benefits:

  • Lehrkräfte erhalten einen 12 Monats Account mit einer kostenlosen Konsumation bis 250 USD/Monat.
  • SchülerInnen/StudentInnen erhalten einen 6 Monats Account mit einer kostenlosen Konsumation bis zu 100 USD/Monat.

Anmeldung zum Microsoft Educator Grant Programm

Was man mit Microsoft Azure so alles machen kann erklären z.B. die kostenlosen online Trainings der Microsoft Virtual Academy oder unsere kostenlosen Azure Workshops:

Jetzt zum kostenlosen Microsoft Azure Workshop anmelden!

Jürgen Gutsch: Writing C# with Brackets

Nachdem Scott Hanselman gestern angekündigt hat, dass das OmniSharp Team die C# Unterstützung für Brackets bereitgestellt hat, musste ich das natürlich auch gleich mal testen.

Man findet die Erweiterung für Brackets, wenn man im “Extension Manager” nach “Omnisharp” sucht. Die Installation funktioniert Problemlos und nach einem Neustart von Brackets ist die Erweiterung auch aktiv und greift sobald eine C# Datei bearbeitet wird.

Es funktioniert erstaunlich gut und fühlt sich auch relativ gut an. Das Visual Studio mit seinen Extension möchte ich nicht missen, aber für den Fall, dass ich nur mal eine kleine Änderung in einer C# Datei machen sollte, ist das schon mal nicht schlecht.

Die Syntaxhervorhebung ist gut, nicht speziell, aber vergleichbar mit anderen Sprachen in Brackets:


Es findet auch tatsächlich eine Validierung des Codes statt, inklusive aussagekräftiger Informationen. Der Fehler hier ist, dass ich beim zweiten Console.WriteLine() ein zweites Argument erwarte, dass nicht existiert.

Das IntelliSense kann sich ebenfalls sehen lassen. Einzig die Auswahl per Enter statt Tab ist für Visual Studio Nutzer ungewohnt, in Brackets aber völlig normal:


Die oben erwähnte Validierung ist nicht perfekt, reicht aber für einfache Sachen aus. Es werden nicht alle Fehler gefunden. In diesem Fall ein Folgefehler des fehlenden Semikolons in Zeile 11 und der zweite Punkt in Zeile.


Entferne ich den Punkt der zu viel ist, bleibt der Folgefehler des fehlenden Semikolons. Dass es die Methode “Hallo” nicht gibt, wird erst bemängelt, wenn alle anderen Fehler beseitigt sind:


Das sind jetzt keine kritischen Probleme, sondern nur Punkte die mir auf Anhieb aufgefallen sind. Weiteres wird sich wohl zeigen, wenn ich weiterhin C# Code mit Brackets schreiben sollten.

Wem bis hierhin schon aufgefallen ist, dass die geschweiften Klammern im Java-Style geschrieben sind, dem sei gesagt, dass das das Standardverhalten in Brackets ist. Nicht schlimm; Abhilfe schafft der Punkt OmniSharp in der Menüleiste:


Der Punkt “Format Document” formatiert dann das ganze Document im C# Style um:


Alles in allem finde ich die Unterstützung von C# sehr gelungen. Vor allem auch, weil sich die Unterstützung sehr schön ins Brackets einfügt und nicht versucht das Visual Studio Verhalten hier aufzuzwingen.

Probiert es doch einfach mal aus :)

Karsten Kempe: Hot News zu Visual Studio, Visual Studio Online und Team Foundation Server

Microsoft-ConnectGestern und heute findet in New York der Microsoft Event Connect() statt und Microsoft hatte ihn schon im Vorfeld groß angekündigt. Die Erwartungshaltung in der Community war und ist dementsprechend hoch. Neuigkeiten zu Mobile, Cloud in DevOps sollten verkündet werden und Microsoft hielt Wort. Schon gestern wurden zahlreiche News verkündet – viele neue Features für Visual Studio Online und TFS, das .NET Framework wird Open Source, Visual Studio 2015 und einiges mehr. Eine Übersicht über die wichtigsten Announcements bekommt ihr hier:

Visual Studio Online und Team Foundation Server

Brian Harry und Co. kündigten gestern zahlreiche Erneuerungen für die ALM-Plattform von Microsoft an. Unter anderem wurde das vor einem Jahr veröffentlichte Visual Studio Release Management in Visual Studio Online integriert, was eine deutliche Verbesserung der Usability und der Konfiguration des Release Workflows mit sich bringen wird. Außerdem wurde ein neuer Hub in den Visual Studio Team Explorer integriert, mit dem Deployment-Umgebungen, sogenannte Environments, verwaltet werden können. Diese Environments können dann als möglicher Deployment-Ort im Visual Studio Release Management verwendet werden.

Ein neuer Projekttyp namens Cloud Deployment Projects ermöglicht eine Konfiguration der Deployment-Umgebungen im Json-Format, was den Deployment-Prozess an sich wesentlich einfacher und schneller machen soll.

Es gibt ein Video zu Release Management und Cloud Deployment von Brian Keller auf Channel 9, in dem die Neuerungen zusammengefasst werden.

Das Feature „Smart Unit Tests“ soll Entwicklern dabei helfen, eine gute Unit Test-Abdeckung für ihren Code zu bekommen. Smart Unit Tests analysiert den Source Code und erstellt auf Knopfdruck den passenden Unit Test. Jeder Smart Unit Test kann anschließend gespeichert werden und in eine Art Regression Test-Datenbank hinterlegt werden. Smart Unit Tests basiert auf dem Microsoft Research Projekt „Pex“ und ist vielleicht dem einen oder anderem dadurch schon bekannt.

Für das Agile Projektmanagement des TFS gibt es auch ein paar Änderungen. Unteranderem ist es ab sofort möglich (in Visual Studio Online), Bug Work Items, die als Kind eines PBIs oder Requirements verlinkt sind, auf dem Kanban Board und dem Task Board anzuzeigen.

Als weiteres Highlight ist die Vorschau auf das neue Build-System des Team Foundation Servers zu verstehen. Durch den neuen Build-Service wird es erheblich einfacher, Anpassungen am Workflow durchzuführen als bisher. In Zukunft werden Builds nicht mehr über den bekannten XAML/Workflow definiert, sondern es können ganz einfach im Web Access Sequenzen aus verschiedenen Aufgaben zusammengestellt werden.

Ein persönliches Highlight für mich ist die Versionierung der Build-Definitionen. Dadurch wird es in Zukunft möglich sein nachzuverfolgen, wer eine Build-Definition geändert hat und warum.

.NET goes Open Source

Microsoft wird ab jetzt Teile seines .NET Core Frameworks und .NET Core Runtime öffentlich zur Verfügung stellen. Damit erhält jeder Entwickler die Möglichkeit, an diesem Open Source-Projekt mitzuwirken. Der Source Code steht ab sofort unter bereit.

Visual Studio Community Edition

Ab sofort steht eine neue Edition von Visual Studio zum Download bereit – Visual Studio Community 2013 Update 4. Diese Edition löst die vorherige Express Version von Visual Studio ab und soll alle Features beinhalten, die auch in der Professional Variante zu finden sind. Verwenden dürfen diese Version all jene, die an einem „offiziellen“ Open Source-Projekt mitarbeiten, die Software-Entwicklung an der Schule oder Uni erlernen oder praktizieren sowie Firmen, die der Microsoft-Firmen-Definition entsprechen – siehe Auszug unten. Im Folgenden findet ihr einen kurzen Auszug aus den VS Community-Richtlinien:

For organizations, following conditions apply:

• Any number of your users may use the software to develop and test your applications released under Open Source Institute (OSI)-approved open source software licenses.

• Any number of your users may use the software to develop and test your applications as part of online or in person classroom training and education, or for performing academic research.

If none of the above apply, and you are also not an enterprise (defined below), then up to 5 of your individual users can use the software concurrently to develop and test your applications.

• If you are an enterprise, your employees and contractors may not use the software to develop or test your applications, except for open source and education purposes as permitted above. An “enterprise” is any organization and its affiliates who collectively have more than (a) 250 PCs or users or (b) one million dollars (or the equivalent in other currencies) in annual revenues, and “affiliates” means those entities that control (via majority ownership), are controlled by, or are under common control with an organization.

Q: Can independent contractors working for an enterprise customer use VS Community?

A: Per the EULA, contractors doing work on behalf of an enterprise are treated the same way as the enterprise’s employees. No use is permitted for this work beyond the open source and education scenarios specified in the EULA.

Update 4 für Visual Studio 2013 und Team Foundation Server 2013

Eher eine Randerscheinung und fast untergegangen durch all die verkündeten Erneuerungen, aber für alle on-prem Nutzer des TFS trotzdem von Bedeutung, ist das neue Update für Visual Studio und TFS. Update 4 steht nun als produktive Version zum Download bereit. In folgenden Bereichen des TFS gibt es Erneuerungen:

  • Release Management
  • Test
  • Version control
  • Plan and track work
  • Access level name changes and feature access

Detaillierte Infos gibt es auf der News Seite von Visual Studio.

Visual Studio 2015 Preview

Eine erste Preview Version von Visual Studio 2015 steht nun zum Download bereit und kann Side-by-Side zu Visual Studio 2013 installiert werden. Darin zu finden sind einige Neuerungen für cross-platform development, web & cloud development sowie einige Produktivitätsverbesserungen. Die Version ist noch nicht für den produktiven Einsatz gedacht, sondern wird uns von Microsoft zur Verfügung gestellt, um erstes Feedback zur Version einzusammeln. 





[5] [MS]: Visual Studio Aktion für alle KMUs & Einzelpersonen

In Open License läuft bis Ende Dezember eine sehr attraktive Aktion zum Erwerb von Visual Studio. OPEN Licenserichtet sich an unsere Kunden im Klein- bis Mittelbetriebssegment aber auch an Einzelpersonen (Visual Studio kann im OPEN Programm bereits ab einem Stück erworben werden).

Vorteile sind:

  • Die Anschaffungskosten können über 3 Jahre verteilt werden (bei OPEN Value)
  • Bei Vertragsverlängerung nur mehr die günstigeren MSDN/Wartungskosten sowie Upgraderecht auf die jeweils aktuellste Version (so lange MSDN/Software Assurance aufrecht ist)
  • Bis zu –25% auf Visual Studio


image [MS]: Connect(“Keynotes, Day1-Auf einen Blick”);

Gestern fand Tag Eins von Microsoft Connect(); in New York statt. Gerwald hat hier bereits darüber gebloggt und viele Neuerungen aus der Keynote und den Sessions zusammengefasst.

Microsoft hat das Event genutzt, um eine Reihe von Ankündigungen und Neuerungen für Developer zu veröffentlichen. Die Webcasts von Tag Eins können bereits auf downgeloadet oder live angesehen werden.

Für alle jene, die sich ganz rasch informieren wollen, finden hier eine Zusammenfassung der wichtigsten Themen aus der Keynote – als “Bildergeschichte” auf einen Blick.

ScottGu eröffnete die Veranstaltung in seinem klassischen Outfit mit rotem Poloshirt und Jeans…


Aktuell betreibt Microsoft 19 Datacenters weltweit.


Microsoft will .NET und Developer, die .NET, Visual Studio und Azure verwenden, fördern.
Die veröffentlichten Zahlen sind beeindruckend.


“DevOps” ist bei Microsoft derzeit das beliebteste Schlagwort…


Nicole Herskowitz zeigte einen Showcase “MyShuttle” mit mobilen Geräten.


Microsoft arrbeitet eng mit Xamarin zusammen. Damit können native Apps für Windows Phone, Android und iOS erstellt werden. Mobile Websites können ebenso verwendet werden. Push Notifications via Azure Services und SignalR ermöglichen eine sofortige Kommunikation.


Machine learning und Internet of Things (IoT) werden in Zukunft für Develope eine wichtige Rolle spielen. Das Demo zeigt unter anderem gesammelte Daten von Fahrzeugen und Fahrern ansprechend visualisiert.


Das neue Azure Portal sieht ebenso ansprechend aus – und liefert eine Vielzahl an Informationen über Status,, Performance und sogar Code Qualität einer App.


..Visual Studio ist das Tool für alles – ein Entwicklungswerkzeug und alles an einem Ort.


Scott kündigte die Open Source-Veröffentlichung von .NET Core Runtime und Framework an (die Sourcen werden auf GitHub bereit gestellt)…


…die official .NET server framework distributions for Linux and OS X wurden angeküdigt – das bedeutet ASP.NET 5.0 Apps werden auf Windows, Linux und Mac lauffähig sein.


…zusätzlich wurde eine neue, kostenfreie Version von Visual Studio angekündigt, die “Free Visual Studio Community” Edition – für den Nicht-Kommerziellen Einsatz von Visual Studio (eine volle Version ohne dass irgendeine Mitgliedschaft in einem Microsoft-Programm nötig ist).


Ziemlich viel Neuigkeiten in einer knappen halben Stunde!

Was sich in den weiteren Sessions getan hat findet ihr zusammengefasst in Gerwalds´ Blogpost und in den Videos auf channel9!

Jürgen Gutsch: Great News for .NET Developers

Da fahre ich gestern ahnungslos zum .NET-Stammtisch  Konstanz-Kreuzlingen zu einem Vortrag über Mono auf dem Raspberry PI, twittere dieses Ereignis und erhalte als Antwort Das geht doch jetzt mit .NET.

“Nein”, denke ich zuerst, was ist denn das für ein Kommentar. “Jein” denke ich später. Natürlich kann ich .NET-Assemblies im Optimalfall auch mit Mono ausführen, aber dennoch benötige ich Mono.

Der Antwort auf Twitter machte mir auf dem Weg zum Stammtisch schon etwas zu schaffen und mir war schnell klar, das sich etwas verpasst haben musste, als ich mehrere Stunden meine Twitter-Timeline nicht verfolgen konnte. Schließlich finden im Moment zeitgleich zwei Microsoft Konferenzen statt, auf denen es sicher auch eine ganze Menge neuer Ankündigungen gibt. Zum einen ist das das Technical Summit 2014 in Berlin und zum anderen die Connect(); in New York.

Also: Danke vielmals, für den Hinweis an Alexander Witkowski :)

Nach dem ich nun meine Timeline durchgegangen bin war schnell klar, was passiert ist:

Microsoft hat angekündigt, die .NET-Core Libraries und die .NET CLR Open Source zur Verfügung zu stellen. Konkret bedeutet das: Horror für alle Open Source Gegner ;)

Die Durchsicht der Timeline und der neuesten Blog-Artikel, unter anderem von Scott Hanselman und Scott Guthrie zeigte sich aber, dass weit mehr passiert ist, als nur diese Ankündigung:

  • Die .NET Core Libraries sind nicht nur Open Source sondern auch als NuGet Packet zu haben. Was zu einer gewissen Unabhängigkeit von .NET Installationen führt. Jede Applikation kann ihr eigenes .NET-Framework mitbringen.
  • Die .NET CLR ist Open Source und es gibt nun Versionen für Linux und Mac. Ob sich .NET dort durchsetzt ist eine andere Frage, aber sicher ist, dass Mono davon profitieren kann und wird.
  • ASP.NET 5 wird wohl auch auf Mac und Linux laufen können und einen eigenen Webserver mit dem Namen “kerstel” mitbringen der ähnlich wie der von node.js funktioniert
  • .NET 4.6 wird unter der MIT Lizenz als Open Source zur Verfügung gestellt. Auch hier wird ganz sicher auch Mono profitieren können. Somit werden mehr .NET-Applikationen einfacher unter .NET und Mono laufen können.
  • VS2013 Update 4 wurde veröffentlicht.
  • Die Unterstützung für xUnit wurde ins Visual Studio wohl direkt integriert.
    • An einigen Stellen in der Twitter Timeline meine ich gelesen zu haben, dass man nun generell auf xUnit statt auf MSTest setzen sollte. Abgesehen davon dass ich niemandem empfehle MSTest zu verwenden.
  • Was schon länger angekündigt wurde: Das Visual Studio 2015 und ASP.NET 5 unterstützen nun gulp, grunt, bower und npm für Web Frontend Entwickler.
  • Das Team um Omnisharp bringt Intellisense für C# nach Sublime, Atom, Brackets, Vim und Emacs auf Windows, Linux und Mac.
  • Weiterhin gibt es nun eine Community Edition des Visual Studio, die im Gegensatz zu den sinnfreien Express Editions, Solutions mit mehreren Projekten unterstützt und Extensions und Add-Ins zulässt. So können ReSharper, Web Essentials, etc. genutzt werden.

Die Community Edition des Visual Studio steht allen frei zur Verfügung, ebenso kleinen Unternehmen mit bis zu fünf Entwicklern. Dieser Schritt ist notwendig, wenn man .NET für mehrere Systeme bereitstellt und gegen die freien IDEs anderer Plattformen durchsetzen möchte. Immerhin entscheiden sich viele Einsteiger für alternativen zu .NET, da es bisher keine freie IDE von Microsoft gab, die auch tatsächlich für größere Projekte nutzbar gewesen war. Alternativen wie SharpDevelop oder MonoDevelop/XamarinStudio sind zwar gut, bieten aber dennoch nicht den Umfang den das Visual Studio liefert.

Übrigens gibt es weitere Neuigkeiten, speziell zur ASP.NET, die ich aber in einem weiteren Beitrag zusammenfassen möchte. Vorab eine Übersicht von Xinyang Qiu: Announcing ASP.NET features in Visual Studio 2015 Preview and VS2013 Update 4

Wow. Einfach nur geil.

Ich hatte vor einiger Zeit schon zu einer Art Loblied auf die offene Arbeitsumgebung für die .NET-Entwicklung angesetzt, aber was hier passiert ist eine komplette Öffnung der .NET-Umgebung. Das die Community in Quelloffene .NET-Bibliotheken von Microsoft contributet ist schon cool genug, aber dass nun tatsächlich die .NET Core und die .NET CLR unter der MIT Lizenz auf GitHub öffentlich gemacht wird, steigert das ganze. Die Unterstützung für grunt, bower und npm im Visual Studio macht die Entwicklung für Web-Anwendung um eine sehr großes Stück flexibler. So ist das Visual Studio nicht mehr rein für .NET-Applikationen sondern auch für .NET-freie Web Frontends nutzbar.

Ich bin gespannt, wie sich das in Zukunft auf die Arbeitsweise auswirken wird. Fakt ist, dass Microsoft mit diesem Schritt einigen Skeptikern die Luft aus den Segeln genommen hat, aber auch einigen Open Source feindlichen unternehmen etwas Trouble bereiten wird. Besonders um letzteres freut es mich tatsächlich etwas. ;)

Ebenfalls Lesenswert: Thomas Bandts Meinung zu den aktuellen Neuerungen: .NET wird Open Source und kommt auf Mac + Linux

Thomas Bandt: .NET wird Open Source und kommt auf Mac + Linux

Eigentlich wäre ich heute und gestern auf dem Microsoft Technical Summit in Berlin gewesen, wäre nicht etwas dazwischengekommen. Egal, denn die wirklichen News von Microsoft kamen heute Nachmittag aus New York.

Und was für welche: Microsoft legt den Quellcode von .NET offen, akzeptiert Pull-Requests, stellt alles unter eine vernünftige Lizenz (MIT!) und führt es mit Mono zusammen, um auch Linux und OS X inklusive offiziellem Support (!) zu unterstützen.

Was sich mit Roslyn und ASP.NET vNext (zukünftig ASP.NET 5.0) schon im Verlauf des Jahres abzeichnete, nimmt jetzt also seinen vorläufigen Höhepunkt.

Ich muss zugeben, dass das auch einige meiner Gedanken von gestern ordentlich durcheinander wirbelt.

Denn wir reden jetzt hier – zumindest für die Webentwicklung – nicht mehr von einem pseudo-offenen System, sondern von echtem Open Source. Noch mal: MIT-Lizenz, Git-Repositories, Akzeptanz von Pull-Requests.

Dazu fallen auch die elenden Lizenzkosten-Debatten weg, denn ASP.NET kann damit auf jedem beliebigen System entwickelt und betrieben werden – inklusive dem Serverbetriebssystem Nr. 1, Linux.

Die Entwicklung unter Windows kann weiter mit Visual Studio stattfinden – was in der Community-Edition nun die reichlich sinnfreien Express-Varianten ablöst und selbst für Startups mit bis zu fünf Entwicklern für kommerzielle Anwendungen kostenlos (!) verfügbar ist.

Ich denke es ist nicht zu hoch gegriffen, wenn man das als Wendepunkt sowohl für Microsoft, als auch für die vielen, vielen Entwickler betrachtet.

Zu was es genau führen wird, bleibt abzuwarten. Zumal die Ankündigungen heute noch nicht vollständig mit realen Umsetzungen einherkommen – es wird noch ein paar Monate dauern, bis den Worten endgültig Fakten gefolgt sind.

Doch ich bin vorsichtig optimistisch und würde mir wünschen, dass .NET mit seinen großartigen Sprachen C# und F# nun auch bei Entwicklern und Unternehmen, die bisher einen Bogen um Microsoft gemacht haben, Traktion bekommen wird.

Es fühlt sich zumindest schon mal so an, als wäre mein Know-How heute wertvoller geworden. Das ist doch schon mal was ;-).

Mehr Infos:

| Kommentieren | © 2014 Thomas Bandt [MS]: Connect(“Keynotes, Day1”);


Heute Abend wurde der erste Tag des Connect(); Eventsin New York live übertragen – die Vorträge stehen auch on-demand zur Verfügung.

“There has never been a better time to be a software developer” waren die Eröffnungsworte des ersten Keynote-Sprechers Scott Guthrie und die Ankündigungen zu den Themen Innovation, Agilität und Offenheit/x-Plattform haben dies auch wirklich unterstrichen.


In den ersten beiden Keynotes mit Scott Guthrie & Soma Somasegar wurde unter anderem die Preview von Visual Studio 2015 und die Verfügbarkeit von Visual Studio 2013 Update 4 angekündigt. In vielen interessanten Demos wurden verschiedene Aspekte zur x-Plattform Cliententwicklung vorgestellt – natürlich durfte Xamarin und die Apache Cordova Integration in Visual Studio dabei nicht fehlen sowie Microsoft Azure um die Applikation (Backend) zur Verfügung zustellen. Beeindruckend war auch die Debug-Funktionalität auf nicht-Microsoft Geräten die direkt in Visual Studio integriert ist.
Eine weitere Ankündigung betraf das .NET Core Framework sowie das .NET Server Framework welche als Open Source Projekte verfügbar sein werden sowie eine offizielle Portierung des .NET Server Framework für Linux und MacOS in den kommenden Monaten.


Nach einer kurzen Pause folgten zwei weitere Keynotes mit Scott Hanselman sowie Brian Harry & Brian Keller – wobei ich mich hier auf die Visual Studio Online und Team Foundation Server Ankündigungen fokussieren möchte.
Gezeigt wurde Release Management in Visual Studio Online mit einer DSC-Konfiguration für Applikationsressourcen die in Microsoft Azure laufen. Brian Harry hat auch eine Enterprise-Roadmap für Visual Studio Online angekündigt – in der aktuellen Umsetzung befindet sich die Möglichkeit “Process Templates” auch in Visual Studio Online modifizieren zu können sowie eine umfangreichere Reporting-Funktion. Folgend auf die Ankündigungen zu Thema Offenheit/x-Plattform hat Brian Keller auch die nächste Generation von Build Management in Visual Studio Online gezeigt (die Build Templates können nun auch im Webbrowser modifiziert werden und werden versioniert, Rückmeldungen des Build Agents werden “live” dargestellt). Angekündigt wurde aber auch ein Build Agent für Linux und MacOS – besser gesagt ein node.js basierter Build Agent der auf einer Vielzahl an Plattformen genutzt werden kann.

Lars Keller: DNUG Braunschweig Treffen - Hello Xamarin! Native iOS und Android Apps in C# !

Die DNUG Braunschweig trifft sich am 17.11.2014 um 19:00 im Restaurant Zucker (Tagungsraum). Dieses Mal halten unsere Mitglieder Benjamin Schmidt und Dominik Spohr einen Vortrag über Xamarin.

Xamarin ermöglicht nicht nur die Entwicklung 100% nativer iOS- und Android- Apps mit der Programmiersprache C#, sondern bietet umfangreiche Tools von einer VisualStudio-Integration mit hochwertigen Designern über Qualitätssicherung mithilfe einer Test Cloud bis zur Echtzeitanalyse im Betrieb.
Die beiden Entwickler Dominik Spohr und Benjamin Schmidt aus der H&D AppFactory stellen Ihnen die Xamarin-Welt vor und zeigen beispielhaft welche Herausforderungen und Lösungen es bei der Crossplattformentwicklung mit Xamarin gibt.
Dieser Vortrag richtet sich an Entwickler und Entscheider, die auf der Suche nach einer effizienten Lösung für die Entwicklung mobiler Apps sind.
Die Referenten:
Benjamin Schmidt und Dominik Spohr arbeiten als App-Entwickler und Xamarin-Consultant in der AppFactory der H&D International Group.
Dort beschäftigt sich Benjamin hauptsächlich mit der Frontend-Entwicklung und Dominik mit der Backend-Entwicklung für Windows-, iOS- und Android-Apps.
Zudem halten sie Vorträge und Workshops über die App-Entwicklung mit Xamarin.

Wie immer ist die Veranstaltung kostenlos!
Weitere Informationen zur DNUG Braunschweig können hier gefunden werden: [MS]: Wie komme ich zu kostenlosen MCP Prüfungen für Entwickler?

… oder wie Euch das Lesen dieses Blog Beitrages bis zu € 600.- und noch mehr sparen helfen kann!!

Solange der Vorrat reicht gibt es jetzt kostenlose Gutscheine für MCP Prüfungen rings um Microsoft Azure und Office 365. Wer schnell ist kann sich hier also einen tollen Wissens und Wettbewerbsvorteil sichern. Folgende vier Prüfungen kann man derzeit kostenlos ablegen:

Um den Microsoft Certified Specialist in Azure zu erlangen gibt es diese beiden Kurse / Prüfungen (siehe “Microsoft Azure training” -

Um den Microsoft Certified Solutions Associate in Office 365 zu absolvieren müssen beide Prüfungen bestanden werden (Siehe “Microsoft Office 365 training” -

Die kostenlosen Gutscheine kann man jetzt bestellen und dann bis 31. Dezember dieses Jahres in einem Prometric Test Center seiner Wahl einlösen.

Für viele weitere Prüfungen bekommt man derzeit 15% Rabatt. Alle Kurse die mit “70-,” “72-,” oder “73-” beginnen sind derart vergünstigt. Diesen 15% Rabatt kann man sowohl bei Prometric als auch Pearson VUE Test Centern lukrieren..

Mehr zu diesen beiden Angeboten gibt es am Born To Learn Blog ( bzw. auf der Born to Learn Goodies Webseite:

Zur Vorbereitung auf die Prüfungen bieten sowohl unsere Microsoft Learning Partner also auch die Microsoft Virtual Academymit Kursen rings um Microsoft Azure und Office 365 einiges an tollen Lerninhalten.

MVA Kurse zu Microsoft Azure

Marco Scheel: Links for 2014-11-11 []

Thomas Bandt: ASP.NET – quo vadis?

In den letzten Wochen hatte ich die Gelegenheit, nach mehr als 13 Jahren Webentwicklung mit Microsoft-Technologien einmal wieder innezuhalten und über den Tellerrand zu schauen.

Nach meinen ersten eher kläglichen Gehversuchen mit PHP ab Ende der Neunziger des vergangenen Jahrhunderts [sic!] war es 2001 schließlich ASP, was bei mir für den großen Aha-Effekt und für dauerhafte Begeisterung sorgte. Nicht weil VBScript so schön gewesen wäre – aber es war einfach zu verstehen, unglaublich schnell und die Lernkurve war flach.

Das konnte man schon von ASP.NET und den neuen WebForms nicht mehr behaupten. Es dauerte bis Anfang 2004, als ich hier schließlich den Einstieg in die damalige Version 1.1 fand und letztendlich dann doch alles darauf umstellte, was irgendwie in meiner Verantwortung lag.

Wer WebForms nur von Erzählungen her kennt, der wird kaum verstehen wie man sich (und dem Web) das antun konnte, aber ganz ehrlich: es funktionierte. Und wenn man ein bisschen darauf aufpasste, was man wo tat – also z.B. für öffentliche Websites auf Postbacks und damit kiloweise ViewState verzichtete – konnte man gute, flexible und sehr performante Sachen damit bauen (z.B. dieses Blog und dutzende weiterer Seiten von mir aus dieser Zeit).

Das mag dann auch der Grund dafür gewesen sein, weshalb ich vor 7 Jahren zunächst recht skeptisch war, als die ersten Previews von ASP.NET MVC auftauchten.

Mein Fazit von damals hatte nicht lange Bestand – es dauerte nicht mehr lang und alles, was ich irgendwo auf der grünen Wiese bauen konnte, baute ich – natürlich – mit ASP.NET MVC.

Das war allerdings auch die Zeit, als es noch legitim war, Formular-Validierungen beispielsweise ausschließlich serverseitig durchzuführen. Ich glaube JavaScript habe ich damals in Form von jQuery höchstens benutzt, um hier und da ein DIV zu toggglen ;-).

Heute sind wir wieder ein gewaltiges Stück weiter: gerade bei Webanwendungen ist sehr viel Logik ins Frontend gewandert, was sich am – die serverseitigen Technologien übergreifenden – Erfolg von AngularJS & Co. zeigt.

ASP.NET MVC ist heute bestenfalls noch dafür da, das Ganze zu orchestrieren und Styles, diverse Libraries und die HTML-Views zusammenzustecken.

Die serverseitige Logik steckt normalerweise in einem eigenen Projekt, das mit ASP.NET Web API läuft und das nichts als JSON entgegennimmt und wieder ausspuckt.

Visual Studio ist dabei über all die Jahre eine gute Entwicklungsumgebung geblieben, und heute mit den Add-ons ReSharper, Web Essentials und Web Workbench in meinen Augen noch immer ein Werkzeug von hoher Qualität.

Doch trotz des .NET Frameworks unter der Haube und der IDE von Microsoft ist doch nicht zu leugnen, dass sich der überwiegende Teil der Nummer nicht mehr um Technologien aus Redmond dreht: AngularJS als eigenes Frontend-Framework, Sass für eigene Stylesheets und Bootstrap für den Rahmen – all das kann man genauso gut auch am Mac oder unter Linux entwickeln.

Dazu kommt, dass ich in meinen letzten Projekten auch auf anderen Ebenen die Microsoft-Welt mal bewusst und mal unbewusst verlassen habe. So haben wir z.B. für Whatstays im Backend auf RavenDB, MongoDB und PostgreSQL gesetzt, aber nicht auf den SQL Server, obwohl ich den seit der 2000er Variante überall im Einsatz hatte.

Und nur um eine kleine Webanwendung zu betreiben, deren überwiegender Teil von der serverseitigen Plattform vollkommen unabhängig ist, fühlt es sich manchmal auch an, als würde man mit Kanonen auf Spatzen schießen.

Anlass genug, mich einmal mit Alternativen zu beschäftigen.

Ich habe das natürlich auch genutzt, um zu überlegen, was die Zukunft bringen mag – oder besser, was man in der Zukunft bringen muss, um noch vorne dabei sein zu können. Dass .NET gerade im Enterprise-Bereich weiter eine bedeutende Rolle spielen wird, ist unbestritten. Aber ebenso wenig kann man darüber diskutieren, dass das nächste Facebook oder Google eher auf Open Source-Technologien basieren wird, als auf .NET.

Das im Hinterkopf habe ich mir verschiedene Umgebungen angeschaut: die JVM (Java, Scala; Spring, Play etc.), Django (Python), Ruby on Rails (Ruby), PHP (nein, nicht wirklich) und Node.JS (JavaScript).

Die Java-Welt ist im Enterprise-Bereich ebenso stark vertreten wie .NET, dazu setzen auch einige größere Startups darauf. Sicherlich kein schlechter Stack, aber allein die Unzahl der verfügbaren Web Frameworks lässt einen Umstieg schon zum Lottospiel werden. Rein technologisch für mich keine Verbesserung, weshalb ich da die Finger von lasse, wenn ich nicht durch irgendeinen blöden Zufall da hineinrutsche (von C# zu Java ist es ja nur ein Katzensprung).

Django und Ruby on Rails profitieren von zwei schönen Sprachen, wobei das Python-Lager ja schon sehr gespalten scheint, weil der Sprung von Sprachversion 2 zu 3 so groß sein soll. Beide Kandidaten sind in der Startup-Bubble durchaus gern gesehen, im gesamten Markt spielen sie aber nach meiner Wahrnehmung eher eine marginale Rolle.

Node.js hingegen ist “the cool kid on the block”. Nicht mehr in den Kinderschuhen und von einigen großen Playern wie PayPal, Yahoo und LinkedIn inzwischen großflächig eingesetzt. Und mit einem nicht zu unterschätzenden Vorteil: Die Lernkurve ist (selbst erprobt) flach, das ganze Ding ist sehr schlank, auf jeder beliebigen Plattform lauffähig und die Sprache dahinter beherrschen alle guten Fullstack-Webentwickler: JavaScript.

Zwar verbindet mich mit JavaScript eine Art Hassliebe, aber schreiben muss ich es am Client sowieso. Bzw. kann ich auch auf TypeScript oder Coffeescript und demnächst AtScript setzen und mir diverse Painpoints durch Tooling lösen lassen, wie es bei CSS mit Less oder Sass inzwischen ja auch gemeinhin akzeptiert ist. Und mit Ecma Script 6 werden ja eh Milch und Honig fließen.

Fazit: Ich schätze ASP.NET sehr, aber die Zeit ist reif für ein paar Experimente. Mehr vielleicht in Kürze hier ;-).

| Kommentieren | © 2014 Thomas Bandt

Thomas Bandt: UrlRewritingNet und mite.desk auf GitHub

Nachdem ich in den letzten Wochen etwas Zeit hatte, habe ich mich unter anderem dazu entschieden, zwei meiner nicht tot zu kriegenden ;-) Nebenbei-Projekten ein neues Zuhause zu geben.


Vor inzwischen 8,5 Jahren [sic!] hatte diese kleine Komponente das Licht der Welt erblickt, deren Aufgabe es war, lesbare und (damals) suchmaschinentaugliche URLs mit ASP.NET 2.0 zu ermöglichen.

Mit mehreren hunderttausend Downloads über die ehemalige Projekt-Website und der Verwendung in halbwegs populären Projekten wie Umbraco kam das gute Stück dann auch ein bisschen rum – und ist teilweise heute immer noch im Einsatz.

Der Quellcode findet sich nun zusammen mit Doku und Binaries hier.


mite.desk ist ein Windows-Client für die Zeiterfassung mite. Im Sommer 2009 entwickelt und veröffentlicht, habe ich die Anwendung mehr als fünf Jahre lang gegen einen kleinen Unkostenbeitrag angeboten.

Da sich das rein wirtschaftlich nie getragen hat und ich auch keine Zeit mehr habe, mich um das Projekt zu kümmern, habe ich es ebenfalls auf GitHub gepackt.

(Man muss sagen, dass der Code – vielleicht auch durch die [MS]Tests – ziemlich reibungslos und zuverlässig funktioniert. Anders, als ich angenommen hatte, lag der Supportaufwand über die Jahre nahe Null. Erstaunlich für eine Desktop-Software. Vielleicht komme ich auch noch mal zum Aufräumen - meinen eigenen Konventionen von 2014 würde der Code aus 2009 nämlich eher nicht mehr standhalten ;-).)

| Kommentieren | © 2014 Thomas Bandt

Holger Schwichtenberg: .NET vNext im Überblick

Anlässlich eines Vortrags zur Zukunft des .NET Framework auf dem Microsoft Summit 2014.

Ralf Westphal: Die vielen Gesichter des Product Ownership

Wie sollte, wie kann Product Ownership aussehen? Stefan Rook hat dazu einen Vortrag gehalten: Product Ownership hat also viele Gesichter. Diese Botschaft hat mir an dem Vortrag gefallen. Mir hat allerdings auch etwas gefehlt. Nämlich die Abstraktion. Was ist das Muster? Worum geht es im Kern? Mag sein, dass das schon allen klar ist. Meine Erfahrung ist jedoch, dass die meisten Unternehmen genau [MS]: Teil 3: Plattformübergreifende App-Entwicklung mit dem MVVMbasics Framework

Gastbeitrag von Andreas Kuntner

Dieser Artikel ist der zweite Teil einer dreiteiligen Serie. (Teil 1, Teil 2)

Andreas Kuntner arbeitet als .NET Entwickler mit Schwerpunkt auf Client-, UI- und Mobile Development, und betreut in seiner Freizeit das MVVMbasics Framework und den Developer-Blog

Definition der Views

Ich habe beide Pages im Shared-Projekt angelegt, es wäre aber genauso möglich für beide Plattformen unterschiedliche Pages zu definieren und diese im jeweiligen Windows- bzw. WindowsPhone-Projekt zu hinterlegen. Wichtig ist, dass alle Views (egal ob WinRT-Page oder WPF-Fenster) von der BaseView-Klasse abgeleitet sind, und zwar sowohl im XAML- als auch im C#-Code. In XAML bietet es sich außerdem an, das entsprechende Viewmodel als Design-Time-DataContext anzugeben, denn dadurch können Properties und Commands mit Hilfe von IntelliSense schneller gefunden werden:

	d:DataContext="{d:DesignInstance viewmodels:LoginViewmodel}">

Auf keinen Fall sollte die normale DataContext Eigenschaft der View manuell mit einer Instanz des Viewmodels befüllt werden, darum kümmert sich das NavigatorService automatisch.

Im C#-Code der View ist es außerdem notwendig, das [MvvmNavigationTarget] Attribut zu setzen. Dieses sagt dem NavigationService während der automatischen Registrierung, dass es sich bei dieser Klasse um eine View handelt und mit welchem Viewmodel sie verbunden werden soll. Abgesehen davon sollte aber – ganz dem MVVM-Pattern folgend – nichts im C#-Coder der Views stehen:

public sealed partial class LoginPage : BaseView
	public LoginPage()

In XAML können nun die beiden Pages nach Lust und Laune gestaltet werden. Um auf Properties oder Commands des jeweiligen Viewmodels zuzugreifen, kann wie gewohnt Binding verwendet werden. Die beiden Textfelder zur Eingabe von Namen und Alter sowie der Login-Button schauen in meiner Demo beispielsweise so aus:

<TextBox Text="{Binding Name, Mode=TwoWay, UpdateSourceTrigger=PropertyChanged}" />
<TextBox Text="{Binding Age, Mode=TwoWay, UpdateSourceTrigger=PropertyChanged}" InputScope="Number" />
<Button Command="{Binding LoginCommand}">Einloggen</Button>

Die Angabe von UpdateSourceTrigger=PropertyChanged im Fall der beiden Textboxen ist notwendig, um Änderungen innerhalb einer Textbox noch während dem Tippen ans Viewmodel weitergeleitet werden, und nicht erst wenn die Textbox den Focus verliert. Dadurch wird auch die Bedingung des Button-Commands sofort während dem Tippen überprüft und der Button sozusagen in Echtzeit aktiviert bzw. deaktiviert!

Das genaue Design beider Pages ist im vollständigen Projekt zu finden. Wenn wir die App jetzt laufen lassen (und ein passendes Webservice erreichbar ist), können wir Nachrichten zwischen Windows 8 und Windows Phone Geräten austauschen:



Eine zusätzliche Zielplattform?

Die Windows 8 und Windows Phone Apps schauen ja schon mal ganz gut aus, aber einige meiner Kollegen würden gern den Chatverlauf immer im Blick haben während sie mit Desktop-Programmen arbeiten. Eine SimpleChat-Version für den Desktop? Wenn das ursprüngliche Projekt wie in diesem Artikel beschrieben korrekt für die plattformübergreifende Entwicklung strukturiert wurde, ist das in wenigen Minuten erledigt!

Um das auszuprobieren, fügen wir schnell mal ein Projekt vom Typ „WPF Application“ zur Solution hinzu. Dieses muss natürlich eine Referenz auf das PCL-Projekt sowie auf das MVVMbasics NuGet-Package bekommen. Diesmal sollte in den References die MVVMbasicsWPF Biblitothek zusätzlich zum plattformübergreifenden MVVMbasics aufscheinen:


Wir passen die existierende App-Klasse so an, dass sie von BaseApplication erbt, und registrieren alle benötigten Services – am besten im Constructor der App:

public partial class App : BaseApplication
	public App()
		var navigator = new NavigatorService();

Dann erstellen wir zwei neue Fenster im Views Namespace, ändern ihre Definition sodass sie von BaseView statt von Window ableiten, und fügen das [MvvmNavigationTarget] Attribut hinzu:

public partial class LoginWindow : BaseView
	public LoginWindow()

Der Inhalt der beiden Fenster kann jetzt komplett neu designed oder aus dem existierenden Universal App Projekt kopiert und überarbeitet werden – das wichtigste ist: Datenmodelle, Viewmodels und die gesamte Businesslogik können so wie sie sind weiterverwendet werden, so ist die WPF-App im Handumdrehen fertig!



Event Binding

Eine Kleinigkeit möchte ich zum Abschluss noch zeigen: Was, wenn wir in der WPF-App keinen eigenen Button zum Aktualisieren der Nachrichten-Liste integrieren wollen, sondern die Liste bei jedem Berühren mit der Maus neu befüllen wollen?

Klar, um das Herunterladen und Aktualisieren der Nachrichten kümmert sich das Refresh Command, das im ChatViewmodel ja schon vorhanden ist. Um dieses Command aber zu starten, muss erst das MouseEnter-Event der Liste in XAML spezifiziert werden, dann wird ein Eventhandler im C#-Code des Fensters erzeugt, und mit etwas Geduld können wir von dort auf das Viewmodel zugreifen und das Command ausführen – das ganze ist aber mehr als mühsam, entspricht nicht dem MVVM-Pattern, und muss vor allem für jede Plattform individuell nachgezogen werden.

MVVMbasics 2.0 bietet hier erstmals eine bequemere Lösung: Im XAML-Code wird als Eventhandler des MouseEnter-Events einfach die EventToCommand Methode angegeben, die im MVVMbasics Framework definiert ist und für alle Plattformen zur Verfügung steht. Jetzt kann das Command ganz einfach an Event.Binding gebunden werden:

MouseEnter="EventToCommand" mvvm:Event.Command="{Binding RefreshCommand}"

Hinweis: Event.Binding ist im Namespace MVVMbasics.Helpers definiert, dieser muss im Fenster deklariert sein:



Weiterführende Informationen

Übrigens: Zusätzlich zu WinRT und WPF unterstützt MVVMbasics auch die Windows Phone Silverlight Plattform, sodass die SimpleChat App ganz schnell auch für Windows Phone 8.0 angepasst werden könnte – und ich arbeite laufend daran, dass es hoffentlich bald noch mehr Plattformen werden!

Ich hoffe, dieser Artikel hat euch einen kleinen Einblick in die Arbeit mit MVVMbasics gegeben. Das Framework ist kostenlos als NuGet Paket verfügbar und kann in jedes Projekt eingebunden werden:

Viele der nötigen Set-Up Schritte die in diesem Artikel beschrieben sind und sich bei jedem Projekt wiederholen könnt ihr umgehen, indem ihr die MVVMbasics Project Templates verwendet. Diese können unter heruntergeladen werden.

Weiterführende Infos zu den Templates und zum Framework, aber auch Tutorials, Dokumentation etc. gibt’s unter der Adresse

Und falls jemand wissen will wie das eine oder andere Feature gelöst ist (oder MVVMbasics für weitere Plattformen anpassen will): Der gesamte Sourcecode ist frei verfügbar unter


friends header

bloggers headline

links header

Don't contact us via this ( email address.