Schwäbisches Kleinstadtidyll

Auch vor schwäbischen Kleinstädten macht die Aufklärung keinen Halt. Diskussionskultur auf Stein, unbekannter Künstler.

Ich bin...

Manchmal greift moderne Popmusik unfreiwillig Motive auf, die schon sehr sehr alt sind. Ein solches Motiv schnappte sich Gloria Gaynor mit ihrem Lied "I Am What I Am". Das Lied handelt davon, sich die Lebensfreude und Eigenheiten nicht von anderen madig machen zu lassen. Da es mit diesem Inhalt besonders in der LGBT Community freudig aufgegriffen wurde, galt das Lied bald als Schwulenhymne.

Wenn man sich den Titel des Liedes übersetzt, findet man aber noch eine ganz andere Verbindung: "Ich bin, was ich bin". Sagt nicht Gott selbst über sich: "Ich bin, der ich bin" bzw. "Ich werde sein, wer ich sein werde"? Und dann die Ich-Bin-Worte Jesus im Neuen Testament.

Also übersetze ich den Text des Liedes einmal auf Deutsch, und ich lade dazu ein, das Lied aus den Augen Gottes zu betrachten, als würde Gott selbst die Verse singen. Es lohnt sich, versprochen:

Ich bin, was ich bin

Ich bin, was ich bin, ich bin meine ganz eigene Schöpfung.
Also sieh her, gib mir 'nen Laufpass oder Beifall.
Es ist meine Welt, für die ich etwas Stolz empfinden möchte,
meine Welt - und sie ist kein Ort, an dem ich mich verstecken müsste.
Das Leben ist keinen Pfifferling wert,
wenn du nicht sagen kannst: Ich bin, was ich bin.

Ich bin, was ich bin. Ich will kein Lob, ich will kein Mitleid.
Ich hau auf meine Pauke, manche nennen es Krach, aber ich finde es schön.
Was ist also dran, wenn mir jeder Klimbim daran gefällt,
warum nicht einfach mal alles aus einem anderen Blickwinkel betrachten.
Dein Leben ist eine Mogelpackung,
bist du es rufen kannst: Ich bin, was ich bin.

Ich bin, was ich bin, und dafür muss ich mich nicht entschuldigen.
Ich spiele meine Karten, manchmal die Ässer, manchmal die Luschen,
Es ist ein Leben, und es gibt kein Pfand und kein Zurück,
ein Leben, also mach die Käfigtür auf.
Das Leben ist keinen Pfifferling wert,

bist du es rufen kannst: Ich bin, was ich bin.

Sharing posts from within Blogger won't work in Chrome and Chromium?

Deutsch	English
Blogger verfügt seit einiger Zeit über eine bessere Anbindung an Google+, so dass man seine Posts direkt teilen kann. Wenn man einen neuen Post veröffentlicht oder den Teilen-Link eines Posts anklickt, soll Blogger ein Fenster öffnen, in dem man den Post in seinen Kreisen weitergeben kann.	Blogger has recently gotten a tighter integration with Google+, so that you can directly share your posts from within Blogger. When publishing a new post or when clicking the posts share-link, Blogger would open a window that lets you share the post with your circles.
Leider hat das bei mir bisher nicht funktioniert: Das Fenster öffnet sich in Chrome oder Chromium lediglich ganz kurz, schließt sich danach aber gleich wieder.	However, this did not work for me: The window would show up in Chrome and Chromium for a second and then immediately close.
Hier die Lösung des Problems:	The solution is as follows:
Das Problem entsteht, wenn man Cookies von Drittanbietern gesperrt hat. Man muss einfach nur folgende Ausnahmen hinzufügen:	The problem is caused by blocking third-party cookies. Just add the following exceptions to your third-party cookies section:
[*.]google.com [*.]blogger.com [*.]blogspot.com
Voilà, das Fenster zum Teilen der Posts lässt sich nun öffnen!	Well done, the window for sharing your posts will show up now.

Windows Communication Foundation - Monster die Zweite

Es gibt Neuigkeiten von der Front mit WCF und dem Hosten eines Services mit WsHttpBindung und NetTcpBinding im IIS.

Nachdem es mir beim letzten Mal gelungen ist, meinen Service endlich im IIS zu hosten, hatte ich noch Probleme beim Aufruf. So konnte ich problemlos mit dem WsHttpBinding arbeiten, bekam aber beim NetTcpBinding einen Timeout mit folgender Beschreibung:

"The sequence has been terminated by the remote endpoint. Due to a user abort the reliable session cannot continue. The reliable session was faulted."

Diese und ähnliche Fehlermeldungen werden von WCF erzeugt, wenn irgendwas schief geht. Leider erachtet WCF es nicht für nötig, mich darüber zu informieren, was genau das Problem war. Ist IIS falsch konfiguriert? Ist WCF falsch konfiguriert? Stimmt meine web.config oder app.config nicht? Muss eine Betriebssystem-Einstellung angepasst werden? Kann es an der Firewall liegen? Auf alle diese Fragen gibt WCF mir keine Antwort, sondern nur kryptische und völlig uninformative Meldungen.

Also musste ich mal wieder selber alles herausfinden, was - natürlich - erheblich viel Zeit in Anspruch nimmt, aber das kennen wir bei WCF ja schon.

Also prüfte ich zuerst meine Konfiguration. In meiner Not habe ich sogar alle Ratschläge aus dem IIS Blog befolgt (die Anmerkungen zu Application Pools sind erhellend!), jedoch erfolglos.

Nach ratlosem Suchen bemerkte ich eher zufällig: Es gibt eine Methode des Services, die sich via NetTcpBinding erfolgreich aufrufen lässt. Das bedeutet also, dass IIS, Betriebssystem und WCF grundsätzlich richtig eingerichtet sind.

Also analysierte ich genauer die Methoden, die sich nicht aufrufen ließen. Dazu heftete ich meinen Debugger an den Worker Process des IIS an. So konnte ich feststellen, dass die Methoden fehlerfrei ausgeführt wurden, und zwar bis zur return-Anweisung.

Nun muss man wissen, dass die Methoden DataSet-Instanzen liefern. Hat WCF etwa ein Problem bei der Serialisierung und dem Versand von DataSets? Da viele Leute genau sowas schon gemacht haben, lautet die ermunternde Antwort: Nein. Stattdessen fand ich den Ratschlag auf StackOverflow, man solle die Quotas erhöhen.

Die Quotas legen u.a. die Maximalgröße von Arrays, Nachrichtenblöcken und Paketen fest. Wenn diese Größen überschritten werden, kommt es in WCF zu Exceptions. Und diese Fehler heißen dann nicht etwa "Quota XY exceeded", was einem ja einen Hinweis auf die Fehlerursache geben könnte, sondern... hm... z.B.  "This request operation sent to XY did not receive a reply within the configured timeout", was uns natürlich in die total falsche Richtung schickt.

Nachdem ich die Quotas also entsprechend erhöht habe, lassen sich beide Bindings betreiben.

Ich möchte einen Toast aussprechen auf Microsoft und die Kunst, Probleme beim Namen zu nennen.

Windows Communication Foundation - Monster!!!

Ich versuche seit Stunden, einen bestehenden asmx Web Service meines Arbeitgebers gleichzeitig als WCF Service im IIS hosten zu lassen. Dabei will ich zunächst ein WsHttpBinding anbieten, und später ein NetTcpBinding.
Aber dieses Problem entpuppt sich als extrem komplex, was mich verwundert, denn die Aufgabenstellung ist kinderleicht. Mittlerweile kann ich WCF einfach nicht mehr hören. Microsoft prahlt unentwegt damit, wie toll diese Technik sein soll, ich aber sage euch: BULLSHIT! Im 21. Jahrhundert komplizierte XML Konfigurationen von Hand nehmen? Dokumentation - Fehlanzeige? Fehlerdiagnose = Eventlog? Fehlermeldungen, die überhaupt keine Anhaltspunkte liefern, was man falsch macht? Keine grafische Unterstützung durch Visual Studio oder IIS? Echt zum Kotzen das alles, aber leider alternativlos.
Also, hier die Chronik meines Leidens:

1. Der asmx Web Service und seine Methoden müssen mit WCF Attributen versehen werden, wie Kenny Wolf beschreibt - bitte ignoriert aber seine web.config.
2. Nun fügt man dem ASP.NET Projekt mit dem asmx Web Service einen WCF Service hinzu (.svc-Datei). Das kann man mit Visual Studio machen, dann werden schon einige tolle Eintragungen in die web.config getätigt. Die svc-Datei muss man bearbeiten und als neue Code-Behind-Datei die bestehende asmx.cs-Datei eintragen. Die alte Code-Behind-Datei kann man wegwerfen.
3. Nun muss man in der MSDN nachlesen, wie man den Service konfiguriert. Schließlich zwingt WCF uns zum Verfassen von XML Konfigurationsdaten in epischem Ausmaß. Von Hand, versteht sich.
4. Danach geht's immernoch nicht, weil WCF bei mir noch gar nicht im IIS registriert ist. (What the f*ck...) Also ServiceModelReg aufrufen.
5. Danach geht's immernoch nicht, weil IIS noch nicht verkraftet, dass mein WCF Service erstmal nur ein WsHttpBinding mitbringt. Also schnell bei StackOverflow nach der Lösung dafür suchen: Vorübergehend schalte ich Net.Tcp ab. Auf .NET 4 will ich nicht aktualisieren, also muss ich wieder einen Sermon in die XML Konfiguration aufnehmen, etwa so:
       <serviceHostingEnvironment>
         <baseAddressPrefixFilters>
           <add prefix="net.tcp://localhost"/>
         </baseAddressPrefixFilters>
       </serviceHostingEnvironment>
   

Danach kriege ich immerhin den WsHttpBinding-Teil in den IIS und irgendwie laufen die meisten einfachen Sachen sogar.
Ab das Binding für NetTCP habe ich ja noch gar nicht in die web.config geschrieben. Ich ahne, dass hier noch unangenehme Arbeit auf mich wartet. Und vor allem viel handgeschriebener XML Konfigurationscode.
Das Problem: Es ist fast unmöglich, Informationen darüber zu finden, wie das NetTcpBinding im IIS aufgesetzt werden muss.

1. Unbedingt nachvollziehen sollte man die Schritte aus einem Schweizer MSDN Blog.
2. Und nicht vergessen: Den Workaround aus Schritt 5 (oben) wieder entfernen, sonst geht's nämlich wieder nicht und man sucht stundenlang, weil es keine richtige Fehlermeldung gibt.

Danach habe ich mein Ziel erreicht:
Ich habe meinen bestehenden asmx Web Service als WCF Service im IIS mit zwei Endpunkten (WsHttpBinding und NetTcpBinding) veröffentlicht.

Aber an der Stelle hört das Drama leider noch nicht auf. Da mein asmx Web Service rege auf die Session-Variable zugreift (zu meiner großen Freude!), werde ich noch etliche Anpassungen vornehmen müssen, denn in WCF macht man das anders.

Mir stehen also noch spannende Ereignisse bevor...

Tip des Tages: Das Minderheiten-Quartett!

Das Minderheiten-Quartett - jetzt kaufen!

Mit spitzem Humor gegen Engstirnigkeit und Diskriminierung - fabelhaft.