TFS-2010 Umzug auf andere Hardware und Dokumentation, die sich irrt

Mein TFS-2010 muss umziehen. Zum Glück ist auch dieser Vorgang in der MSDN ausgiebig beschrieben: 
Move Team Foundation Server from One Hardware Configuration to Another

In der Anleitung steht unter zwei Warnungen, die mich irritierten und die sich eigentlich beide als falsch bzw. teilweise falsch herausstellten:

1. SharePoint

You can choose to change versions or editions of some software, such as SharePoint Products, but not others. Changing versions or editions might complicate the restoration. For optimal results, consider restoring to exactly the same software and then upgrading after the restoration is completed.

Bei der Installation des TFS-2010 habe ich eine Upgradeinstallation gewählt und dabei wurde auch der SharePoint Portal Server 3.0 mit installiert. Mittlerweile lief dort auch schon SharePoint 3.0 SP2.

OK, denke ich. Also SharePoint 3.0 SP2 herunterladen und installieren. Pustekuchen! Bei der Einrichtung und dem hinzufügen der SharePoint Site in den TFS kam es zu mehreren Fehlern. Es hat immer gesagt, dass dieser Name nicht hinzugefügt werden dürfte.

Nach einigem überlegen schwante mir der Unterschied. Ich hatte damals den TFS-2010 in englisch installiert. Jetzt hatte ich die deutsche SharePoint 3.0 SP2 Installation einfach aus Gewohnheit durchgeführt.
Also zurück-marsch-marsch. Die deutsche Version deinstalliert (zwei Snapshots zurück), die englische drauf und siehe da es geht.

Also Achtung: Nach meiner Erfahrung ist der TFS-2010 sehr eigen, wenn es um die Sprachversion des SharePoint Dienstes geht und so einfach kann man also nicht den Dienst wechseln wie man lustig ist. Zumindest nicht die Sprachversion.

BTW: Was sich hier so schnell liest, war eine Fehlersuche von über 2,5 Stunden…

2. SQL Server

Auch hier lesen wie den folgenden Satz:

You must install the same version that you used in the original installation of Team Foundation Server.

Uff! Das kommt gar nicht in die Tüte. Das alte System war ein 32bit System. Der neue virtuelle Server soll komplett in 64bit laufen, inkl. also meinem SQL Server. Auf dem alten Server lief ein SQL 2008 32bit. Der neue Server und das Image, dass ich bereits erzeugt hatte sollte nun SQL 2008 R2 64bit haben.

In diesem Fall habe ich die Warnung ignoriert.
Das erfreuliche Resultat: Keine Probleme

Bis auf Kleinigkeiten beim Einrichten der Dienste und Fehlermeldungen, auf die einen dieses Umstellungsdokument auch nicht hinweist, aber andere Ursachen haben, gab es gar keine Probleme die neue Version zu verwenden und den Sprung von 32bit auf 64bit zu wagen. Also Mut zum Verstoß gegen diesen Hinweis 😉

PS: Ich habe die Umstellung mit entsprechenden Snapshots auf dem virtuellen Server-System abgesichert und konnte somit meine Fehler und Probleme sehr einfach korrigieren und Lösungen austesten, ohne die Neuinstallation zu gefährden.

Und auf einmal ging der Debugger in VS-2010 nicht mehr…

Ich wollte heute morgen einfach ein kleines Testprogramm debuggen. Der Build wurde normale durchgeführt, aber danach ging nichts mehr. VS meldete nurnoch lapidar:

Microsoft Visual Studio is Busy
Microsoft Visual Studio is waiting for an internal Operation to complete. If you regularly encounter this delay during normal usage. please report this problem to Microsoft.

D.h. Visual Studio meldete nur noch, dass es beschäftigt wäre. Nach ein paar überlangen Sekunden/Minuten hatte sich dann zumindest der Bildschirm aufgebaut, wie ich es vom Debugger her gewohnt war.

Im Debug Ausgabefenster konnte ich nur sehen, dass er die Symbole der EXE geladen hat. Mehr nicht.
Also DEVENV.EXE abgeschossen.
Anders Mini-Projekt mit nur einer Consolen Ausgabe, kompiliert, Debuggen… gleiches Problem.
Neustart.
Gleiches Problem.  😯

💡 Ich starte DEVENV.EXE erneut, gehe auf Tools -> Options -> Debugging und sehe den Übeltäter:

Meine Server ziehen um, und ich habe zentral für alle Entwickler einen Symbol-Cache. Nun und dieser Server ist eben nicht mehr da. Also wurde für jede DLL die der Debugger gesucht hat ein Fileshare bemüht der ins Nirwana zeigte.

Wie so oft: Kleine Ursache – Fatale Wirkung!

Tipps & Tricks: TFS Administration Tool 2.1

Mit der Benutzerverwaltung im TFS kann man viel unnütze Zeit verbringen.
Jeder kennt das Problem der schon mal mehrere Anwender in einem TFS-Projekt verwalten musste. Durch die Dreiteilung der Rechte muss man:

  • Rechte auf dem TFS verwalten (Team Foundation Roles)
  • Rechte auf dem SharePoint Server verwalten (SharePoint Roles)
  • Rechte auf dem SQL Reporting Server verwalten (Reporting Services Roles)

Wenn also was nicht klappt, weil einem zum Beispiel ein Report nicht angezeigt wird, ist man gleich wieder am grübeln: Wo war das nochmal mit den Reporting Services? Welcher Server, welche Webadresse? Gleiches, wenn man ein Benutzer keinen Zugriff auf die Dokumente in der SharePoint Site hat, die zu einem Projekt angelegt wurde.

Ich fühle mich eigentlich eher als Entwickler, denn als Administrator von einem SharePoint Server oder SQL-Reporting Services Server.

Das Ganze wird um ein vielfaches einfacher durch das TFS Administration Tool 2.1.
Hier kann man auch einfache Art in einem Tool alle Rechte auf einmal einsehen und verwalten. Netterweise wird man in der Listenanzeige sofort durch rote Kästchen auf die Konten aufmerksam gemacht, in denen keine Rechte definiert wurden. In den meisten Fällen ist hier auch schon ein grundsätzliches Problem gefunden.

Das Tool lässt sich auf jedem Client installieren auf dem der Team-Explorer auch installiert wurde.

Link: http://tfsadmin.codeplex.com/

BUG: VC-2010 ftell liefert negative Werte wenn eine UTF-8 Datei mit ccs=UNICODE geöffnet wird, die nicht mit fseek funktionieren

In VS-2005 hielt die Unicode und UTF-8 Unterstützung Einzug in die CRT und damit auch in die MFC. Jochen und ich haben dazu gebloggt.

Leider ist die Implementierung nicht fehlerfrei. Wenn man eine UTF-8 Datei mit ccs=UNICODE öffnet dann liefert ftell zum Teil auch negative Werte. Das ftell nicht die exakte Position in der Datei liefert ist dokumentiert, nur sollte es mit dem Wert zumindest möglich sein wieder fseek aufzurufen um an eine alte Dateiposition zurück zu gelangen.
Das ist mit der jetzigen Implementierung nicht möglich.

Ein Sample dazu ist schnell gebaut:

int _tmain()
{
  FILE *file = NULL;
  if (_tfopen_s(&file,_T("Test.txt"),_T("rt") _T(", ccs=UNICODE")))
    return -1;

  TCHAR szBuffer[_MAX_PATH];
  while (_fgetts(szBuffer,_countof(szBuffer),file))
  {
    int iPos = static_cast(ftell(file));
    _tprintf(_T("%d\n"),iPos);
    _ASSERTE(fseek(file,iPos,SEEK_SET)==0);
  }

  fclose(file);
  return 0;
}

Ein entsprechendes Sample kann man hier herunterladen.

Der Fehler betrifft natürlich auch die MFC mit CStdioFile und GetPosition!

Hintergrund:
Ich kam auf den Fehler, weil wir ein Programm benutzen, dass sich bestimmte Dateipositionen merkte um einen Datenimport bei einer bestimmten Bedingung, ab einer definierten Stelle, neu aufnehmen zu können. Bisher hatten wir hier nur pure ASCII Dateien erlaubt, jetzt wollten wir auch UTF-8 Dateien unterstützen.
Sicher man kann auch alles im Speicher zwischenhalten, aber wenn es eine simple Dateiposition ist das Ganze so weitaus Ressourcen schonender.

Soweit ich das übersehen kann, betrifft der Fehler alle VS-Versionen ab VS-2005. Ein entsprechende Bug wurde von mir schon vor längerer Zeit auf Connect geöffnet. Getan hat sich bisher noch nichts:
https://connect.microsoft.com/VisualStudio/feedback/details/591030/ftell-returns-negative-value-for-utf-8-files-opened-with-textmode-and-ccs

Beta Version von VS-2010 SP1 veröffentlicht

Es wurde ja schon einiges geredet über VS-2010 SP1. Jetzt ist die Beta 1 veröffentlicht worden.
Ich kann leider noch nicht sagen, was sich für VC Nutzer ändert. Der Blog Artikel (s.u.) gibt darüber keine Auskunft.

Mehr Infos hier:
http://blogs.msdn.com/b/jasonz/archive/2010/12/07/announcing-visual-studio-2010-service-pack-1-beta.aspx

BUG: VS-2010 vergisst regelmäßig die Tastaturkürzel für Extensions und Addins

 Toll ist, das es für VS-2010 wirklich viele nützliche Extensions gibt. Das heißt aber auch, dass man des öfteren mal ein Update einer solchen Extension installiert. Und jetzt wird es ärgerlich. Jedesmal wenn man ein Update einer Extension installiert dann sind alle Tastaturzuordnungen auf ALLE Extensions und Addins futsch.

Mich hat das so genervt, dass ich einen entsprechenden Bugreport eingereicht habe:
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=621929

Wie man lesen kann: „A known issue!“. Na dann hoffen wir mal auf einen Hotfix… 😉 (also bitte gebt Eure Votes ab), wie immer stirbt die Hoffnung zuletzt..

Ich kann jedem nur raten, die eigenen Einstellungen des Visual-Studios über die Import/Export Funktionen regelmäßig zu sichern. Dann kann man bei Bedarf auch die Tastaturmappings alleine wieder zurückspielen…

TFS-2010 zeigt nicht alle Historien Einträge für Dateien

Ein Kunde meldete ein Problem und ich entdeckte einen Fehler. Ich wollte wissen wann dieser Fehler in die Software kam oder ob er evtl. schon immer vorhanden war. Also bemühte ich die Historie des Team Foundation Servers. Allerdings erschien mir diese nicht komplett.

Vor ca. 2 Jahren habe ich einige Projekte umstrukturiert und dabei auch Verzeichnisse verschoben. Und genau bis zu diesem Punkt konnte ich die Historie einsehen.

Nach ein bisschen Recherche im Netz fand ich diesen Report auf Connect:
https://connect.microsoft.com/VisualStudio/feedback/details/538032/tfs-2010-does-not-display-history-for-a-renamed-folder
Und in dieser Meldung fand ich dann auch den entsprechenden Workarround.

Erst der Befehl:
tf.exe history  „C:\Dev\Root\Projects\the file name I am looking for.cpp“   /itemmode
zeigt die komplette Historie:

Frag mich bitte keiner warum das so sein muss 😉 Slotmode / Itemmode? Brauchen wir das wirklich?

In VS-2010 SP1 wird sich einiges bzgl. des Help-Viewers tun…

Das sich doch relativ viele Entwickler (wie auch ich hier in meinem Blog) negativ über die MSDN-Hilfe Integration in VS-2010 geäußert haben hat scheinbar Spuren hinterlassen, wie in Jeff Brattens Blog zu lesen ist:

http://thirdblogfromthesun.com/2010/10/the-story-of-help-in-visual-studio-2010/
http://thirdblogfromthesun.com/2010/10/the-story-of-help-in-visual-studio-2010-part-2/
http://thirdblogfromthesun.com/2010/10/the-story-of-help-in-visual-studio-2010-part-3/

Besonders Teil 3 mit dem Ausblick auf SP1 ist interssant. Ich zitiere direkt aus Part 3:

New Features in Visual Studio SP1

We’ve made three major changes to the Help Viewer in SP1. First, we’ve abandoned the browser-as-local-help-viewer and implemented a simple client application for offline help. The help window is no longer lost in the set of browser tabs you have open and the help application icon can be easily located in the taskbar. F1 Help re-uses the currently active tab instead of creating a parade of open tabs that must be manually managed. The help application can be sized and placed anywhere on your desktop and retains its size and placement across sessions. The navigation panel width is resizable and it can be placed to the right or the left of the content.

Second, with the flexibility we gain from building a client application, we’ve re-introduced many of the productivity/efficiency features found in Document Explorer. The viewer features four navigation tabs: a fully-expandable table of contents that can be explored without reloading the current topic, a keyword index, a Favorites and History tab, and a search results pane. The search results pane allows you to refine your search queries without losing your current topic context. In addition, context menus and shortcut keys allow you to access features quickly without excessive need for a mouse.

TFS Unshelve mit Merge

Ich und meine Kollegen benutzen gerne Shelvesets um uns Code gegenseitig zuschieben zu können, oder Testcode auszuprobieren.

Problematisch ist allerdings, dass die Dateien alle nicht ausgechecked sein dürfen, die man mit dem Shelveset laden möchte. Doof! Ein Merge ist mit VS-2010 nicht möglich, wenn man ein Shelveset lädt.

Glücklicherweise gibt es aber die Team Foundation Server Powertools. Und in diesem genialen Tool-Paket ist auch netterweise der Befehl: tfpt unshelve verfügbar! Und damit kann man in gewohnterweise, ein Shelveset in die eigenen bereits bearbeiteten Source hinein-mergen.

Erstaunen: CMemDC ist Bestandteil der MFC!

Wer Double Buffering benötigt und die MFC nutzt, der kennt auch CMemDC. Vermutlich eine der meist genutzten und kopierten Klassen, die auf CodeProject und CodeGuru vorgestellt wurden.
http://www.codeproject.com/KB/GDI/flickerfree.aspx
http://www.codeguru.com/cpp/misc/misc/flickerfreedrawing/article.php/c389/Flicker-free-drawing-using-memory-DC.htm

Ich habe meine Erweiterung hier im Blog vorgestellt und die liegt normalerweise in einem separaten Namespace, wie alle meine Tool-Klassen.

Nicht schlecht staunte ich, als ich keinen Compilerfehler bekam obwohl ich CMemDC nutzte aber keinen Namespace angab. Siehe da: CMemDC hat in einer eigenen Implementierung den Weg in die MFC gefunden. Man findet sie in:
C:\Program Files\Microsoft Visual Studio 10.0\VC\atlmfc\include\afxcontrolbarutil.h

Im Großen und Ganzen ist es die bekannte Standard-Implementierung, allerdings verfügt diese CMemDC Version auch Code, der auf Windows Vista und Windows 7, die fest im Betriebssystem verankerten Funktionen nutzt: BeginBufferedPaint, EndBufferedPaint
Siehe http://msdn.microsoft.com/en-us/library/bb773178(VS.85).aspx
Diese Funktionen werden innerhalb des Themeings von Windows Vista und Windows 7 verwendet und in dieser Funktionsgruppe ist auch Alphablending direkt verankert. (BufferedPaintSetAlpha). Ich vermute sogar, dass diese integrierten Klassen effektiver arbeiten, als die eigenen Klassen (ein Test steht noch aus), denn Windows weiß intern natürlich viel besser was wie zu puffern und zu zeichnen ist, als wir, wenn WM_PAINT aufgerufen wird.

Vielleicht ein guter Grund, die eigene CMemDC Klasse auch auf Vista/Windows 7 Funktionen zu erweitern oder die integrierte Klasse in der MFC zu verwenden.

Tipp: Übrigens hat die MFC CMemDC Klasse einen statischen Member, der es auf einfache Weise erlaubt das Double-Buffering abzuschalten (CMemDC:: m_bUseMemoryDC), dass ist besonders interessant beim Debuggen von grafischen Operationen, deren Ergebnisse man auch gleich sehen will, allerdings wird dieser Member nicht benutzt wenn das interne Windows Double-Buffering genutzt werden kann, schade eigentlich.

PS: Aber eigentlich muss man sich auch die Frage stellen, warum die Entwickler genau diesen Klassennamen verwendet haben, denn er provoziert ja auch direkt den Konflikt mit existierendem Code.