Category Archives: .NET 4.5 és Visual Studio 2012

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:

MSB4175: The task factory "CodeTaskFactory" could not be loaded

Az alábbi hibaüzenetbe sikerült belefutnom fordítás közben:

C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v12.0\CodeAnalysis\Microsoft.CodeAnalysis.targets(214,5): error MSB4175: The task factory "CodeTaskFactory" could not be loaded from the assembly "C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Build.Tasks.v12.0.dll".

Could not load file or assembly ‘file:///C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Build.Tasks.v12.0.dll’ or one of its dependencies.

The system cannot find the file specified.

A dolog különlegessége, hogy a gépen csak VS 2013 volt, 2012 soha.

A problémát talán az okozza, hogy a 2013-as verziótól kezdve az MSBuild már nem a .NET Framework, hanem a Visual Studio része, ennek megfelelően a fájlrendszerben is máshol laknak a hozzá tartozó fájlok. A hibaüzenetből kiderült, hogy a Microsoft.Build.Tasks.v12.0.dll fájlt a rendszer a C:\Windows\Microsoft.NET\Framework64\v4.0.30319 mappában keresi, pedig nálam itt található: C:\Program Files (x86)\MSBuild\12.0\Bin. Átmásoltam, és azóta megy rendesen.

Valószínűleg nem ez a legszebb megoldás, de mivel a forráskódhoz nem lehetett hozzányúlni, és nálam megoldotta a problémát, nyugodtan alszom.

 

Technorati-címkék: ,,

Az IIS Express kitakarítása

Az IIS Express a beállításait a %USERPROFILE%\Documents\IISExpress\config\applicationHost.config fájlban tárolja, ami nagyon kényelmes, hiszen így nem szükséges rendszergazdai jog a szerkesztéséhez. Ennek következménye, hogy a Visual Studio eltávolításával a webszerver és a webalkalmazások beállításai megmaradnak.

Előfordulhat, hogy eltávolítjuk a VS 2012-t, telepítjük a 2013-as verziót, majd létrehozunk egy új webalkalmazást, ami szokatlanul viselkedik, például minden indításakor Windowsos bejelentkezést kér. Ez lehet amiatt is, hogy a korábban már hoztunk létre ugyanilyen néven webhelyet az IIS Expressben, aminek a beállításai megőrződtek a konfigurációs fájlban.

Ha a szokásos projektjeink mellett gyakran hozunk létre tesztelésre webprojekteket, akkor időnként érdemes kitakarítani az IIS Expresst. Mivel nincsen hozzá grafikus felületünk, vagy kézzel szerkesztjük az applicationHost.config fájlt, vagy parancssorból esünk neki.

Az Expresses appcmd.exe a C:\Program Files (x86)\IIS Express mappában található. Listázhatjuk vele a webhelyeket:

C:\Program Files (x86)\IIS Express>appcmd list site
SITE "WebSite1" (id:1,bindings:http/:8080:localhost,state:Unknown)
SITE "MyProject" (id:2,bindings:http/*:44441:localhost,https/*:44300:localhost,state:Unknown)
SITE "WebSite1(1)" (id:3,bindings:http/*:44468:localhost,state:Unknown)
SITE "WebSite2" (id:4,bindings:http/*:44465:localhost,state:Unknown)

Ha a webhelyek nevei nem mondanak sokat, akkor listázhatjuk a virtuális mappákat, mert azok mellett megjelennek a fizikai útvonalak is:

C:\Program Files (x86)\IIS Express>appcmd list vdir
VDIR "WebSite1/" (physicalPath:%IIS_SITES_HOME%\WebSite1)
VDIR "MyProject/" (physicalPath:W:\Projektek\MyProject)
VDIR "WebSite1(1)/" (physicalPath:W:\Temp\WebSite1)
VDIR "WebSite2/" (physicalPath:W:\Desktop\WebSite2)

Ha valamelyik webhelyre még szükségünk van, csak épp értelmes nevet akarunk neki adni, akkor átnevezhetjük:

C:\Program Files (x86)\IIS Express>appcmd set site WebSite1(1) -name:Master
SITE object "WebSite1(1)" changed

Amire pedig nincs szükség, azt bátran törölhetjük:

C:\Program Files (x86)\IIS Express>appcmd delete site WebSite2
SITE object "WebSite2" deleted

 

Technorati-címkék: ,,

Egyedi ablak cím Visual Studioban

Aki gyakran indítja el a Visual Studiot egyszerre több példányban azért, hogy ugyanannak a projektnek több változatát különböző könyvtárakból nyissa meg, az gyakran bosszankodik azon, hogy sem a Visual Studio ablakának címsorában, sem pedig a Windows tálcán nem látszik, hogy ép melyik ágról van szó. Minden teljesen egyforma:

vs-rename-similar

Ezen segíthet a Rename Visual Studio Window Title bővítmény, ami a szülő könyvtárak neveit olyan mélységben szúrja be a címsorba, ahogy csak szeretnénk:

vs-rename-title

Persze ugyanez jelenik meg a tálcán is:

vs-rename-taskbar-branches

A megjelenés egészen jól testreszabható a beállítások között:

vs-rename-options

Apró, de hasznos eszköz.

 

Technorati-címkék: ,

Így varázsolsz biztonsági rést ASP.NET-ben

Az ASP.NET WebForms egyik óriási előnye, hogy villámgyorsan lehet vele adatelérési kódot varázsolni. Példaként vegyük a Northwind adatbázist, és legyen az a feladat, hogy csak az amerikai beszállítókat kell megjelenítenünk.

Dobjunk a Default.aspx-re egy GridView vezérlőt, majd állítsuk be szépen a Configure Data Source varázslóban, hogy a Suppliers táblából adja vissza… (kattints a teljes méretű képért)

PK-in-URL-1

… az USA-hoz tartozó beszállítókat:

PK-in-URL-2

Pofozzunk még annyit a GridView beállításain, hogy dobjuk le a SupplierID és a CompanyName oszlopokat, majd az utóbbit tegyük vissza, ám ezúttal HyperLinkField formájában. A link vezessen a (még nem létező) View.aspx oldalra, és query string paraméterben adjuk át neki a beszállító azonosítóját:

PK-in-URL-3

Készen is vagyunk, bátran ki lehet próbálni, íme az amerikai beszállítók listája:

PK-in-URL-4

Készítsük el a View.aspx oldalt, amire dobjunk egy DetailsView vezérlőt. Indítsuk el a Configure Data Source varázslót és kérjük le a Supplier rekord összes oszlopát…

PK-in-URL-5

…de csak abból a rekordból, amire a query stringben hivatkozunk, hiszen így kapcsoljuk össze a két oldalt:

PK-in-URL-6

Kitt és katt (Next és Finish) és máris készen van a működő oldalunk, amin a kiválasztott beszállító összes adatát át tudjuk tekinteni:

PK-in-URL-7

Működik? Igen, kiválóan lehet vele böngészni az USA-beli beszállítókat. Hurrá!

Hány sor kódot írtunk? Egyet sem, mert mindet a varázslók írták meg nekünk. Hurrá!

Van benne biztonsági rés? Van bizony! Elég átírni az URL végén lévő számot 2-ről mondjuk 4-re és máris hozzáférünk egy japán beszállító adataihoz, miközben nekünk csak az USA-ban lévőket szabadna látnunk:

PK-in-URL-8

Sőt, ha 1-től szép sorban minden számot kipróbálunk, akkor pillanatok alatt letölthetjük magunknak az összes beszállító adatait, azaz elvihetjük a teljes beszállítói kapcsolat adatbázist, az pedig már érték! Hurrá?

Ez történhet, ha az ember vakon megbízik egy varázslóban, vagy vakon követi valamelyik “hú-de-egyszerű-ez” demó lépéseit.

Most persze mondhatod, hogy a profik ilyet nem csinálnak. Pedig de, mondok is rögtön két példát.

Pár évvel ez előtt 114.000 iPad tulajdonos személyes adatait vitték el pillanatok alatt úgy, hogy egy URL-ben egyszerűen végigpróbálták a lehetséges eszköz azonosítókat (ICC ID – integrated circuit card identifier). Mindössze egy fél képernyőnyi szkript kellett hozzá és így került a címlapokra:

PK-in-URL-9

A biztonságcentrikus fejlesztéssel foglalkozók pedig így reagáltak rá:

PK-in-URL-facepalm-1

Ugyanezt a hibát később egy bank is elkövette. A Citibanktól – igen, egy banktól! – 200.000 ügyfél személyes-, folyószámla- és bankkártya adatait vitték el pont ugyanígy: csak átírták az ügyfél azonosítót az URL-ben. Erre aztán már nem csak a biztonsági szakemberek reagáltak így:

PK-in-URL-facepalm-2

Két rövid tanulság a fentiekből:

  • Ne tégy kitalálható azonosítót az URL-be!
  • Az eltitkolt URL nem védelem!

A varázslók a produktivitásban segítenek, de nem gondolkodnak. Egy biztonságtudatosan gondolkodó és a biztonságos programozás gyakorlatát követő fejlesztő bár valószínűleg lassabban kódol, hosszabb távon mégis kifizetődőbb.

 

Technorati-címkék: ,,,

Még egyszer a Windows és a Visual Studio verziókról

Korábban már röviden írtam arról, hogy az egyes Windows és Visual Studio verziók nem minden kombinációban szeretik egymást. Kis kiegészítés:

A Visual Studio 2012 (ha Windows 8-on vagy 8.1-en fut) továbbra is támogatja Windows Store alkalmazások készítését Windows 8-ra. Nem támogatja viszont Windows 8.1-re készülő Windows Store alkalmazások létrehozását vagy szerkesztését. A Windows 8-ra készülő alkalmazások tökéletesen működnek Windows 8.1 alatt is, csak éppen nem tudják kihasználni az új funkciókat, vagy a teljesítmény javulást.

A Visual Studio 2013 (amiből egyelőre a Preview érhető el), amennyiben Windows 8.1-en fut, támogatja Windows 8.1-re készülő Windows Store alkalmazások létrehozását és szerkesztését. Támogatja a Windows 8-ra készülő Windows Store alkalmazásokkal való munkát is, de olyan projekt sablonokat nem tartalmaz, amivel új, Windows 8-ra készülő projektet lehetne létrehozni. Ha viszont a Visual Studio 2013 Windows 8-on fut, akkor nem támogatja a Windows Store alkalmazások készítését, függetlenül attól, hogy az alkalmazás Windows 8-ra vagy 8.1-re készülne.

Ez várhatóan így marad a Visual Studio végleges változatával is.

Cserébe a jó hír, hogy a Visual Studio 2012 és a 2013 telepíthető egy gépre egymás mellé (side-by-side).

 

Technorati-címkék:

A VS 2013 preview-val csak Windows 8.1-re lehet fejleszteni?

Aki a Visual Studio 2013 új preview változatával Windows 8.1-en próbált meg létrehozni új Windows Store projektet, annak feltűnhetett, hogy a projekt neve mellett a Solution Explorer ablakban megjelenik a “(Windows 8.1)” jelzés:

vs2013-solution-explorer

A projekt tulajdonságait megnézve észrevehetjük a Target Platform Version opciót, azonban ezt nem lehet állítani:

vs2013-target-platform

Az az alapelv továbbra is igaz, hogy Windows 8-on lehet csak Windows Store alkalmazásokat fejleszteni, ám most már a verziókra is oda kell figyelnünk (legalábbis a mostani preview-nál biztosan).

A lényeg:

  • Létező Windows 8 projekteket meg lehet nyitni és lehet módosítani VS 2013-mal Windows 8.1-en.
  • Új Windows 8 projektet nem lehet létrehozni VS 2013-mal Windows 8.1-en.
  • Windows 8.1-en új Windows 8 projekt létrehozásához VS 2012-t kell használni.

 

Technorati-címkék: ,

Content Injector for ASP.NET MVC

Aki készített már újrafelhasználható elemeket ASP.NET MVC-ben, bizonyára találkozott már azzal a problémával, hogy egy partial view vagy egy HTML helper működéséhez szükséges egy CSS stíluslap vagy egy külső JavaScript fájl. Ha odafigyelünk a kódunk minőségére, akkor a CSS-t mindig az oldal tetején, a szkriptet pedig mindig az oldal alján töltjük be, gondosan ügyelve arra, hogy ezek a külső erőforrások akkor is csak egyszer töltődjenek be az oldalra, ha több helyen is szükség van rájuk. Viszont ezt csöppet sem egyszerű megoldani, hiszen a partial view-k és a HTML helperek teljesen önállóan, egymástól függetlenül renderelődnek. Bár a probléma egyáltalán nem újkeletű, még ASP.NET WebFormsban sem egyszerű megoldani, MVC-ben viszont kifejezetten nehéz.

Talán nem is meglepő, hogy a készre sütött megoldást Peter Blum tálalja nekünk a Content Injector for ASP.NET MVC formájában. Az öreg motoros ASP.NET fejlesztők már sokszor találkozhattak Peter nevével, aki egyszemélyes cégében leginkább ASP.NET web controlokat készít. Ezek közül a legismertebb a Peter’s Data Entry Suite, amely több, mint 100 WebForms vezérlőt tartalmaz, melyek elsősorban az adatbevitelt és a validációt teszik egyszerűbbé. Igen hasznos csomagról van szó, nem véletlenül kapott már értük számos pozitív értékelést.

Így csöppet sem csodálkoztam, amikor pár héttel ezelőtt Peter bukkant fel egy ötlettel az ASPInsiders listán, ami nagyon kényelmesen megoldja a fenti problémát. Sokan kipróbáltuk, kapott is pár visszajelzést, amit villámgyorsan át is vezetett a kódon, így most már bátran merem ajánlani a Content Injector for ASP.NET MVC projektet, leginkább NuGet csomag formájában.

A használata pofonegyszerű. Először is jelöljük meg az oldalunkon, tipikusan a Layout.cshtml fájlban, azokat a helyeket, ahova majd beszúródnak a tartalmak:

@Injector.InjectionPoint("ScriptFiles")

Ezek után ha például egy view-nak szüksége van a jQuery Validate szkript fájljaira, akkor a view-ból szúrjuk be őket a korábban megjelölt helyekre:

@Injector.ScriptFile("~/Scripts/jquery.validate.min.js");
@Injector.ScriptFile("~/Scripts/jquery.validate.unobtrusive.min.js");

Ez persze csak a legegyszerűbb használati eset, meg lehet adni még további paramétereket (például sorrend), valamint beszúrhatunk stíluslapot, szkriptet, meta tag-et, rejtett mezőt, szkript blokkot, vagy bármi mást, hiszen a rendszer jól kiterjeszthető és konfigurálható (például tracing). Minderről elég részletesen tájékoztat a 23 oldalas User’s Guide.

További érdekesség, hogy a visszajelzések alapján Peter összekapcsolta a Content Injectort a Microsoft Web Optimization Frameworkkel, így a ContentInjector.WOF NuGet csomag telepítése után már StyleBundle is ScriptBundle is beszúrható.

Letöltések:

 

Technorati-címkék: ,,

Forráskód source control mentesítése

Van úgy, hogy az ember egy source controlhoz (pl. TFS-hez) kapcsolt projektet source control nélkül szeretne megnyitni. Akár például azért, mert meg kellene osztani valakivel a kódot, aki nem fér hozzá a forráskódkezelő szerverünkhöz, vagy egyszerűen épp úgy akarunk garázdálkodni a kódban, hogy a source control kapcsolat csak zavarna. Persze a Studioban van Unbind lehetőség, de ahhoz, hogy odáig eljussunk, át kell verekednünk magunkat számos furcsa hibaüzeneten.

Én ilyenkor eddig mindig azt csináltam, hogy letöröltem a .vssscc és a .vspscc fájlokat, majd töröltem az Scc-vel kezdődő sorokat a projekt fájlokból, és csak ezek után nyitottam meg a projektet. Ez működő megoldás, de sok projekt esetén fájdalmas. Ezért is örültem nagyon, amikor Kovács Ferenc barátom figyelmembe ajánlotta a CodePlexen elérhető VS Unbind Source Control nevű eszközt, amivel mindezt egy csapásra elvégezhetjük parancssorból:

  VSUnbindSourceControl.exe W:\MyFolder