TFS-2008: Your search cannot be completed because this site is not assigned to an indexer…

SharePoint und TFS sind ja was feines. Man kann ja mal ganz schnell seine Projekt-Doku durchsuchen. Aber 😮 was ist das

Your search cannot be completed because this site is not assigned to an indexer. Contact your administrator for more information.

Ok Kein Problem. Wahrscheinlich ist einfach der Suchdienst dieser Site nicht zugeordnet.

Also SharePoint 3.0 Central Administration öffnen -> Central Administration -> Application Management -> Content Databases  -> Datenbank auswählen -> und dort nun unter Select Windows SharePoint Services search server den Server mit dem Suchdienst auswählen. Aber 😮

Die ComboBox ist leer. Es gibt keinen Suchdienst.

Also nachsehen bei SharePoint 3.0 Central Administration öffnen -> Operations -> Services on Server 😮 Kann gar nicht sein!

Kein Such-Service installiert! Hier hätte ein für Windows SharePoint Services Search stehen müssen.

Bei der TFS Installation hatte ich einfach die Sharepoint Services 3.0 mit installieren lassen. Und bisher klappt auch alles prima. Also was machen?
Versuchen wir es mit einer Reparaturinstallation der Sharepoint Services 3.0. 😮 Fehler bei der Installation:

Microsoft Windows SharePoint Services 3.0 1033 Lang Pack — Error 1706. An installation package for the product Microsoft Windows SharePoint Services 3.0 1033 Lang Pack cannot be found. Try the installation again using a valid copy of the installation package ‚wssmui.msi‘.

OK! Dann noch Deutsches Sprachpaket heruntergeladen für die Sharepoint Services 3.0 -> Installieren -> Reparatur Installation für Sharepoint Services 3.0 durchführen.

Nun das ganze noch mal: SharePoint 3.0 Central Administration öffnen -> Operations -> Services on Server. Hurra!!!
Nun die Windows SharePoint Services Search starten.
Achtung: Wichtig ist, dass man einen Account als Reader angibt, der wirklich nur Read-Zugriff hat ❗

Starten und yeah… es geht… :mrgreen:

TFS-Reports und die Date/Time Picker mit den regionalen Einstellungen für Deutschland…

Wer Reports aus dem TFS in Visual Studio benutzt kann oft genug nicht die Date/Time Picker verwenden, wenn er die deutschen  regionalen Einstellungen verwendet.

Wenn man einen dieser Date/Time Picker benutzt wird das Datum im englischen Format in das Eingabefeld übernommen, was dann anschließend mit der Meldung

Der Wert, der für den ParamEndDate-Berichtsparameter angegeben ist, ist für dessen Typ ungültig. (rsReportParameterTypeMismatch)

quittiert wird.

Das ganze ist kein Problem des TFS sondern des MS-SQL 2005 Reportservers.
Es gibt für den MS-SQL 2005 SP2 einen nicht offiziellen Hotfix, der dies behebt:
http://support.microsoft.com/kb/949095/en-us

Leider muss man um ihn zu erhalten den Microsoft Support kontaktieren. Einfach dort den Hotfix anfordern. Mir ist nicht klar warum man diesen Hotfix nicht direkt herunterladen kann.

Weitere Infos auch hier:
https://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=271928

The project file ‚….vcproj‘ has been moved, renamed or is not on your computer. + Projects have recently been added to this solution. Do you want to get them from source control?

Bei der Umstellung meiner Projekte und Solutions von Visual Source Safe in den  TFS habe ich auch einige Projekte und Solutions umgruppiert.

Als ich dann ein bestehendes Projekt das bereits im TFS lag in eine bestehende Solution einfügen wollte, bekam ich in meinem Visual Studio 2005 die folgenden beiden Meldungen:

The project file ‚….vcproj‘ has been moved, renamed or is not on your computer.

Projects have recently been added to this solution. Do you want to get them from source control?

Und ich habe einige Zeit herumprobieren müssen um heraus zu bekommen was hier passierte. Erst habe ich versucht das Projekt heraus zu nehmen und wiedereinzufügen. Kein Erfolg. Neue Solution genommen, wieder das selbe.
Einiges Suchen im Netz brachte dann Hinweise auf die .suo Datei, die offensichtlich an dieser ganzen Geschichte schuld ist.

In dieser Datei werden lokal (nicht im Source Control) einige Einstellungen des Users für diese Solution gespeichert. Und diese war offensichtlich irgendwie mit falschen Informationen gefüttert bzgl. des Source Control Systems oder kam mit den alten Informationen nicht klar.

Die Lösung:

  • Projekt hinzufügen und es erscheinen die oben genannten Fehler 
  • Beide Fehler einfach ignorieren
  • Geänderte Solution Speichern mit dem hinzugefügten Projekt Speichern
  • Sulution schließen, oder besser gleich Visual Studio ganz beenden
  • Jetzt die <Solution>. suo Datei löschen
  • Dann Solution neu laden.

und alles ist gut…

VS Tipps & Tricks: Ganze Solutions zu einer Master-Solutions zusammenfügen

Wie andere Programmierer auch habe ich meine Projekte in einzelne Solutions zusammengefasst. Nicht wenige dieser Solutions haben auch komplexere Abhängigkeiten.

Bisher hatte ich insgesamt dann 4 größere Solutions, die alle Projekte dann für einen vollen Release-Build bündelten. Bisher wurden diese großen Solution-Builds, dann durch spezielle Batchfiles gesteuert. 

Seit ich den TFS (Team Foundation Server) verwende habe ich begonnen alle einzelnen Komponenten direkt auch auf das Buildsystem des TFS hin abzubilden. Dazu gehört auch, alle Projekte in einer großen Solution zusammenzufassen, um nun im Teambuild alles weitere ablaufen zu lassen.

Als ich mühsam Projekt für Projekt in eine große Master-Solution einfügen wollte machte ich eine nette Entdeckung:
Man kann nicht nur existierende Projekte in eine Solution einfügen. Nein! Es ist sogar möglich eine ganze Solution in eine bestehende Solution einzufügen und dabei sogar alle Abhängigkeiten in dieser Solution zu erhalten. Einfach im Dateidialog die Solutions auswählen und das war es auch schon.
Das macht es wirklich einfach auch komplexere Solutions in eine Master-Solution zusammenzufügen. Jetzt ist es auch nicht weiter schwer die verbleibenden Abhängigkeiten, die bei mir in dem Batch geregelt wurden zu definieren.

Langsame Ausführung von TF Befehlen auf der Befehlszeile

Ich verwende einige TFS Befehlszeilen Kommandos in Batchdateien unter anderem TF CHECKOUT und andere. Leider hatten die Befehle eine immens lange Ausführungszeit. Bis zu 20 Sekunden war keine Seltenheit. Wenn es schnell ging waren es 2-3 Sekunden. Mancher Batch lief bis zu 5 Minuten…

Eigentümlich, denn der TFS-Server liegt in meinem Netz, mein Rechner hat genug Power und der TFS-Server auch. Ein vergleichbarer Befehl aus der IDE dauert nur Sekundenbruchteile.

Das kann es ja nicht sein. Also gehen wir auf die Fehlersuche…
Gefunden habe ich die Lösung dann nach einigem Suchen in diesem diesem genialen Artikel von Buch Hodges

Check LAN connection settings (applies now and for RTM)

First, check your LAN connection settings in Internet Explorer (Tools -> Internet Options -> Connections -> LAN Settings).  Often, the best settings are either to have no boxes checked or to have both of the bottom two checkboxes checked, „Use a proxy server“ and „Bypass proxy server for local addresses.“  The reason is that the .NET 2.0 framework network code gets its settings from the settings in IE.  Prior to the December CTP, there was no way to override this.

How much difference does it make?  It makes a 1 – 2 second difference per tf.exe execution on our network.  Of course, these settings may not work on your network, either for tf.exe or IE, depending upon your network configuration; you’ll need to test it.

Beginning with the December CTP, there is an optional registry setting that you can use to tell the Team Foundation client to bypass the proxy server without changing your IE settings.  In HKCU (per user) or HKLM (global), you can create the registry entry Software\Microsoft\VisualStudio\8.0\TeamFoundation\RequestSettings\BypassProxyOnLocal of type string with the value „true“ to get the improved performance.

Also einfach in den Internet Explorer Optionen auf Internet Optionen -> Verbindungen -> LAN-Einstellungen gehen. Dort nun die beiden ersten Haken aus Automatische Suche der Einstellungen und Automatisches Konfigurationsskript verwenden herausnehmen.

Bei mir dauert nun ein entsprechender TF Befehl nur noch Sekundenbruchteile!

PS: Ich verwenden einen TFS-2008 mit VS-2005 auf den Clients. Also ist der Artikel für mich passend. Der Registry Eintrag der in dem Artikel erwähnt ist muss bei einem VS-2008 natürlich im Ast 9.0 gemacht werden.

External Tools in VS-2005 IDE begrenzt die Argumente auf 251 Zeichen

Wenn man sich ein eigenes Tool baut, dann kann man Überraschungen erleben, wenn nicht das passiert was man möchte.

Auffällig ist schon, dass der Eingabebereich nicht sonderlich lange Befehlszeilen zulässt. Bei 251 Zeichen ist Schluss. Aber wirkliche Überraschungen erlebt man, wenn man Environment-Variablen oder die schönen vordefinierten Makros für den aktuellen Projektpfad verwendet. Wird hier eine etwas komplexere wirklich lange Befehlszeile aufgebaut, dann ist das Ergebnis oft genug zufällig.

Das Problem ist, dass alle Argumente der Befehlszeile auch nach dem Expandieren der Makros eine Länge von 251 Zeichen nicht überschreiten. Der Rest wird einfach abgeschnitten!

So werden z.B. Dateien kopiert, aber nichtdahin wo man sie hin haben wollte.

Good News: Diesen Bug hat man in VS-2008 gefixt. Die Eingabezeile für Argumente ist zwar immer noch begrenzt, aber Makros werden jetzt korrekt expandiert und die entsprechende Befehlszeile darf jetzt länger werden.

Intellisense Hotfix für VS-2005 ist verfügbar

Soeben wurde ein Hotfix veröffentlicht der einige Performance Probleme mit dem Intellisense in Visual-Studio 2005 beheben soll.

Infos über diesen Hotfix gibt es im Visual C++ Team Blog.
Weitere Infos und die Liste der betroffenen Dateien findet man auch in in diesem KB-Artikel 943969

Hier der aktuelle Download Link für die englische Version.
Ob andere Sprachversionen (Deutsch) verfügbar sein werden wurde bereits bei der Produktgruppe intern nachgefragt.

Wichtig ❗ SP1 für VS-2005 muss installiert sein für diesen Hotfix.

Anmerkung: Nutzer von VisualAssist von http://www.wholetomato.com  bemerken von diesen Problemen kaum etwas.

VS-Tipps & Tricks: Schnelle Navigation über Strg+Tab

Wenn man mit dem, aus anderen MDI-Applikationen bekannten, Tasten Strg+Tab in andere Dokumente wechselt, dann wird auch ein Navigationsfenster angezeigt. Am Anfang wunderte mich, was das für ein Geflackere war, wenn ich wie gewohnt Strg+Tab und Umschalt+Strg+Tab verwendete. Bis ich entdeckte, dass man das geöffnete Navigationsfenster noch weitaus besser nutzen kann als nur als Navigationshilfe, wo man mit dem nächsten Strg+Tab landet.

Sofort nach Drücken der Tasten Strg+Tab, kann man bei gedrückter Strg-Taste in dem Navigationsfenster über die Cursor-Tasten jede beliebige offene Datei auswählen, ohne x-mal Strg+Tab zu drücken. Besonders nett ist, dass man auch die Pfeil-Rechts und Pfeil-Links Tasten nutzen kann.

Besonders interessant ist hier, dass man auch die Toolfenster, wie z.B. den Solution-Explorer, den Ressource-View, oder im Debugger den Call-Stack sofort erreichen kann (auch wenn es dazu direkte Hotkeys gibt).

VS-Tipps & Tricks: Tastatureinstellungen einfach auf einen anderen Rechner übernehmen

Unter dem Tools Menüpunkt verbirgt sich eine der schönsten Funktionen der Visual-Studio IDE: Import and Export Settings…

Wenn hat es nicht schon geärgert, wenn man kurze Zeit an einem anderen Rechner sitzt (ja man hat nicht immer Roaming Profiles) und man vermisst die so geliebten individuell eingestellten Shortcuts. Früher hieß dass irgendeinen mysteriösen Registry Ast zu sichern und zu importieren. Heute?

Kein Problem! Auf meinem USB-Stick befindet sich eine Datei Keyboard.vssettings. Mit dieser netten Datei stelle ich sofort meine Einstellungen wieder her. Wie?

Zuerst einmal ertsellen wir diese nette XML-Datei:

  • Dazu wählen wir Tools -> Import and Export Settings…
  • Wir wählen Export selected environment settings
  • Dann wählen wir alles ab indem wir in die Checkbox von All Settings klicken.
  • Jetzt wird in dem Baum unter All Settings -> Options -> Environment -> Keyboard die Checkbox angeklickt.
  • Die Datei speichert man unter einem sinnvollen Namen in C:\Dokumente und Einstellungen\UserName\Eigene Dateien\Visual Studio 2005\Settings

Für den Import geht man so vor:

  • Die Datei kopiert man am einfachsten in den Ordner C:\Dokumente und Einstellungen\UserName\Eigene Dateien\Visual Studio 2005\Settings auf der entsprechenden Maschine. (kann man sich auch sparen und die Datei auf dem Stick lassen)
  • Dann wählen wir Tools -> Import and Export Settings…
  • Wir wählen Import selected environment settings
  • Speichern der aktuellen Einstellungen wenn man will
  • Jetzt sieht man schon die Datei, wenn man Sie in den Ordner kopiert hat, oder man selektiert sie nun direkt vom USB-Stick.
  • Auswählen, was man importieren will. Hier sind natürlich nur die Keyboard settings zu sehen und schon selektiert.
  • Finish und wir haben unsere Einstellungen. Super!

BTW: Dieser Weg eignet sich auch ideal um festzustellen, was man eigentlich umdefiniert hat. Die XML-Datei enthält nur die Änderungen zum angewählten Profil. Damit kann man auch mal wieder auf die Suche gehen, was eigentlich von einem selbst stammt, oder eben Standard ist…

MFC 8.0 PDB Dateien mit und ohne Source Informationen

Gestern hat es mich überrascht, dass ich beim debuggen auf einmal nicht mehr in eine MFC Funktion mit der F11 Taste steppen konnte. Er sprang immer über diese Zeile. Selbst über die Assembler Ansicht war es nicht möglich die entsprechenden Source-Dateien der MFC im Debugger durch zu steppen.

❓ Eigentümlich. Ein kurzer Blick in die Debug Ausgabe und in die Liste der geladenen Module zeigte, dass die PDB Datei der MFC80UD.DLL aus meinem Symbol-Cache geladen wurden.
In der Modulliste stand als Info: Symbols loaded (source information stripped).
Ich verwende einen zentralen Symbol Cache auf unserem Entwicklungsserver und habe natürlich auch als http://msdl.microsoft.com/download/symbols als Quelle für unbekannte Symbole angegeben.

Scheinbar ist auf irgend einem Weg vom Symbolserver aus dem Netz eine Version in meinen Cache hineingelangt, die nicht alle Debug Informationen enthält. Also gerade die Informationen, die es mir erlauben durch den Sourcecode der MFC zu steppen.

Die entsprechende Version mit den Source Informationen befindet sich durch die Installation von Visual Studio im Verzeichnis C:\Windows\Symbols\dll. Auch in den Optionen für mein Visual Studio war zusätzlich natürlich korrekt auch C:\Windows\Symbols\dll als Pfad angegeben. Die dortigen PDB Dateien wurden jedoch offensichtlich ignoriert. Ein manuelles Nachladen aus diesem Verzeichnis half allerdings sofort.
Bei der nächsten Debug Session wurden jedoch wieder die Informationen aus dem Cache geladen.

Also was machen?

❗ Ich habe einfach die entsprechenden Symbol aus dem C:\Windows\Symbols\dll Verzeichnis in meinen Symbol Cache geladen. Das geht einfach mit dem entsprechenden symstore Befehl:

symstore add /r /f C:\Windows\Symbols\dll\*.* /s <My symbol store>

Und siehe da. Nun werden immer die richtigen PDB-Dateien geladen und Step-Into Befehl F11 verhält sich beim debuggen wieder wie gewohnt.