Ab sofort gibt es den aktualisierten SQL Server 2008 R2 Express zum konstenlos runterladen.
Eines der wichtigesten neuerung der Express Edition dürfte wohl die erhöhung des Datenabnk-Größe-Limits von 4 GB auf 10 GB sein 
Hier der Link zur SQL 2008 R2 Express Startseite
http://www.microsoft.com/express/Database/
Ich bin schon länger ein Fan von Sharepoint und verwendet dies auch für mehrere interne Projekte.
Seit einigen Tagen ist jetzt auch der Nachfolger der “Sharepoint Services 3.0″ verfügbar (natürlich immer noch kostenlos). Aber natürlich mit einem neuen Namen:
Sharepoint Foundation 2010
Der einzige Nachteil des Nachfolgers ist, dass es nur noch auf einem x64 System installiert werden kann.
Wenn man es auch auf einem Entwicklungsrechner installieren will, so kann man es auf Vista (SP1-x64) oder Win7 (x64) installieren. Produktiv wird dies aber nicht unterstützt.
Hier wird dann schon mehr verlangt:
Mit Server 2008 R2 Service Pack 1 wird es endlich eine Erweiterung des RDP (Remote Desktop Protocols) geben: 3D!
Es ist also zukünftig möglich via RDP die schöne, neue 3D-Welt zu erfahren.
Dies bedeutet natürlich auch, dass ein Arbeiten mit VS2010, welches ja WPF verwendet, vermutlich flüssig über RDP möglich ist!
Also, ich bin mal gespannt und freue mich schon auf dieses Feature, da ich oft RDP verwende!
Edit 2010-03-27:
Hier gibt es auch noch eine ausführlichere Erklärng wie RemoteFX funktioniert:
http://blogs.msdn.com/rds/archive/2010/03/26/microsoft-remotefx-the-problem-we-are-solving.aspx
Wer von Euch kennt das Problem: Der Kunde hat ein Absturz oder einen Hänger Deines Programmes. Das einzige was Du bekommst ist ein Dump-File (z.B. entweder via WER oder durch eigenes schreiben von MiniDumpWriteDump).
Jetzt beginnt für Dich das Problem:
Mit diesem Fragen braucht man sich nicht beschäftigen, wenn man bei seinem Build Prozess noch zusätzlich zwei Dinge einbaut
Source-Indexing sorgt dafür, dass in die Debug-Symole (PDB-Dateien) auch zusätzlich noch ein verweis auf die richtige TFS-Version eingefügt wird. Dadurch kann der Debugger (z.B. VS) man mit der PDB-Datei genau den passenden Source aus dem TFS holen, mit dem die DLL/EXE gebuildet wurde.
Um dies zu machen braucht man zwei Dinge: “Debugging Tools For Windows” und “ActivePerl“). Das Source-Indexing findet sich bei den Debugging Tools im Unterverzeichnis “srcsrv” (also z.B. C:\Program Files\Debugging Tools for Windows\srcsrv). Da die “Skripts” (leider) in Perl geschrieben sind, ist auch noch ActivePerl notwendig. Es reicht aber, wenn man die ZIP-Datei runterlädt und vor dem Aufruf einfach den Pfad auch noch auf das entpackte ActivePerl setzt.
Damit beim Source-Indexing auch der korrekte TFS-Server verwendet wird, muss man in der Datei “srcsrv.ini” die Zeile mit “MYSERVER” auf den richtigen TSF zeigen lassen.
MYSERVER=http://my-tfs-machine:8080
Jetzt muss man nach einen Build nur noch das Source-Indexing aufrufen und angeben, wo denn der Workstore und die PDBs liegen. Ich gebe der Einfachheithalber immer den Root aller Projekte an, welche ich gebuildet habe. Die Natchdatei sieht dann z.B. so aus (es kann auch direkt als eigenes Task in msbuild laufen):
rem Merke mit mal den aktuellen Pfad, was die Root meiner Projekte und Ausgabe ist
set srvOrgDir=%CD%
rem Setze den pfad auch zu dem Perl Zeugs...
path=%path%;"%CD%\Tools\srcsrv\ActivePerl-5.10.1.1006-MSWin32-x86-291086\perl\bin"
rem Wechsle in das Verzeichnis wo die Source-Indexing Tools liegen (liegt bei mir auch im TFS)
cd .\Tools\srcsrv
rem Rufe das Source-Indexing auf
call tfsindex.cmd -ALLROOT="%srvOrgDir%"
rem Setze wieder den ursprünglichen Pfad
cd /D %srvOrgDir%
Alternativ kann man natürlich auch das srcsrv-Verzeichnis im TFS ablegen (so hab ich es gemacht), dann muss man nicht sicherstellen, dass man auf dem Build-Rechner auch die Debugging-Tools installiert hat.
Jetzt sollten nach einem Build alle PDB-Dateien mit der korrekten TFS-Version indiziert worden sein (dies erkennt man daran, dass ziemlich weit hinten in der PDB-Datei Einträge mit “MYSERVER” kommen…; kann man z.B. in Notepad anschauen).
Oben haben wir jetzt die PDB-Dateien mit dem passenden Verweis auf den TFS ausgestattet. Jetzt müssen wir nur noch sicherstellen, dass wir zu einem beliebigen späteren Zeitpunkt nicht mehr nach dieser PDB-Datei (und den dazugehörigen EXEn) suchen müssen. Dies geschieht am einfachsten mit dem “symstore” aus den Debugging Tools for Windows. Dies speichert einfach alle PDBs/EXEn in ein Verzeichnis (am besten ein Netzwerkverzeichnis, wenn es später mehrere Verwenden wollen).
Das ablegen erfolgt dann ganz Simple durch:
.\Tools\SymStore\Symstore.exe add /r /f .\*.* /s G:\MyProject\SymbolStore\Files /t "Project Name"
Das war alles
Ok, fast… denn man will das ganze ja auch noch verwenden… dazu muss man in VS noch ein paar Einstellungen machen, da per default der “Source-Server” deaktiviert ist. Dies muss aktiviert werden:
Jetzt muss man noch den Pfad zu den zuvor abgelegten Dateien eintragen:
Bekommt man jetzt ein Dump oder will in dieser EXE/DLL debuggen, so werden die Sourcen direkt vom TFS geholt (und in einem temporären Verzeichnis gespeichert) und man kann dies dann direkt debuggen.
Ich hoffe, dass hilft dem ein oder anderen.
PS: Beide Verfahren werden übrigens auch intern von Microsoft schon sehr lange eingesetzt (deswegen auch das Source-Indexing in Perl; PowerShell gab es damals noch nicht). Die gesamten Windows Sourcen sind so indiziert und (der wer darf ) können dann via CCP die passenden indizierten PDB-Dateien abgefragt werden, welche dann z.B: in VS/WinDbg die passenden Source runterlädt.
PPS: Wer das ganze noch für SubVersion haben will, kann es bei Stefan nachlesen:
Source Server und Symbol Server Setup mit Subversion
Wer zufällig vom 9.11. bis 13.11. auf der TechEd Europe in Berlin ist, darf gerne mal im Technical Learning Center (TLC) an den Ask-the-Expert (ATE) booths vorbeischauen, wo ihr mich treffen könnt
Wir haben hier für die ListBox ein eigenes Template gemacht, dass eben alle ListBoxen bei uns in der Anwendung gleich aussehen… dabei haben wir einfach das Beispiel aus der MSDN verwendet: ListBoxItem ControlTemplate Example
Eigentlich sollte man ja meinen, dass dies Beispiel zumindest einigermaßen funktioniert… leider weit gefehlt…
Das Problem ist: Sobald wir ein eigenes DataTemplate für spezielle Daten gemacht haben, hat ein Klick auf ein Element nur dann reagiert, wenn entweder genau auf den Rahmen des Items geklickt wurde oder genau auf den Text:
Es ist also relativ schwer z.B. das “!” genau zu treffen…wir haben ewig gesucht, bis wir endlich den Grund gefunden haben… (dank Franks Unterstützung haben wir es mittels Snoop und der Event-Ansicht gefunden): Der Border in dem ControlTemplate hat keine Hintergundfarbe. Somit ist der Border “durchsichtig” (bzw. “x:Null”), was dazu führt, dass ein Klick auf den Border nicht vom Border verarbeitet wird, sondern vom darunterliegenden Scroll-Container… und der macht natürlich hier nichts damit…
Hier ist auch ein Beispielprojekt (VS2008), damit man es mal selber probieren kann.
Für uns jetzt mal die Lösung: Wir setzen einfach die Hintergrundfarbe des Borders des ControlTemplates auf “Transparent”, dann wirken sich jetzt überall die Klicks auf die ListBox aus… danke an Hendrik für diesen Hinweis!