Visual Studio címkéhez tartozó bejegyzések

Open source fejlesztés Visual Studioval

A legutóbbi LogMeIn-Microsoft Enterprise Developer Meetup utáni beszélgetésünk során az egyik résztvevő mesélte, hogy bár náluk mindenkinek van jogtiszta Visual Studioja, a cég megvásárolt több tucat licencet egy másik fejlesztőeszközhöz, mert a következő projektjüket nyílt forráskódú technológiákkal, node.js alapon fogják megvalósítani, és “ahhoz ugye a Visual Studio nem jó”.

Bár korábban a Visual Studio tényleg elsősorban .NET-es alkalmazások fejlesztésére volt ideális, az utóbbi időben a Microsoft igen komolyan nyit a nyílt forráskódú világ felé, ezért szerintem érdemes egy próbát tenni, és saját véleményt alkotni. Csináljunk hát egy egyszerű node.js projektet, pakoljunk hozzá mindent, amit ilyenkor szokás, és nézzük meg, hogy mennyire kellemes élmény mindezt Visual Studioval megtenni!

 

Repository létrehozása

Az első lépés egy közös tárhely létrehozása a kódunk számára, ami mi más lehetne mint egy Github repository. Akinek még nincs felhasználói fiókja a Githubon, pillanatok alatt létrehozhat egyet, csak el kell látogatni a github.com oldalra és ki kell tölteni ezt a roppant bonyolult űrlapot:

01v

Username-ként érdemes olyat választani, ami nem túl hosszú, és URL-ben is jól mutat.

Ha ez megvan, akkor a jobb felső sarokban a nevünk mellett található “+” ikonra kattintva csalhatjuk elő a Create menüt, amiben a New repository menüpontra kattintva haladhatunk tovább:

02v

Az új repó létrehozása igen egyszerű, az űrlapon csak a név kitöltése kötelező, de célszerű rögtön a leírás rovatot is kitölteni, mert ha belejövünk a repó gyártásba, fél év múlva fogalmunk sem lesz, hogy ezt éppen mihez hoztuk létre:

03v

Az űrlap alján van három alapból nem bekattintott opció, amivel szerintem érdemes élni:

Ha bekapcsoljuk az Initialize this repository with a README opciót, akkor a repóban rögtön lesz egy README.md nevű (így nagybetűvel, kis kiterjesztéssel) szövegfájl, ami gyakorlatilag a projektünk kezdőlapjaként viselkedik. Bátran kapcsoljuk be, így nem kell később nekünk létrehozni, és sokkal jobb érzés lesz, hogy a kódtárunk (mi a repository szó jó fordítása?) nem kong az ürességtől, máris publikáltunk benne valamit.

Az Add .gitignore megértéséhez először azt kell megtanulnunk, hogy mi az a .gitignore. Git verziókezelő esetén a repó gyökerében lévő .gitignore fájl (így kisbetűvel, név nélkül, csak kiterjesztéssel) segítségével határozhatjuk meg, hogy mik azok a fájlok, amiket nem szeretnénk betenni a közösbe. Alapértelmezés szerint ugyanis minden fájl, ami a könyvtárban van, bekerül a repóba és eljut a többi fejlesztőhöz is. Csakhogy tipikusan nem akarunk megosztani helyi naplófájlokat (*.log) vagy a fordító kimenetét, és pont az ilyen kivételeket lehet felsorolni a .gitignore-ban. Mivel egy adott fejlesztőkörnyezetre/platformra jellemző, hogy tipikusan minek nem kell bekerülnie a verziókezelő rendszerbe, ezért a Github már tartalmaz egy rakás előre gyártott .gitignore fájlt, nekünk csak választani kell a listából, de persze később módosíthatjuk majd a fájlt.

Mivel itt node.js projektet fogunk készíteni, válasszuk a Node opciót, de .NET projektek esetén a VisualStudio.gitignore jobb választás. A fájlnak van egy nem bonyolult, de sajátságos szintaktikája, amiről a dokumentációt megtalálhatjuk itt.

Az Add license opcióval egy csapásra létrehozhatunk a repónkban egy LICENSE nevű (így nagybetűvel, kiterjesztés nélkül) szövegfájlt, ami a kódunkhoz tartozó licenc szövegét tartalmazza. A különböző licencek közötti eligazodásban nekem legjobban a TLDRLegal oldal segített, de ha tudtok jobbat (akár magyar nyelvűt), kérlek írjátok meg kommentben.

Végre kattinthatunk a Create repository gombra, és pillanatok alatt el is készül forráskódunk új otthona, felül a generált fájlok, alul a README tartalma, jobb oldalt pedig az opciók:

04v

 

Repository klónozása

Az eddigi lépéseket csak a weboldalon tudjuk elvégezni, nem is szokás közvetlenül a fejlesztőkörnyezetet használni ehhez a művelethez. A következő lépés, hogy ez a repository megjelenjen a saját gépünkön, amihez –  ősmagyar szakkifejezéssel élve – le kell klónoznunk azt. A klónozáshoz szükséges a repository URL-je, amit a jobb oldalon található Copy to clipboard gombbal gyorsan a vágólapra menthetünk.

A klónozáshoz már bátran használhatjuk a Visual Studiot (én a VS 2015 CTP 6-ot fogom használni), azon belül is a Team Explorer ablakra lesz szükségünk:

05v1

A Team Explorer ablakban kattintsunk először Clone linkre, majd töltsük ki a mini űrlapot:

05v2

Az URL-t másoljuk be a vágólapról, helyi mappának pedig tetszőleges mappát megadhatunk, ami mostantól a repó gyökereként fog viselkedni. Mivel nyílt forráskódú projektek esetén nem ritka a mély könyvtárhierarchia, ami akár problémát is okozhat, célszerű rövid útvonalat választani. A sikeres klónozásról a Team Explorer közepén kapunk tájékoztatást:

06

A Team Explorer ablak alján, a Local Git Repositories részben láthatjuk felsorolva a Visual Studio által ismert összes repót, ahol most már a saját projektünk is megjelenik. Mivel ezzel szeretnénk dolgozni, kattintsunk rá duplán!

Bátran nyissuk meg a projektünk mappáját Windows Explorerben is, ahol ezt fogjuk látni:

08

A Git verziókezelő rendszer összes okossága a rejtett .git mappában található, ezért vigyázzunk erre a mappára.

 

Repository konfigurálása

Visual Studioban a projekt nevére kattintva a Team Explorer ablak Home oldalára jutunk:

07v

Itt a Settings…,

09v

majd a Global Settings gombokra kattintva azokat a Git specifikus beállításokat csalhatjuk elő, amik minden Gites projektünkre vonatkozni fognak:

11v

Hol tárolódnak ezek a beállítások? A bejelentkezett felhasználó profil mappájában lévő .gitconfig fájlban:

12

Ez egy szöveges fájl, simán megnyithatjuk Studioval, ha úgy kényelmesebbnek tűnik a szerkesztése, de ehhez érdemes elolvasni a hivatalos dokumentációt is:

13v

A Settings ablakban feltűnhetett egy Install 3rd-party tools, amire kattintva ez a képernyő fogad:

14v

Sajnos ez a képernyő csak azt mondja el, hogy mivel fog telepíteni, azt nem, hogy mit. Az Install gombra kattintva egy msysgitvs.exe akar letöltődni:

15v

Ez tartalmazza a beígért Web Platform Installert, majd azzal telepíti a Git for Windowst (msysgit), ami az eredetileg Linuxos Git Windowsos változata. Nagy baj nem lehet belőle, bátran telepíthetjük.

Ezzel meg is ágyaztunk a projektnek a gépünkön, nincs más hátra, mint kódot írni bele!

 

Értékelés

Ebben a részben a forráskód alapjait raktuk le, és ehhez szerintem a Visual Studio tökéletesen megfelelt. Hogy a Team Explorer ablak mennyire optimális és felhasználóbarát, azon lehet vitatkozni, de az tény, hogy a szükséges műveleteket egyszerűen el lehetett végezni vele. Aki nem hiszi, próbálja ki, a projekt elérhető a https://github.com/balassy/vs-node-example címen.

 

(Folytatás következik…)

Technorati Tags: ,,

Kértem és kaptam egy .vs mappát és a Visual Studio csapattól

Biztos mindenkinek feltűnt már, hogy a Visual Studio új fájlokat hoz létre a solution mappájában, akár tetszik, akár nem. Az egyik ilyen a .suo kiterjesztésű Solution User Options fájl, ami az adott fejlesztői géphez kapcsolódó beállításokat tartalmazza, és hiába töröljük le, hamar visszanő.

vs_2013_suo

Az ilyen fejlesztő vagy fejlesztői gép szintű beállításokat tartalmazó fájlokra különösen forráskódkezelő rendszer esetén kell figyelni, hiszen nem szabad őket megosztani a többi fejlesztővel. Nem véletlen, hogy a Visual Studios projektekhez ajánlott .gitignore fájlban is első helyen szerepel a *.suo.

Sajnos nem ez az egyetlen ilyen jellegű fájl, különböző projekt típusok esetén ezek szépen el tudnak szaporodni, ami meg tudja keseríteni az életünket. Mennyivel szebb lenne, ha az összes ilyen jellegű fájl egyetlen mappában lakna!

Szerencsére a Visual Studio 2015-ben ezt már megoldották, és bepakoltak mindent egy külön mappába, amit más fejlesztőkörnyezetekhez hasonlóan .vs-nek hívnak:

vs_2015_suo

A .vs egy rejtett mappa, tehát be kell kapcsolni a Windows Explorerben a Show hidden files, folders, and drives opciót a megjelenítéséhez, ha nézegetni szeretnék (de miért is szeretnénk?). Jelenleg (Visual Studio 2015 CTP6) a .suo fájl és a Visual Basic illetve C# fordítók IntelliSense adatbázisai kerülnek ebbe a mappába, de szépen sorban minden ide fog átköltözni, és reméljük ezt a gyakorlatot az add-in gyártók is követni fogják. Amikor meglévő solutiont frissítünk VS 2015-re, nem fognak automatikusan letörlődni a korábbi fájlok, hogy minden beállításunk megmaradjon, ha ugyanarra a projektre a Visual Studio korábbi verziójával rányitnánk.

A legszebb az egészben, hogy ezt a mappát nem a Visual Studio fejlesztőcsapat találta ki. Azért került a termékbe, mert én kértem. Meg még rajtam kívül 2822 másik ember a Visual Studio UserVoice oldalon. A csapat elolvasta, átgondolta, elfogadta és megcsinálta.

Kellemes érzés, amikor a fejlesztők figyelnek a felhasználókra.

 

Technorati Tags:

Túl sok segédvonal Visual Studioban

Feltetted a Productivity Power Toolst talán mert jó kis függőleges segédvonalakat szerettél volna látni a szerkesztőben, de mielőtt bármit is beállítottál volna, megjelentek maguktól mindenhol?

vs-guidelines-too-much

Ráadásul bármennyire pontosan kattintasz rájuk, ki sem tudod kapcsolni őket, mert a Remove Guideline menüpont mindig inaktív?

vs-guidelines-menu-disabled

Íme a megoldás: ne a Column Guides, hanem a Structure Visualizert kapcsold ki, az a bűnös:

vs-guidelines-options

Ezzel persze pár tooltipet is elvesztesz, de legalább oda tehetsz segédvonalat, ahova csak szeretnél.

 

Technorati-címkék:

Visual Studio: Unable to check out the current file

Érdekes hibába futottam bele, miközben egy szolgáltatás referenciát próbáltam felvenni Visual Studioba. Az URL egy .svc fájlra mutatott, aminek a szerkezetét az Add Service Reference dialógusablak gond nélkül felismerte, ám az ablak bezárásakor a Studio a következő hibaüzenettel örvendeztetett meg:

Unable to check out the current file.  The file may be read-only or locked, or you may need to check the file out manually.

Bár az adott projekt történetesen valóban source control alatt volt, Git-ről lévén szó a “check out” kifejezés nem tűnt helyénvalónak. Az igazság az, hogy a fenti hibaüzenet teljesen rossz és semmi köze a verziókezelőhöz, és a megoldás az, hogy nem közvetlenül az Add Service Reference, hanem azon belül az Advanced gombra, majd az Add Web Reference gombra kattintva megjelenő dialógusablakot kell használni az adott szolgáltatás esetén.

 

Technorati-címkék: ,,

Visual Studio “14” CTP SxS

Sorra jelennek meg a Visual Studio következő változatának előzetesei, ún. CTP, azaz Community Technology Preview formában. A CTP-k célja, hogy a fejlesztőcsapat minél korábban kapjon visszajelzéseket az újabb funkciók működéséről, ennek megfelelően ezekre koncentrálnak, nem pedig arra, hogy minden korábban bevezetett funkció is helyesen működjön. Simán előfordulhat, hogy egy korábbi verzióban már stabilan működő funkció egy CTP-ben elromlik (lásd Release Notes). Semmi gond, nem kell aggódni, a következő stabil release-re biztosan ki fogják javítani (főleg akkor, ha jelentjük a hibát). Ezzel teljesen összhangban a Microsoft nem csak hogy hivatalosan nem támogatja a CTP verziókat, de egy CTP telepítésével az egész “gép” támogatása megszűnik.

A legjobb megoldás a CTP kipróbálására a virtuális gép. Sajnos a Visual Studio csapat nem tesz elérhetővé telepített és előre konfigurált virtuális gépeket, aminek a fő oka, hogy így a telepítés folyamatát is sokan tesztelik világszerte különféle környezetekben. Azure előfizetéssel rendelkezők azonban kényelmes helyzetben vannak, mert számukra a Virtual Machine Gallery-ben elérhetőek ilyen konfigurációk.

Mi a helyzet a bátrak módszerével, a side-by-side telepítéssel? Természetesen a végleges verziót lehet majd a korábbi verzió mellé telepíteni, azonban CTP esetén ez fokozottan kockázatos. A VS “14” CTP 1 telepítője nem is engedte ezt, de mivel a csapat folyamatosan dolgozik a kapcsolódó problémák megoldásán, ezért a CTP 2-től már technikailag ugyan lehet side-by-side telepíteni, továbbra is az az ajánlás, hogy teszt gépen célszerű kipróbálni.

Side-by-side telepíteni nem kell félnetek jó lesz én nem ellenzem.

 

Technorati-címkék: ,

TFS adatbázis költöztetése másik szerverre

Előfordulhat, hogy a Team Foundation Serverünk adatbázisát át kell vinnünk másik gépre, például mert:

  • Frissítjük alatta a hardvert vagy a szoftvert (migration upgrade).
  • Szét szeretnénk osztani az adatokat több TFS szerver között (split).
  • Szeretnénk egy másolatot az éles adatokról teszteléshez.

A folyamat viszonylag egyszerű, de a sorrend fontos:

  1. Gondoskodjunk róla, hogy a célkörnyezetben egyező vagy frissebb verziószámú SQL Server legyen. Ez azért kell, mert az újabb SQL Serveren készült mentést a régebbiekre nem lehet visszaállítani.
  2. Gondoskodjunk róla, hogy a célkörnyezetben pontosan egyező verziószámú TFS legyen, beleértve nem csak a nagyobb javítócsomagokat, hanem minden hotfixet.
  3. A forrás szerveren:
    1. A TFS Admin Console-on állítsuk le a project collectiont (Stop Collection).
    2. A TFS Admin Console-on válasszuk le a leállított project collectiont (Detach Collection).
    3. Az SQL Server Management Studio segítségével készítsünk egy teljes mentést a project collection adatbázisáról.
  4. Vigyük át a mentést a cél szerverre.
  5. A cél szerveren:
    1. Az SQL Server Management Studio segítségével állítsuk vissza az adatbázis mentést egy új adatbázisba.
    2. A TFS Admin Console-on csatoljuk fel az adatbázist (Attach Collection).
    3. Szükség szerint módosítsuk a SharePoint és Report Server beállításokat.

Előfordulhat, hogy a cél szerveren nem sikerül felcsatolnunk az adatbázist, hanem az alábbi hibaüzenetet kapjuk:

TF254078: No attachable databases were found on the following instance of SQL Server: MyServer. Verify that both the name of the server and the name of the instance are correct and that the database was properly detached using the detach command in the Team Foundation Administration Console.

tfs-attach-db-not-found

A hibaüzenet egészen jó, ezeket kell ellenőrizni:

  • Valóban sikerül-e csatlakozni, méghozzá a TFS Service account nevében a megadott SQL Server példányhoz és azon belül az adatbázishoz.
  • Valóban azonos TFS verzió van-e a forrás és a cél környezetben.
  • Nem hagytuk-e ki a 3b. lépést, azaz az SQL mentés előtt rendesen leválasztottuk-e a TFS-ről az adatbázist.

A második és harmadik kritériumot a TFS úgy ellenőrzi, hogy először lekérdezi az SQL Serveren lévő adatbázisokat, majd mindegyiken lefuttatja az alábbi lekérdezést:

SELECT name, value 
FROM   sys.extended_properties 
WHERE  name LIKE 'TFS_%'

Azaz lekérdezi a “TFS_”-sel kezdődő egyedi tulajdonságait az adatbázisoknak. Ellenőrzésképpen ezt mi is megtehetjük a cél környezetben a Configuration adatbázison, és valami hasonlót kell kapnunk:

tfs-properties-configuration-db

Egy korrektül felcsatolt adatbázison:

tfs-properties-attached-db

És végül egy korrektül leválasztott adatbázison:

tfs-properties-detached-db

Ha nem találjuk a TFS_SNAPSHOT_STATE tulajdonságot Complete értékkel, akkor gyanakodjunk, hogy elfelejtettük a Detach Collection gombot megnyomni a TFS Admin Console-on.

 

Technorati-címkék: ,,

TFS adatbázis takarítása

Ha egy projekt adataira már nincs szükség, a Team Foundation Serverről többféleképpen is törölhetjük azokat:

  • A TFS Administration Console felületén a Team Projects fülön van egy Delete gomb.
  • Használhatjuk a tf.exe delete opcióját, ami gyorsan lefut, cserébe szinte csak annyit csinál, hogy töröltre állítja az elemeket, amiket szükség esetén az undelete segítségével visszaállíthatunk.
  • A tf.exe destroy opciója véglegesen törli az elemeket, futtatása után azokat már nem tudjuk visszaállítani. Hátránya, hogy csak a version control adatokat tud törölni.
  • A TFSDeleteProject.exe szintén parancssori eszköz, és nem csak a TFS adatbázisában, hanem a reporting adatbázisban és a SharePointban lévő adatokat is tudja törölni.

Az összes megközelítés közös jellemzője, hogy hiába törlünk ki sok adatot, a TFS SQL adatbázisának mérete nem fog csökkenni. Ennek pedig az az oka, hogy minden módszer hagy hátra maga után olyan adatokat, amikre már nincs szükség, méghozzá többnyire a Content táblában. Ezeknek a törléséért a TFS Background Job Agent által futtatott egyik job a felelős, ami viszont csak naponta fut.

Ha nem akarunk ennyit várni, akkor az egyik lehetőségünk, hogy a tf destroy futtatásakor használjuk a /startcleanup kapcsolót, ami azonnal elindítja a takarítást.

Egy másik lehetőség, hogy kicsit beletúrunk az adatbázisba és manuálisan indítjuk el azokat a tárolt eljárásokat, amik a takarítást végzik. Ha a Content tábla nagy:

EXEC prc_DeleteUnusedContent 1

Ha a Files tábla nagy:

EXEC prc_DeleteUnusedFiles 1, 0, 1000

Ez utóbbi tárolt eljárás sokáig is futhat, ezért találták ki neki a harmadik paramétert, amivel meg lehet határozni, hogy mekkora darabokban dolgozzon. Ennek megfelelően célszerű többször lefuttatni, illetve ha gyorsan fut, akkor a harmadik paraméter értékét lehet növelni.

Ez természetesen nem támogatott eljárás, de nálam bevált.

 

Technorati-címkék: