MSBuild.EXE ist im Extended .Net Framework 4.0 enthalten

Um bestimmte Build-Skripte auf einem Rechner laufen zu lassen, die auf MSBUILD.EXE der Version 4 beruhen, wird das Extended .Net Framework 4.0 benötigt. Es reicht nicht die Client Version.

http://www.microsoft.com/downloads/de-de/details.aspx?familyid=0a391abd-25c1-4fc0-919f-b21f31ab88b7&displaylang=de

oder für Core Server:

http://www.microsoft.com/downloads/de-de/details.aspx?familyid=c2794455-274d-4363-ade6-e69008a24d8a&displaylang=de

Top Einführung in PNRP per NETSH

Was man mit den Clouds von PNRP bei IPv6 alles anstellen, zeigt sehr einfach dieser Screencast: http://channel9.msdn.com/Blogs/SlickThought/Peer-to-Peer-Series-Part-1-Intro-to-PNRP

Daneben wird auch die komplette Programmierung über das .Net-Framework gezeigt:
http://channel9.msdn.com/Blogs/SlickThought/Peer-to-Peer-Series-Part-2-Registering-Names-with-PNRP-API

COPY CON unter Powershell

Leider funktioniert COPY CON unter Powershell nicht, da CON nicht mehr als Eingabekonsole erkannt wird. Es gibt nun aufwendige Geschichten, wie z. B. http://www.nivot.org/nivot2/post/2008/04/02/HowToCopyConTexttxt
InPowerShellUpdated.aspx.

Aber wenn man mal auf die schnelle auf einem anderen Rechner ein paar Befehle speichern muss, dann hilft folgendes:

[System.Console]::in.ReadToEnd() > meineDatei.ps1

Am Ende wird wie gewohnt mit F6 oder STRG+Z abgeschlossen.

Etwas spannender, vor allem kürzer ist die Variante:

PS C:\temp> ‚
>>Mein Text
>>‘ > test.txt
>>

Entscheidend ist das einfache obere Anführungszeichen, danach kann man beliebig viele Zeilen schreiben. Abgeschlossen wird wieder mit oberem Anführungszeichen. Gespeichert wird dann durch das Weiterleiten mit > an die Datei test.txt. Am Ende um >> los zu werden, muss noch einmal Return eingegeben werden.

In beiden Varianten stehen mit den Pfeiltasten die Eingabehistorie ganz normal zu Verfügung.

Datei Hashes wie CRC-32, MD5, SHA1 oder SHA256 unter Windows erstellen

Dieses Tool erstellt erstellt Datei Hashes für beliebige Dateien unter Windows und da es in C# geschrieben wurde, steht es auch auf anderen Plattformen wie Mono zur Verfügung: http://blogs.msdn.com/b/delay/archive/2010/12/06/hash-for-the-holidays-managed-implementation-of-crc32-and-md5-algorithms-updated-new-release-of-computefilehashes-for-silverlight-wpf-and-the-command-line.aspx

WPF Anwendung kann aus 16bit Umgebung heraus nicht gestartet werden

Wenn man per eine 16bit Umgebung ausführt bzw. command.com direkt ausführt und dann aus dieser Umgebung heraus versucht eine WPF Anwendung zu starten, der bekommt einen AppCrash serviert.

Die Lösung des Problems in der 16bit Umgebung

set windir=C:\Windows

zu setzen, danach konnte die WPF Anwendung gestartet werden. Hintergrund dürfte die Suche nach den im System verfügbaren Zeichensätzen gewesen sein. Da windir nicht bekannt war, wurde c:\windows\fonts nicht gefunden.

Wenn man windir nicht per Commandline direkt setzen kann, dann muss die Zuordnung innerhalb der AUTOEXEC.NT erfolgen!

Debugging von .Net Framework Anwendungen wie WPF und WinForms und sogar Silverlight

Immer mehr Programme verwenden das .Net Framework in seinen verschiedenen Ausprägungen. Was aber tun wenn ein Programm nicht funktioniert und sich nur mit einem Fehlerreport an MS verabschiedet?

Man kann mit dem Debugger WinDBG auf das betreffende Programm losgehen.

Eine kleine Einführung mit Beispiel wird hier beschrieben: http://blog.codemurai.de/2009/09/04/WinDbgTutorialFehlerursachenFin
denTeil1EinerSerie.aspx. Das Beispiel geht aber von einer laufenden Anwendung aus, auf die man sich aufschalten möchte.

Oftmals hat man jedoch den Fall, dass man eine Anwendung startet und es kommt gleich die entsprechende Crashmeldung. Bei dieser Situation startet man zuerst WinDBG und ruft dann das zu startende Programm über File->Open Executable auf. In diesem Fall bekommt man bei Aufruf von

.loadby sos mscorwks

allerdings die Meldung “unable to find module” angezeigt.

Das laden des Moduls kann man mit dem Befehl

sxe ld:mscorlib
g
.loadby sos mscorwks

erzwingen.

Danach funktioniert das Debuggen wie unter obigem Blogeintrag beschrieben.

Hinweis: Diejenigen mit langsamer Internetverbindung müssen sich aber beim ersten Aufruf der Funktionen in WinDBG gedulden, da zuerst die nötigen Symboldateien heruntergeladen werden müssen.

Weitere nützliche WinDBG Befehle für SOS findet man hier:
http://geekswithblogs.net/.netonmymind/archive/2006/03/14/72262.aspx

sowie in der offiziellen Referenz unter: http://msdn.microsoft.com/de-de/library/bb190764.aspx

Man kann sogar Silverlight Anwendungen damit debuggen: http://debuggingblog.com/wp/2009/06/02/silverlight-with-better-production-debugging-support-sosdll-in-coreclr-better-than-mscorwks/

Silverlight Plugin Problem unter 64Bit Windows

In einer bestimmten Konstellation kann es vorkommen, dass man unter einem Windows x64 System Probleme bekommt, das eine Silverlight-Anwendung nicht gestartet werden kann.

Hintergrund ist zum aktuellen Zeitpunkt die fehlende 64Bit Unterstützung von Silverlight. Wenn es Probleme mit Silverlight gibt, sollte man explizit schauen, dass man von einem 32bit Prozess aus unterwegs ist.

Mike Taulty beschreibt dieses Problem aber auch noch weitere in Verbindung mit .Net Plattform Programmen, die auf das Zielsystem angepasst werden:
http://mtaulty.com/CommunityServer/blogs/mike_taultys_blog/archive/
2009/02/04/64-bit-wpf-webbrowser.aspx
http://mtaulty.com/CommunityServer/blogs/mike_taultys_blog/archive/
2008/10/01/10807.aspx

.NET Framework Programme über Netzlaufwerke aufrufen wird mit NET 3.5SP1 einfacher

Wenn man ein .NET Framework Programm seither über ein Netzlaufwerk von einem Server gestartet hat, so kam es immer zu einer Sicherheitsverletzung und das Programm wurde abgebrochen. Man konnte sich zwar mit CASPOL.EXE helfen aber das war lästig. Wie man dies seither machte, ist im Artikel https://newyear2006.wordpress.com/2006/09/02/net-programme-uber-netzlaufwerke-aufrufen-caspolexe/ beschrieben.

Microsoft hat mittlerweile die Zügel etwas gelockert und vertraut nun auch .NET Programmen die von einem Netzlaufwerk kommen in bestimmtem Umfang. Dazu wird allerdings das .NET Framework 3.5 mit Service Pack 1 benötigt. http://www.microsoft.com/downloads/details.aspx?FamilyID=ab99342f-5d1a-413d-8319-81da479ab0d7&displaylang=en

Weitere Details beschreibt der Artikel: http://blogs.msdn.com/shawnfa/archive/2008/05/12/fulltrust-on-the-localintranet.aspx

Windows 7 bekommt GPS Unterstützung

Im Windows 7 Developer Guide ist die Rede von direkter GPS Unterstützung im Betriebssystem.
http://code.msdn.microsoft.com/Win7DeveloperGuide

Was bei aktuellen Windows Mobile Geräten mittlerweile zur Standardausstattung gehört, findet nun endlich auch bei den größeren Geräten Einzug. Stellt sich nur noch die Frage wie lange die Hardwarehersteller brauchen um darauf zu reagieren.

Damit ist die Wettervorhersage vor Ort, egal wo man sich gerade mit seinem Notebook befindet, gesichert. Oder wenn man in Zukunft sein Notebook vermissen sollte, kann man es einfach orten solange es noch Strom bekommt 😉

Realisiert wird das ganze durch die Windows Location API. Würde mich nicht wundern, wenn diese API in Windows Vista mit Service Pack 2 auch Einzug halten sollte, überfällig ist sie schon lang.

Jetzt bräuchte man nur noch eine direkte managed Unterstützung im kommenden .NET Framework 4.0 um Koordinatenumrechnungen und Wegberechnungen durchführen zu können, dann würde es sicherlich noch mehr Anwendungen mit GPS Unterstützung geben.

Die Implementierung eines GPS Gadgets das unter Windows 7 die aktuelle Position mittels Virtual Earth anzeigt, findet sich hier: http://download.microsoft.com/download/a/d/f/adf1347d-08dc-41a4-9084-623b1194d4b2/PCHOL13.docx.

Vergleich von XPS und PDF

Einen schönen Vergleich von den Möglichkeiten von XPS und PDF im direkten Vergleich sowie viele Details zum XPS Format selber und den Möglichkeiten findet man unter:
http://www.globalgraphics.com/xps/faq.pdf