Visual Studio 2012 kategória bejegyzései

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