Microsoft Nyári Akadémia – .NET vNext

2014.07.6. 11:53 Hozzászólás

Kedden a Microsoft Nyári Akadémia programsorozat megnyitásaként a .NET és az ASP.NET következő verziójáról tartottam egy bevezető előadást. Az előadásnak a “.NOT, avagy .NET vNext” címet adtam, mert az új verzió számos gyökeres változást hoz, sok esetben teljesen átírva azt, amit a .NET-ről eddig tanultunk.

Ahhoz, hogy ezeknek a változásoknak az okait megértsük, mindenképp látnunk kell azt, hogy a Microsoft másfél évtizede rakta le a .NET platform alapjait, és ennyi idő alatt ez a szakma, különösen a webes világ, rengeteget változott. Kezdetben a cég ezekre a irányváltásokra pont olyan fürgén reagált, mint egy konténerszállító teherhajó, de azután a webes termékcsapat szépen magára talált, és a teherhajóból fürge romboló lett. A WebForms ás a .NET hiányosságait szépen sorban igyekeztek pótolni, megjelent a NuGet, az MVC, a WebPages és a WebAPI.

A végeredmény azonban nem egyetlen technológia lett, hanem egymáshoz nagyon hasonló, egymással rokon programozási keretrendszerek összessége. És bár hívhatjuk “One ASP.NET”-nek, amíg az MVC és a WebAPI más filtereket használ, vagy az MVC-ben és a WebPages-ben más a HTML helperek implementációja, addig ez az elnevezés sántít.

A webes termékcsapat nagyon jól ráérzett, hogy itt egy komolyabb vérfrissítésre van szükség. És ha már újraírják az MVC-t úgy, hogy magába olvassza a WebAPI-t és a WebPagest is, akkor át lehet gondolni az ASP.NET-nek azokat a részeit is, amik valóban közösek. Elég csak a mindenhol jelenlevő HttpContext objektumra, a System.Web.dll-re, vagy a teljes végrehajtási csővezetékre gondolni. Sőt mi több, ha figyelembe vesszük az új fordító (Roslyn) és új JIT fordító (RyuJIT) képességeit, akkor fel kell hogy merüljön a BCL és a CLR cseréjének kérdése is.

A Microsoft nem kisebb dologra vállalkozott, mint hogy a .NET következő verziójára refaktorálja a BCL-t, kicseréli a runtime-ot, átdefiniálja az egységnyi kód fogalmát, elpusztítja a GAC-ot, újraírja az ASP.NET platformot, és hozzá természetesen a teljes eszközparkot. Mindezt kezdettől fogva cross-platform módon, a legmodernebb tervezési mintákat követve, a felhőre optimalizálva és a modern kor elvárásainak megfelelően nyílt forráskódú módon. És itt most nem arra a “klasszikus Microsoftos” nyílt forráskódra kell gondolni, amikor a rendszer megjelenése után sok hónappal kiteszik a CodePlexre a kipucolt forrásfájlokat, hanem arra az igazi Githubos nyílt forráskódú világra, amiben mindenki küldhet pull requesteket.

Ezekről beszélgettünk a Nyári Akadémián. Akit érdekel a diasor (és benne a demók), megtalálja a Slideshare-en:

 

A teljes platform fejlesztése egyelőre nagyon korai fázisban van, és természetesen még nagyon sok változásra lehet számítani. Aki mégis szívesen ismerkedne vele, itt kezdhet hozzá:

 

Technorati-címkék: ,,,
Kategóriák:vNext Címkék: , , ,

Megjelent a .NET Framework 4.5.2

Bejelentés és az újdonságok rövid áttekintése: Announcing the .NET Framework 4.5.2

Az újdonságokról kicsit bővebben: What’s new in the .NET Framework 4.5.2

Telepítőcsomagok:

Vigyázat, in-place upgrade! A 3.5 SP1 és korábbi verziókkal side-by-side települ, de a 4, 4.5 és 4.5.1 verziókat in-place frissíti. Ezért is lehet fontos az alábbi tudásbázis cikk:
KB 2962547 – Known issues for the .NET Framework 4.5.2

Lehet töltögetni!

 

Technorati-címkék:
Kategóriák:.NET 4.5 és Visual Studio 2012 Címkék:

Ingyenes e-book Windows (Phone) 8.1 fejlesztéshez

2843.9780735611111f_7E0540F4A Windows 8 megjelenésével egy időben adta ki a Microsoft Press Kraig Brockschmidt Programming Windows Store Apps with HTML, CSS and JavaScript c. könyvét ingyenes e-book formájában. A 8.1 verzió megjelenésével a könyv kissé elavult, de szerencsére Kraig nem csüggedve tovább dolgozott rajta.

Most jelent meg a könyv második kiadása, amely 478 oldallal kibővítve immár a Windows 8.1 újdonságait is lefedi, sőt jelentős része alkalmazható Windows Phone 8.1 fejlesztéseknél is. A teljes könyv így 1311 oldalas lett, és szerencsére továbbra is ingyenesen tölthető le a Microsoft Virtual Academy oldaláról a kapcsolódó példakódokkal együtt.

 

Kategóriák:Mobil 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: ,,
Kategóriák:Visual Studio 2013 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:
Kategóriák:Visual Studio 2013 Címkék: ,

TFS work item típusok testreszabása

Az egyik legjobb dolog a TFS-ben, hogy a forráskód változását nem csak a changesetekhez írt kommentek dokumentálják, hanem minden változást feladatokhoz, work itemekhez rendelhetünk. A TFS ad nekünk néhány feladat típust (Bug, Task, Issue, User Story stb.), de persze előfordulhat, hogy ezek nem teljesen elégítik ki az igényeinket és jó lenne módosítani őket.

A work item típusok kezelésére hagyományosan a parancssoros witadmin.exe szolgál, amivel exportálhatjuk a típus definíciókat XML-be, majd módosítás után visszatölthetjük őket a szerverre. A módszer előnyre, hogy a módosított XML-t stílszerűen elmenthetjük a TFS-be :)

Aki a grafikus módszereket jobban kedveli, annak érdemes a nem támogatott, ám elég ütős TFS Power Toolst feltelepíteni. Telepítés után megjelenik a Tools menüben egy Process Editor menüpont, amivel megnyithatjuk a work item típus definícióját közvetlenül a szerverről:

vs-open-wit-from-server

Csak ki kell választanunk, hogy melyik projekt melyik típusát akarjuk szerkeszteni:

vs-select-work-item-type

És máris megkapjuk a típushoz tartozó tulajdonságok listáját:

vs-work-item-type-properties

Ha például zavaró, hogy az Assigned To mező mindig megjeleníti a szerver összes felhasználóját, akkor kiválaszthatjuk ezt a mezőt a listából, majd az Edit gombra kattintva módosíthatjuk azt. A felugró szerkesztő ablak második, Rules fülén látható a probléma forrása:

vs-field-definition

A gond a Team Foundation Server Valid Users csoportot jelentő VALIDUSER sor, ami tartalmazza az összes projekt összes felhasználóját. Ezt törölhetjük, és felvehetjük helyette az ALLOWEDVALUES szabályt, ahol felsorolhatjuk a választható elemeket. Praktikus felhasználói csoportot megadni, ahol szerver szintű csoportra [Global]\csoportnév, az aktuális projekt csoportjaira pedig [Project]\csoportnév formában hivatkozhatunk. Például:

vs-field-definition-allowedvalues

A Rule Type ablakban megjelenő lehetőségek teljes dokumentációja megtalálható az MSDN All FIELD XML elements reference oldalán.

Save hatására a módosítások közvetlenül a szerverre mentődnek vissza, de hogy a Studio is érzékelje őket, célszerű egy frissítést kérni a Team Explorer ablakban.

 

Technorati-címkék: ,,
Kategóriák:Visual Studio 2013 Címkék: ,

UriFormatException TFS teszt e-mail küldésekor

2014.03.28. 4:00 Hozzászólás

A Team Foundation Server Administration Console egy igen barátságos alkalmazás. Látszik, hogy a felület tervezésekor végiggondolták a tipikus üzemeltetői feladatokat, ezért lehet például könnyen megváltoztatni a service accountot vagy a szerver URL-jét, ráadásul szinte minden beállítás mellett ott van kéznél egy Test gomb, amivel gyorsan kipróbálhatjuk, hogy jó értéket adtunk-e meg.

Az egyik hasznos funkció, hogy a levelezési beállítások mellett található egy Send Test Email funkció:

tfs-email-settings

Ha rákattintunk, akkor a felugró ablakban meg kell adnunk a teszt levél címzettjének e-mail címét és egy szöveget, ami bekerül a levélbe:

tfs-test-email

Ha szerencsénk van, akkor simán el is megy a levél:

tfs-test-email-success

Azonban előfordulhat, hogy nem sikerül a küldés, hanem az alábbi hibaüzenetet kapjuk:

Unable to connect to the TFS server to test email settings. Url = ‘/_api/_common/TestMailSettings?sendTo=myuser%40example.com&message=Test+email’. Exception = System.UriFormatException: Invalid URI: The format of the URI could not be determined.
   at System.Uri.CreateThis(String uri, Boolean dontEscape, UriKind uriKind)
   at System.Net.WebRequest.Create(String requestUriString)
   at Microsoft.TeamFoundation.Admin.Console.Models.DlgSendTestMailViewModel.SendEmail()

tfs-test-email-error

Az ember ilyenkor átnézi az e-mail küldés beállításait, csakhogy a hibát jelen esetben nem ott kell keresni. Nyissuk meg a Change URLs ablakot, és ellenőrizzük, hogy a Server URL rovatban a Use localhost opció legyen kiválasztva:

tfs-change-urls

Az e-mail küldéses hiba ugyanis csak akkor jön elő, ha a második opciót választjuk, és localhost helyett a gép nevét adjuk meg a Use: rovatban. Akit érint, a Connecten szavazhat, hátha hamarosan kijavítják.

 

Technorati-címkék: ,
Kategóriák:Visual Studio 2013 Címkék: ,
Követés

Értesítést küldünk minden új bejegyzésről a megadott e-mail címre.

Csatlakozz a 78 követőhöz

%d honlapszerkesztő ezt szereti: