Wer unter Windows 7 versucht einen Apache Webserver zu betreiben, kann mit dem Problem konfrontiert werden, dass der Port 80 bereits belegt ist. So erging es auch mir. Das Problem war auch schnell lokalisiert, ein Dienst namens http (wer hätte das gedacht ) belegt den Port. Aber wo kommt dieser her?
Nach einigem Suchen fand ich eine Abhängigkeit zum Druckerspooler von Windows. Die erste Lösung, diesen zu deaktivieren funktionierte zwar, andererseits konnte ich auch nicht mehr drucken.

Sinnvoller ist es die Abhängigkeit des Spoolers von http zu löschen. Dazu in der Registry HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Spooler aufrufen und den Schüssel DependOnService bearbeiten. Dieser sollte die Werte RPCSS und http enthalten. Den zweiten Eintrag löschen und den Rechner neustarten. Fertig.



Es gibt auch noch andere Gründe warum Port 80 belegt sein kann, ein weiterer Webserver (IIS zum Beispiel), Skype oder auch ein blockierende Firewall. Obiges ist also keine allgemeingültige Lösung.

"Internet auf dem Handy? Viel zu teuer!"

Hm, viel zu teuer im Vergleich zu was? Für mein mobiles Datenpaket (250 MB) zahle ich knapp zehn Euro. Das wären dann 4 Cent pro Megabyte. In eine SMS passen 160 Zeichen, was bei einem Byte pro Zeichen[1] also 160 Byte ergeben würde. Damit bräuchte man 6250 SMS um ein Megabyte zu versenden. Nehmen wir den günstigen Preis von 5 Cent pro SMS an, kostet der Transfer von einem Megabyte also stolze 312,5 EUR.





[1] in Wirklichkeit sind es sogar nur 7 Bit

Gelegentlich weise ich hier auf andere Weblogs hin, die ich selber lese und besonders weiterempfehlen kann. Und so auch heute, diesmal das Blog von http.net. Keine Sorge, was sich auf dem ersten Moment nur nach einer weiteren drögen Technik-zentrierten Webseite anhört, ist in Wirklichkeit lebendig und auch für Nicht-Freaks lesbar. Neben den Seltsamkeiten aus dem Provideralltag gibt es auch ungewöhnliche Begebenheit mit Kunden oder Mitarbeitern.

Für Leser die meine Beiträge hier abonniert haben gibt es noch einen besonderen Grund dort hineinzuschauen: ich schreibe nämlich auch gelegentliche Beiträge. Wer also noch ein bisschen mehr aus meinem Berufsalltag erfahren möchte, ist dort garantiert richtig. Ein RSS-Feed um auf dem aktuellen Stand zu bleiben, ist natürlich auch vorhanden.

(english version below)

Gestern Abend verzweifelte Fehlersuche: Beim Benutzen von NUnit stellte ich ein seltsames Verhalten fest. Die einzelnen Tests liefen problemlos durch, jedoch war ein vernünftiges Debuggen nicht mehr möglich. Visual Studio behauptete, dass keine Debuggersymbole geladen seien [1] und so wurden keine Breakpoints mehr angesprungen.
Völliger Blödsinn natürlich, ich war mir ganz sicher dass ich die richtigen Einstellungen getroffen hatte.

Nach einer Stunde herumsuchen war dann klar: Alle Optionen sind so wie sie sein sollen. Nun war gute Rat teuer. Bis mir einfiel, welche Änderung es seit dem letzten Testlauf gegeben hatte: Das Frameworkversion war von 3.5 auf 4.0 verändert worden. Schnell mal probeweise wieder die ältere Version eingestellt und siehe da: es geht.
Das Problem findet sich dann bei NUnit selbst. Die Binaries wurden mit .NET 2.0 erstellt. Kann man auch problemlos mit eigenen Projekten verwenden die 3.0 oder 3.5 nutzen, ab 4.0 geht es aber nicht.

Glücklicherweise ist NUnit aber OpenSource, also flugs den Sourcecode besorgt und mit .NET 4.0 Unterstützung neu gebaut. Naja, so schnell ging es dann nicht [2], aber nach getaner Arbeit funktionierte alles wieder so wie es sollte.

Wer das gleiche Problem hat, sich aber das Neukompilieren ersparen will, kann die erzeugten Binaries auf http://blog.http.net/allgemein/probleme-mit-nunit-und-net-4-0/ herunterladen.


Short english version: Problems with NUnit and .NET 4.0
If you use NUnit with a .NET 4.0 project, you have to recompile NUnit with the same framwork. Otherwise breakpoints are not working [1].
You can download a .NET 4.0 - NUnit version at http://blog.http.net/allgemein/probleme-mit-nunit-und-net-4-0/


[1] The breakpoint will not currently be hit. No symbols have been loaded for this document.

[2] Anscheinend fehlen mehrere Dateien in dem Source-Archiv, daher musste ich erst einmal eine Weile Abhängigkeiten prüfen bis die Kompilierung erfolgreich war.

... zwischen Programmieren und Debuggen, für Laien leicht erklärt:

Beim Programmieren macht man Fehler rein,
beim Debuggen wieder raus.