Schlagwort: VSS

Visual Studio 2010 News

Erstmal die wichtigsten News vorab:

  • Die Beta 2 ist ab heute den 19.10.2009 auf MSDN verfügbar.
  • Für alle die, die kein MSDN haben wird es die Beta 2 vorraussichtlich ab Donnerstag den 22.10.2009 frei für alle verfügbar geben.
  • Das Erscheinungsdatum des Visual Studio 2010 wird voraussichtlich der 22. 03.2010 sein ❗

Die Zusammenstellung der Visual Studio Produkte wird sich komplett ändern. Insbesondere was den Team Foundation Server (TFS) und das Team System selbst bettrifft. Es wird nur noch drei Produkte geben (Professional, Premium, Ultimate) und nicht wie bisher 7 (Standard, Professional, Team System Developer, Test, Database, Architecture  und  Team-Suite) ❗
Das bisherige System mit den unterschiedlichen Rollen in Verbindung mit dem TFS kam nicht an und war unverständlich. Die drei neuen Versionen schließen immer die Leistung aller vorhergehenden Pakete ein. Im Detail sieht das bei den neuen Visual Studio Paketen in etwas so aus:

  • Professional: Alles was man bisher eben auch von der Professional Version kennt plus einige Extras, wie Multi-Monitor Support, Managed Extensibility etc.
  • Premium: Alles was Professional hat, inkl. das was wir bisher so in der Team System Developer, Database und der Tester Version kannte.
  • Ultimate: Alles was Professional und Premium umfasst plus die Team System Architecture Funktionen. Kommt also in etwa auf das hinaus was bisher die Team Suite war.

Auffällig! Es ist keine Visual Studio Standard Version geplant. Visual Studio Standard stirbt.
Aber auch hier soll was preiswertes kommen, so dass die Professional Version erschwinglich wird. So jedenfalls meine Hintergrundinfos.

Aber das aller wichtigste ❗ ❗ ❗

  • Alle Visual Studio 2010 Versionen schließen den TFS und eine CAL mit ein ❗
    (Diese Info ist unter Vorbehalt!)
  • Der TFS bekommt eine neue Installationsform mit dem Namen Basic.

Soweit ich das verstanden habe ist das ein vollständiger TFS, wie wir ihn heute kennen aber ohne Sharepoint Overhead. Das bedeutet einfache Installation in 15 Minuten. Und das läuft auch auf einem DC oder SBS, für alle die, die sich keinen zweiten Server hinstellen wollen. Natürlich eignet sich die Basic Installation auch als Installation für den Einplatz (d.h. auch für jeden XP, Vista und Windows 7 Rechner).
Die TFS Basic Installation bietet alles und viel viel viel viel mehr,  als das was wir bisher mit VSS und Visual Studio erledigt haben.

Microsoft will also ganz klar den TFS pushen und auf jeden Entwickler dazu bringen den TFS zu nuzen. Das heißt natürlich in zweiter Linie eine klare Absage für Visual Source Safe (VSS). Man kann sicherlich den VSS auch weiterhin in 2010 nutzen, wie man das in Visual Studio 2005+2008 her kennt. Aber ich kann nur jedem raten sich schnellstmöglich mit dem TFS anzufreunden.
Der VSS Mainstream Support läuft noch bis 11.04.2011!

Anmerkung zum Schluß:
Die Beta2 schließt bereits eine Go-Live Lizenz mit ein, eigent sich also direkt auch für das produktive Entwickeln.

Nachtrag: Alle Infos zur Lizensierung und Bündelung der Pakete bitte ich noch mit etwas Vorbehalt zubehandeln. Die Informationen wie ich sie hier wiedergebe basieren auf einem Webcast vom letzten Freitag und geben wieder wie was ich verstanden habe.

Resümee bisher: Eine Übernahme aller Daten von VSS nach TFS mit VSSConvert kann man sich sparen

Wir haben Anfang des Jahres produktiv von Visual-Source-Safe (VSS) auf den Team Foundation Server (TFS) umgestellt.
Ich stand vor der Frage ob ich den bisherigen Source-Safe Inhalt komplett in den TFS übernehme und wie die eigentliche Migration auf den TFS möglichst schnell ablaufen kann.

In älteren Blog Artikeln habe ich ja bereits von dem Problem berichtet, dass wir sehr viel auch mit Shares unter VSS gearbeitet haben. Ich hätte hier sowieso tricksen müssen und die eigentliche Umstellung der Projekte in eine Struktur, die keine Shares mehr verwendet wollte ich dich lieber unter Nutzung des TFS durchführen.

Die Entscheidung viel also so aus:

  • Übernahme des aktuellen Programmstandes in das TFS System
  • Keine Übernahme der alten VSS Daten mit dem VSSConverter
  • Überarbeitung der Projektstruktur so dass, keine Datei-Shares mehr benötigt werden. Hierbei werden entsprechende übergeordnete Common Verzeichnisse verwendet.
  • Entzerrung der Gesamten Projektstruktur so, dass auch die Verwendung einer Master-Solution möglich wird.
  • Beibehalten der alten VSS Daten in einem Backup System, für evtl. Hotfixes der letzten Version und einige Legacy Projekte

Ich gebe zu, dass ich misstrauisch war. Auf die Historie des Source Control Systems nicht weiter als zum letzten Release zurückgreifen zu können erschien mir als großer Nachteil. Gerade weil wir hauptsächlich Projekte und Programmteile haben, die zum Teil schon auf 20 Jahre Geschichte zurückblicken und immer noch weiter entwickelt werden.
Letzten Endes haben aber alle Team Mitglieder bisher klar gesagt: „Schade, dass wir diesen Schritt au den TFS nicht eher gemacht haben“.
Im Nachhinein vermisst keiner die gesamte VSS Historie, der Projekte. Wer muss, der kann noch im alten VSS Backup-System stöbern. Aber das war bisher nur in einem einzigen Fall wichtig und hilfreich.

Ich kann aus meiner Sicht also dazu raten, einfach einen Cut mit dem aktuellen System zu machen und mit dem aktuellen Programmstand einfach in das TFS System einzuchecken und einzutauchen. Sich zwei Tage und mehr mit dem VSSConvert herumzuschlagen (wie ich es zum Teil schon gehört habe), ist aus meiner Sicht heute vertane Zeit.

TFS-2008 mit Visual Studio 2005 und anderen älteren Entwicklungssystemen benutzen

Ist man eigentlich gezwungen Visual Studio 2008 zu verwenden wenn man Team Foundation Server 2008 nutzt?

Nein! Wenn man Visual Studio 2005 und 2008 nutzt, wie auch ich für einige Projekte, dann kann man ohne weiteres trotzdem aus allen Systemen auf TFS-2008 zugreifen.
Man muss nur den passenden Team Explorer installieren. D.h. für Visual Studio 2005 installiert man einfach den Team Explorer 2005. Der 2005er Explorer steht übrigens auch kostenlos zum Download zur Verfügung, wer evtl. keine Version des TFS-2005 hat (http://www.microsoft.com/downloads/details.aspx?FamilyID=46473C2A-BB85-4461-BB27-4792A5DEF222&displaylang=ja&displaylang=en)

Es ist klar, dass man in diesem Fall einige Features des TFS-2008 nicht benutzen kann, bzw. nur über den Team Explorer 2008. Aber das ist ja auch nicht weiter tragisch.
Tunlichst vermeiden sollte man aber neue Team-Projekte aus dem 2005er Explorer heraus anzulegen, das schlägt bei mir fehl.  Also neue TFS-Projekte zuerst im Team Explorer 2008 anlegen und dann mit Visual Studio 2005 bearbeiten.

Das Source Control System von TFS-2008 lässt sich übrigens mit den entsprechenden Microsoft Source Code Control Interface (MSSCCI). Ein entsprechendes Plugin gibt es hier zum Download: http://www.microsoft.com/downloads/details.aspx?familyid=faeb7636-644e-451a-90d4-7947217da0e7&displaylang=en. Diese Liste der unterstützen Systeme ist lang:

  • Visual Studio .NET 2003
  • Visual C++ 6 SP6
  • Visual Visual Basic 6 SP6
  • Visual FoxPro 9 SP1
  • Microsoft Access 2003 SP2
  • SQL Server Management Studio
  • Sparx Systems Enterprise Architect 6.1
  • Sybase PowerBuilder 10.5
  • Toad for SQL Server 2.0

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.

TFS 2008 und VC 6.0, VS.NET 2003 oder andere Oldies

Für den Team Foundation Server 2008 steht ein MSSCCI Provider zur Verfügung. (MSSCCI = Microsoft Source Code Control Interface)
Im Klartext heißt das: Auch den alten legacy VC 6.0 oder VS.NET 2003 Code kann man nun im Source Control System des Team Foundation Servers 2008 verwalten:
http://www.microsoft.com/downloads/details.aspx?FamilyId=FAEB7636-644E-451A-90D4-7947217DA0E7

Und Tschüss Visual SourceSafe :mrgreen:

Wer noch den TFS 2005 verwendet findet den entsprechenden Provider hier:
http://www.microsoft.com/downloads/details.aspx?FamilyId=87E1FFBD-A484-4C3A-8776-D560AB1E6198

Wie kann ich das Visual Source Safe Kennwort zurücksetzen?

Ja! Dieses Kennwort braucht man selten, aber wenn man es braucht hat man es vergessen.
Aber die UM.DAT zu hacken ist ziemlich simpel. Es gibt einige Anleitungen im Netz dazu.
Hier meine Vaiante die man mit jedem x-beibigen Hexeditor verwenden kann

  • Man sucht an den Adressen 0x84, 0xC4, 0x104, etc. den Benutzernamen Admin.
  • Hat man die Adresse gefunden z.B. 0x84 (was meistens der erste Benutzer Eintrag ist), dann geht man 0x20 Bytes weiter. In meinen Beispiel gelangen wir nun an die Adresse 0xA4.
  • Hier ersetzen wir einfach die nächsten 4 Bytes durch:
    0x90 0x6e 0x00 0x00

Das Kennwort ist nun leer! Man kann ein neues vergeben. 

PS: Es gibt andere Tipps, die ersetzen hier 6 Zeichen. Das sollte man unterlassen, denn die nächsten beiden Zeichen sind eine interne user ID.

PPS: Die extreme Sicherheit des Source Safe Kennwortes ist erkennbar an dem immens sicheren Hasing auf 32bit! 😀 Eine Brute Force Attacke per Batch zu betreiben sollte auch kein Problem sein…

BTW: Der Hack ist natürlich auf eigene Gefahr und sollte nur gemacht werden, wenn man auch eine Sicherung der UM.DAT hat!

VSS Undo Checkout für einen Anwender den es nicht mehr gibt…

Da ist eine Datei die man ändern will. Man checkt sie aus und bekommt gesagt, dass diese Datei vom Benutzer „Wareinmal“ ausgecheckt ist.  😕 „Wareinmal“ war einmal bei uns beschäftigt… Lange her. Rechner wurde schon recycled.

Im Source Safe Explorer bekomme ich einen Undo Checkout für diese Dateien nicht angeboten. Und nun?
Im Dunkeln erinnere ich mich an ein Admin Kennwort für Visual Source Safe.

  • Also Source Safe Explorer so starten:
    SSEXP -yAdmin
  • Kennwort eingeben.
  • Datei suchen.
  • Undo Checkout…

Fertig!

Was man beim Umstieg von VSS auf TFS bedenken muss!

Ich plane in der nächsten Zeit Visual Source Safe (VSS) abzulösen. Da wir alle Hauptprojekte (bis auf einigen legacy Kram) auf VC++ 2005 bearbeiten und die entsprechenden Visual Studio Team System Lizenzen haben beabsichtigen wir auch den Team Foundation Server (TFS) einzusetzen.
Einen Team Foundation Server kaufen müssen wir auch nicht, denn wir haben nicht mehr als 5 Clients.

Vorteile:

  • Integration auch in ältere Systeme ist kein Problem! Für VC6, VB6, VS.NET 2003 gibt es entsprechende Plug-Ins! Das ist schon mal genial. Also können wir theoretisch sogar alle legacy Projekte konvertieren und mit den alten Tools weiterarbeiten.
  • Alles wird in einem SQL-Server gehalten. Endlich!
  • Die Projekt Dokumente sind gleich in dem entsprechenden Share Point mit gehalten (leider noch WSS 2.0)
  • Einchecken mehrere Dateien werden direkt zu einem Vorgang zusammengefasst.
  • Direktes Bug-Tracking und einfache Projektierung ist möglich ohne externe Hilfsmittel.

Beim evaluieren der Features habe ich mir schon die Hände gerieben. Allerdings gibt es da eine wirkliche fette Kröte die ich schlucken muss. Mein geliebtes „Sharing“ unter VSS gibt es unter dem Source Control System von TFS nicht ❗

Wir haben einiges an gemeinsamen Code, den wir nicht in Libraries oder DLLs zusammengefasst haben. Da sind einige nette Template Klassen etc., spezielle Header und andere nette Code-Snipplets. Alle diese Code Teile waren in einem kleinen Projekt zusammengefasst und jeder Entwickler konnte diese wahlfrei in sein Projekt sharen. Das ist und war extrem bequem. Mit dem Drawback, dass eine zentrale Code Änderung alle Projekte beeinflusst und evtl. bricht kann man leben.
Man muss einfach regelmäßig Ohrfeigen verteilen für Entwickler die nicht testen und Kerker bei Brot und Wasser androhen… 😉

Unter TFS ist es damit vorbei. Einziger Ausweg wie ich ihn aktuell sehe ist es, die entsprechenden Codeteile einzubranchen in die anderen Projkete. D.h. aber das man die aktuelle Version (und den evtl. gewünschten Fix) nur mit einem Merge bekommt, was wieder nicht unbedingt automatisch geht, man muss also Hand anlegen was man evtl. eben auch vergisst.

Mal sehen vielleicht fällt mir da noch was anderes ein. Anonsten sieht das ganze sehr vielversprechend aus.