Category Archives: .NET 4 és Visual Studio 2010

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

Visual Studio asp:Localize snippet készítése

Az egyik projektünkben éppen többnyelvűsítünk, ami részben abból áll, hogy az ASPX oldalakban lévő statikus szövegeket pakolgatjuk ki resx fájlokba. A szövegeket asp:Localize vezérlővel akarjuk megjeleníteni, ami valójában egy Literal, abból származik és semmivel se tud többet, csak épp messziről ordít róla, hogy mire használjuk.

Egy idő után meguntam a gépelést és összedobtam egy code snippetet hozzá, hogy TAB-TAB-bal gyorsan be lehessen szúrni a lényeget, csak az erőforrás rekord nevét kelljen megadni. Íme a kód, amit egy .snippet kiterjesztésű fájlba kell bemásolni a C:\Program Files (x86)\Microsoft Visual Studio 10.0\Web\Snippets\HTML\1033\ASP.NET mappába, a Studio magától fel fogja ismerni:

<CodeSnippet Format="1.1.0" 
             xmlns="http://schemas.microsoft.com/VisualStudio/2005/CodeSnippet">
  <Header>
    <Title>localize</Title>
    <Author>Balássy György</Author>
    <Shortcut>localize</Shortcut>
    <AlternativeShortcuts>
      <Shortcut Value="localize">asp:localize</Shortcut>
    </AlternativeShortcuts>
    <Description>
      Markup snippet for a control that contains localized text
    </Description>
    <SnippetTypes>
      <SnippetType>Expansion</SnippetType>
    </SnippetTypes>
    <FileExtensions>
      aspx;master;ascx
    </FileExtensions>
  </Header>
  <Snippet>
    <Declarations>
      <Literal>
        <ID>key</ID>
        <ToolTip>key</ToolTip>
        <Default>key</Default>
      </Literal>
    </Declarations>
    <Code Language="html">
      <![CDATA[<asp:localize runat="server" meta:resourcekey="$key$" />$end$]]>
    </Code>
  </Snippet>
</CodeSnippet>

Egy-egy snippet pillanatok alatt megvan és utána sok gépeléstől kímél meg, megéri.

 

Technorati-címkék: ,

HTML postback ellenőrzés ASP.NET 4.0 és 4.5 esetén

Az ASP.NET az 1.1 verziótól kezdve tartalmaz alapszintű beépített védelmet a cross-site scripting (XSS) támadások ellen. Ezzel úgy szoktunk szembesülni, hogy HTML markupot próbálunk postbackelni, ami szerencsére elhasal a request validation védelmen ezzel a hibával:

System.Web.HttpRequestValidationException: A potentially dangerous Request.Form value was detected from the client

Persze erre többnyire szükség van, de néha – főleg WYSIWYG editorok esetén – mégis szeretnénk HTML kódot küldeni a szerverre.

ASP.NET 2.0 esetén a megoldás nagyon egyszerű volt, elég volt az adott oldalon a @Page direktívában a ValidateRequest=”false” beállítás. (Azt le se írom, hogy lehet az egész alkalmazásra kikapcsolni a web.config-ban.)

Az ASP.NET 4.0-ban viszont jelentős változtatások történtek, amit két módon szoktunk észrevenni:

  • Olyan helyeken is jön HttpRequestValidationException, ahol nem az oldal számára küldünk fel HTML adatokat, hanem cookie-ban vagy Ajax kérésben.
  • Hiába állítjuk át a ValidateRequest attribútumot a @Page direktívában, látszólag nem működik.

A változás lényege, hogy az ASP.NET 4.0 alapértelmezés szerint már nem csak a page számára küldött adatokat ellenőrzi, hanem a HTTP kérés minden részét. Mivel a korábbi @Page és web.config beállítások csak az oldalra vonatkoztak, ezért azok állítgatása már nincs hatással a 4.0 szerinti működésre.

Ha mégis szeretnénk egy oldalra kikapcsolni az ellenőrzést, akkor először a web.config-ban vissza kell állítani a működést 2.0 üzemmódra:

<location path="Admin/MyEditor.aspx">
   <system.web>
     <httpRuntime requestValidationMode="2.0" />
   </system.web> </location>

Ezek után a korábbi módon működik a ValidateRequest attribútum a @Page direktívában.

ASP.NET 4.5 újdonságok

Az ASP.NET 4.5 verzióban két fontosabb újdonság van: egyrészt finomabban hangolhatjuk, hogy mit szeretnénk ellenőriztetni, másrészt az ellenőrzést a platform alaposabb módon, az AntiXSS Library segítségével végzi el. A korábbi verziók legfőbb hiányossága az volt, hogy nem tudtuk mező szinten megadni, mely mezőket kívánjuk ellenőriztetni és melyeket nem (legalábbis WebForms esetén), azt pedig főleg nem, hogy mikor.

Ez most úgy változik, hogy az ellenőrzés alapértelmezés szerint (requestValidationMode="4.5") csak akkor és csak arra az adatra fut le, amikor a kódunk eléri a kérés adott részét. Ezt hívják késleltetett (vagy más néven lusta) ellenőrzésnek.

Az ellenőrzést immár kikapcsolhatjuk egyes vezérlőkre, mert a Control osztály kapott egy ValidateRequestMode tulajdonságot, ami ValidateRequestMode.Enabled, Disabled vagy Inherit értéket vehet fel.

Sőt, nem csak kikapcsolhatjuk az ellenőrzést, hanem meg is kerülhetjük azt. A HttpRequest osztály kapott egy csak olvasható Unvalidated tulajdonságot, amin keresztül egy UnvalidatedRequestClass példány formájában elérhetjük a kéréshez tartozó összes adatot (Cookies, Form, Headers, QueryString, Url stb.) anélkül, hogy az ellenőrzés beindulna. Ennek az az előnye, hogy a kódunk explicit módon kifejezi a szándékunkat, szó sem lehet véletlenről. Ekkor az ellenőrzést természetesen nekünk kell elvégeznünk!

 

Eltűnt item template-ek

Egyik napról a másikra eltűntek a Studioból az item template-jeim. Nem a sajátok, a gyáriak. Bármit akartam hozzáadni az Add New Item ablakban a projekthez, ilyen hibaüzenet fogadott:

Could not find file C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\ItemTemplatesCache\CSharp\Web\1033\WebForm.zip\WebForm.vstemplate.

És milyen igaz, valóban nincs ott olyan fájl, sőt az ItemTemplatesCache mappám szinte üres volt. De hogy mitől, a jóég se tudja.

A klasszikus megoldás ilyenkor a repair, de arra se időm, se szabad helyem nem volt, így végül az /InstallVSTemplates kapcsoló segített admin módban:

devenv.exe /InstallVSTemplates

 

Technorati-címkék:

Ingyen e-könyvek az MS Presstől

mspress_logo_145x90Az alábbi könyvek ingyenesen letölthetőek az MS Press oldaláról többnyire PDF, esetenként XPS, EPUB és MOBI formátumban is:

Ingyen és jogtisztán. Jó, nem?

 

Technorati-címkék:

ClickOnce érdekességek

Összességében szeretem a ClickOnce technológiát, mert jelentősen megkönnyíti a felhasználók életét, ezért is használjuk a VIK-en a záróvizsga jegyzőkönyv program telepítéséhez. Persze nem minden esetben ez a legjobb telepítőcsomag formátum, hiszen a testreszabási lehetőségek korlátozottak, de nekünk éppen megfelel. A héten – fél év után ismét – egy új verziót publikáltam volna a programból, de belefutottam néhány érdekességbe.

Nem lehet publikálni

Az új verziót a következő módon szoktam elkészíteni: Project Properties –> Publish –> Verziószám beállítása –> Publish Wizard, mert így tudom legjobban kézben tartani, hogy mi történik. De most erre ezt az üzenetet kaptam:

Error: Cannot publish because a project failed to build.

Az Output ablakban semmi több, ennyiből kell főznünk. Hát, ha balról nem engedi a ló, hogy felszálljunk rá, próbáljuk jobbról: Solution Explorer –> jobb klikk a projekten –> Publish. Így megy, csodálatos! 🙂

Lejárt a tanúsítvány

Amikor már azt hittem, hogy sínen vagyunk és csak egy Visual Studio bugba sikerült belefutnunk, szembejött az alábbi érdekes hiba:

The signer’s certificate is not valid for signing.

Ejha, ennek a fele sem tréfa, nézzük csak meg azt a tanúsítványt. Irány a Project Properties ablak, azon belül is a Signing (nem a Publish!) fül. Íme az aláíró tanúsítvány:

clickonce-certificate

Igen, ez a Visual Studio által generált önaláírt tanúsítvány, amire nincs mentség, csak kifogások, nem volt más választásunk. Szemmel láthatóan ez valóban lejárt, tehát itt valamit tenni kell. Van ezen az ablakon egy Create Test Certificate gomb, amivel simán generálhatok új tanúsítványt, de annak következményei vannak. Először is jön ez az üzenet:

The application is signed with a different key than the existing application on the server. Do you want to overwrite it?

Amire mondhatjuk, hogy naná, de az MSDN szerint akkor bizony a régi felhasználóink nem fogják megkapni a frissítést. Ez a mi esetünkben semmiképpen sem elfogadható, más megoldás kell. Elvileg .NET 4 esetén ez már nem probléma, mégsem akartam kockáztatni.

Valahogy tehát meg kellene hosszabbítani a létező tanúsítványt, amihez a KB925521 cikkben találunk is útmutatást, egy rakás .cpp kód formájában. Cliff Stanford oldaláról letölthető egy lefordított RenewCert verzió, ami nálam a C runtime library-kre hivatkozva elszállt, de szerencsére Robin Shahan blogjában találtam egy olyan változatot, ami mellett ott állnak a szükséges dll-ek is. Ezzel egy csapásra sikerült meghosszabbítani a korábban használt tanúsítványt és gond nélkül működik a frissítés. 5 évig.

 

Real World .NET, C#, and Silverlight: Indispensible Experiences from 15 MVPs

image 1

Örömmel jelentem, hogy kézzelfogható bizonyítékát kaptam annak, hogy megjelent a Wroxnál a Real World .NET, C#, and Silverlight: Indispensible Experiences from 15 MVPs c. könyv. Számomra azért különleges ez a könyv, mert ez a második angol nyelven, külföldön megjelent könyv, aminek a szerzője, pontosabban társszerzője voltam.

Ez a könyv azért egyedi, mert nem egy témával foglalkozik, hanem többel, konkrétan tizenöttel:

“Written by a group of experienced MVPs, this unparalleled book delves into the intricate—and often daunting—world of .NET 4. Each author draws from a particular area of expertise to provide invaluable information on using the various .NET 4, C# 4, Silverlight 4, and Visual Studio tools in the real world.”

Nagyon jó csapat állt össze, mert minden fejezetet egy Most Valuable Professional címmel rendelkező szerző írt, mégpedig a kedvenc témaköréből:

  • David Giard: ASP.NET and jQuery
  • Bill Evjen: ASP.NET Performance
  • György Balássy: Ethical Hacking of ASP.NET
  • Gill Cleeren: How to Build a Real-World Silverlight 5 Application
  • Jeremy Likness: Silverlight — The Silver Lining for Line-of-Business Applications
  • Daron Yöndem: Tips and Tricks for Designers and Developers
  • Kevin Grossnicklaus: MVVM Patterns in Silverlight 4
  • Alex Golesh: Windows Phone "Mango" for Silverlight Developers
  • Christian Weyer: Pragmatic Services Communication with WCF
  • Dominick Baier: Securing WCF Services Using the Windows Identity Foundation (WIF)
  • Jeffrey Juday: Applied .NET Task Parallel Library
  • Vishwas Lele: The WF Programming Language
  • Christian Nagel: Practical WPF Data Binding
  • Scott Millett: Driving Development with User Stories and BDD
  • Caleb Jenkins: Automated Unit Testing

Az eredeti csapatban Velvárt András barátom is benne volt, de a 15 szerző koordinálása miatt sajnos lassan készült a könyv, így végül Bandi a SilverlightShow-n publikálta a fejezetét Windows Phone 7 for Silverlight Developers címmel e-book formájában.

A könyv az Amazonon november vége óta kapható, de a szerzői tiszteletpéldányok csak most érkeztek meg Magyarországra (az amerikai szerzők már decemberben megkapták), így én is csak most tudtam végignézni a többiek témáját, amik között nem egy nagyon hasznosat és érdekeset találtam. A vegyesfelvágottnak köszönhetően szerintem mindenki talál a könyvben a szívéhez közel álló fejezetet.

Jómagam Ethical Hacking ASP.NET címmel az ASP.NET platformban rejlő olyan biztonsági gyenge pontokról írtam, amelyek minden ASP.NET-es alkalmazást sebezhetővé tesznek bizonyos támadások ellen. Aki eljön a szerdai bemutatóra, kaphat belőle egy kis ízelítőt. Akihez pedig eljut a könyv, kérem küldjön visszajelzést, hogy hasznosnak találta-e a leírtakat.

 

Technorati-címkék: ,,,,

Új év, új .NET. Vagy mégsem?

BUÉK! Aki belegondolt már abba, hogy mi minden várható az idén a Microsofttól, annak biztos ott szerepel a lista elején az új .NET. Lesz új Visual Studio, új C# és új .NET Framework, ami a keresztségben a 4.5 verziószámot kapta. Hogy miért éppen 4.5? Mert a DevDivnél az a szokás, hogy:

  • új CLR –> major verziószám változás (pl. 4.0)
  • javított CLR és új könyvtárak –> minor verziószám változás (pl. 4.5)
  • javítások és apróbb kiegészítések –> revision verziószám változás (pl. 4.0.2)

Márpedig az új verzióban lesznek javítások és újdonságok is, ezért lett épp 4.5. Kár, hogy semmit nem fogunk látni ebből.

Az új verzió ugyanis felülírja a régit hasonlóan, mint ahogy a 3.5 és a 3.5 SP1 felülírta a 2.0 verziót. In-place update. Ez önmagában nem is lenne igazán nagy gond, ami viszont nagyon fáj, hogy a verziószám marad a régi. Igen, pont ugyanaz:

“One of the first things you’ll notice about .NET 4.5 is the version number (4.0.30319) is the same as .NET 4; this is the practice used by other in-place updates.”

Magyarul jön az új Framework, valaki feltelepíti és utána az összes 4.0-ra írt alkalmazás kénytelen lesz azt használni. Ez van, nincs választási lehetőség, nesze, íme, újabb, szebb és jobb.

(Őszintén szólva ennek hallatán az első kifejezés, ami eszembe jutott, a DLL-hell volt, pedig mióta van korrekt Windows Installer és a .NET 2.0-nál elmondtuk, hogy milyen jó a side-by-side telepítés, ezt a fogalmat nyugodtan száműzhettem az életemből.)

Jobban belegondolva még az azonos verziószám sem lenne gond, ha nem lennének breaking change-ek és kompatibilitási problémák. Biztos vagyok benne, hogy az MS nagyon komolyan veszi ezeket az eseteket, nem is tehetik máshogy:

“Our primary concern is guaranteeing applications you use do not break after you install .NET 4.5. We accomplish this by running hundreds of application in our compatibility lab to find issues as soon as they’re introduced. While designing new features or changing existing code, we keep compatibility in mind. And a small group of us, the Developer Division Compatibility Council (DDCC), monitor changes made by developers. We review potential breaking changes, and help teams understand and assess the compatibility impact of new features and bug fixes. For .NET 4.5, members of DDCC reviewed every proposed breaking change, every new feature, and a majority of the bug fixes for the release.”

Persze azt ők is beismerik, hogy nagyon nehéz tökéletes munkát végezniük:

“We’ve put a lot of effort into maintaining a consistently high bar for compatibility across the product, yet we know some issues may get past us. Many applications will exercise the .NET Framework in ways that we did not expect or we lack test coverage for. Still we care about knowing every issue, even those that may seem like corner cases.”

Ha valamelyik alkalmazásunk megpurcan az új frameworkön, akkor lehet a Connecten jelenteni a hibát – és majd lesz valami.

A legszomorúbb az egészben az, hogy a technológia képes lenne a side-by-side működésre, nekünk mégsincs választási lehetőségünk. Valamilyen elvtől vezérelve eldöntötték Redmondban, hogy márpedig in-place upgrade lesz. Tehát ha egy szerveren egy alkalmazás miatt szükség van a 4.5 verzióra, akkor azon a szerveren a telepítés után minden 4.0 alkalmazás a 4.5 verzión fog futni. De ki fogja tudni garantálni, hogy a korábbi alkalmazások teljesen jól működnek az új frameworkkel? A legtöbb esetben senki, vagy csak jelentős munka árán. Mivel az üzemeltető nem fog ilyen kockázatot (vagy munkát) vállalni, nem fogja engedni a 4.5 verzió telepítését, mert fél, hogy a korábbi jól működő rendszerek megborulnak tőle. Üzemeltetőként én sem vállalnám, oda a bizalom. A Microsofttal szemben is és a fejlesztők felé is.

Szerintetek ez jó így?

Technorati-címkék:

Projektenként eltérő kódformázási beállítások a Studioban

A Visual Studio egyik kiváló szolgáltatása, hogy segít nekünk megformázni a forráskódot, mégpedig olyanra, ahogyan mi szeretnénk. Irány a Tools > Options > Text Editor beállítások, ahol kedvünkre kapcsolgathatunk (katt a teljes képért):

Visual Studio Text Editor beállítások

Az így összeállított beállításainkat exportálhatjuk, majd később importálhatjuk más gépen vagy éppen megoszthatjuk másokkal. Ehhez van egy Import and Export Settings varázsló a Tools menüben:

Import and Export Settings varázsló

A bökkenő ezzel csak az, hogy ez felhasználónkénti beállítás, és nem projektenkénti. Azaz ha több projekten is dolgozunk, ahol más a kódformázási standard, akkor bajban vagyunk, mert a beállítások hozzánk kötődnek és nem az egyes projektekhez.

Nem vagyok egyedül ezzel a problémával, már más is felvetette, és itt lehet szavazni, hogy megoldódjon a következő Studioban: http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/2089769-store-per-project-source-formatting-settings-with-

Szerencsére a devenv.exe-nek van egy /ResetSettings parancssori kapcsolója, ami után megadhatjuk a használni kívánt és korábban az export varázslóval létrehozott .vsssettings fájl nevét és elérési útját. Nincs más hátra, minden különböző beállításhoz létre kell hozni egy-egy önálló parancsikont:

Visual Studio indítása ResetSettings kapcsolóval

A dolog működőképes, de nem olyan kényelmes, mint ahogy szeretnénk:

  • A Studio lassabban fog elindulni, gyakorlatilag a háttérben lenyomja az import varázslót. Ez nem gond, ha naponta egyszer indítjuk el, de ha gyakran, akkor zavarni fog.
  • A saját parancsikonnal elindított Studio beállításai lesznek “A Studio beállítások” a gépen (pontosabban az aktuális felhasználónál), azaz ha utána bármikor, bárhogy (Start menüből, .sln fájlra kattintva) indítunk egy Studiot, akkor az utoljára importált beállítások lesznek érvényben. Nincs automatikus visszaállás a gyári értékekre.
  • Le kell szokni arról, hogy az .sln fájlra kattintva nyitjuk meg a forráskódot, hiszen akkor az utoljára importált beállítások lesznek érvényben. Tehát a kötelező ügymenet ezek után mindig az, hogy először elindítjuk a Studiot a  projekt saját parancsikonjával, majd a menüből megnyitjuk a projekthez tartozó solutiont.

Tudtok jobb megoldást?

 

Technorati-címkék:

Visual Studio Database project költöztetése SQL Azure-ra

Nagyon régóta használjuk Visual Studioban a Database project típust, mert nagyon szépen lehet vele kezelni és TFS alatt verziózni az adatbázis objektumokat. Mivel bevált és szeretjük, természetesen ezt használtuk a HTML5 Játéktér fejlesztésekor is, a táblák, elsődleges és idegen kulcsok, kényszerek, indexek, a mezők alapértékeinek és a törzsadatoknak a tárolására. Az üröm az örömben, hogy történeti okokból ez a projekt típus még nem támogatja közvetlenül az SQL Azure-t, így nem lehet az elkészült adatbázist és a szükséges adatrekordokat közvetlenül a felhőbe telepíteni.

Szerencsére van megoldás, az alábbi videóban meg is mutatom, hogyan költözik fel a Studioból az adatbázis az SQL Azure-ra:

720p, teljes képernyős nézet ajánlott

Ráadásként az is kiderül, hogyan lehet a fejlesztés során használt tesztadatokat opcionálisan telepíttetni a kimeneti szkripttel.