Visual Studio 2013 kategória bejegyzései

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:
Reklámok

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: ,,

Kód futtatása tesztelés elején és végén

Aki Visual Studioban írt már unit teszteket, biztosan találkozott a [TestClass] és [TestMethod] attribútumokkal, amelyekkel a teszteket tartalmazó osztályokat és a konkrét teszteket meg tudjuk jelölni. Hasonlóképpen használhatunk attribútumokat olyan kódok jelölésére, amelyeknek a tesztek előtt vagy után kell lefutniuk:

A TestInitialize és TestCleanup attribútumokkal ellátott metódusok minden teszt előtt és után futnak le.

A ClassInitialize és ClassCleanup attribútumokkal ellátott metódusok az osztályban található első teszt futtatása előtt és az utolsó futtatása után futnak le.

Az AssemblyInitialize és AssemblyCleanup attribútumokkal ellátott metódusok a szerelvényben található első teszt futtatása előtt és az utolsó futtatása után futnak le.

Az utóbbiak különösen hasznosak tudnak lenni CI esetén.

 

Technorati-címkék: ,

Hány kérés kell egy authentikációhoz?

Adott egy webszolgáltatás, amiről tudjuk, hogy csak Basic hitelesítéssel érhető el, de ez nem gond, hiszen szerencsére .NET-ben a generált proxy osztály Credentials tulajdonságán keresztül könnyű beállítani a szükséges felhasználónevet és jelszót:

MyService ws = new MyService
{
    Credentials = new NetworkCredential( "user", "password" )
};

Az ember azt gondolná, hogy ennek hatására olyan HTTP kérés megy majd a webszolgáltatás felé, amely tartalmazza az authenkációhoz szükséges adatokat, de a valóságban sajnos nem ez történik. Először elmegy egy olyan kérés, amiben nincs Authorization fejléc, azután ha a szerver ezt zokon veszi és 401 Authenticate válasszal tér vissza, akkor a kliens küld egy újabb kérést, ezúttal mellékelve hozzá a felhasználónevet és a jelszót. Az eredmény tehát dupla forgalom. Ha ez nem szimpatikus, és persze miért is lenne az, akkor jól jöhet a PreAuthenticate tulajdonság:

MyService ws = new MyService
{
    Credentials = new NetworkCredential( "user", "password" ),
PreAuthenticate = true };

 

Technorati-címkék: ,

PHP-s webszolgáltatás hívása .NET-ből

Úgy alakult, hogy .NET-ből kellett egy PHP-ban készült webszolgáltatást meghívnom standard SOAP interfészen keresztül, de ismét bebizonyosodott, hogy a Simple Object Access Protocolban a “simple” egyszerűen nem igaz, ugyanis a két fél összereszelése nem ment teljesen simán.

A hívás eredményeként a kliens 400 Bad Request státuszkódot kapott vissza, ami önmagában nem sokat segített a hibakeresésben. Az Apache webszerver naplójában ugyan volt egy Invalid URI in request bejegyzés, de ez sem vitt közelebb a megoldáshoz.

Mint már oly sokszor, most is a Fiddler segített. Megnézve vele a HTTP forgalmat gyanús lett, hogy a kérésben szerepel egy Expect: 100-continue fejléc, amiről később kiderült, hogy a PHP-s webszolgáltatás nem tud vele mit kezdeni. Ez egy elég érdekes fejléc, arra találták ki, hogy a kliens megkérhesse a szervert, hogy még a body felküldése előtt kiértékelje a kérésben szereplő fejléc mezőket, és egy 100 Continue válasszal jelezze, ha a fejlécek alapján hajlandó lesz feldolgozni a kérést, és a kliens bátran küldheti a body-t (bővebben lásd RFC 2616 8.2.3). Magyarul a klasszikus kérés-válasz sorrendet szépen fel lehet vele borítani:

Kliens –> Szerver:

POST example.com HTTP/1.1
kérés fejlécek
Expect: 100-Continue

Szerver –> Kliens:

HTTP/1.1 100 Continue
válasz fejlécek

Kliens –> Szerver:

kérés body

Szerver –> Kliens:

HTTP/1.1 200 OK
válasz fejlécek
válasz body

A .NET kliens mindig elküldi az Expect: 100-Continue fejléc sort, hogy spóroljon a hálózati forgalommal, sajnos azonban a jelek szerint nem minden szerver támogatja ezt a csavarást. Ezt a viselkedést a ServicePointManager osztály Expect100Continue tulajdonsága segítségével lehet felüldefiniálni:

ServicePointManager.Expect100Continue = false;

Még az is lehet, hogy így lesz gyorsabb a kódunk, hiszen a HttpWebRequest osztály alapértelmezés szerint 350 milliszekundumot vár a Continue válaszra.

 

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: