öt perc dotnet

Join Me!

2010-07-30T12:47:00.000+02:00

A Gizmodo úgy definiálja, hogy "hihetetlenül egyszerű, biztonságos online kollaborációs tool". Magam se mondhatnám szebben.
Ha gyorsan össze kell rántani egy gyors meetinget a szomszéd városban / országban / földrészen tartózkodó kollégával, vagy egyszerűen csak anyu gépét kéne hirtelen megadminisztrálni, mindemellett nincs szakértelem / lehetőség / kedv portot nyitogatni, installálgatni, mondd csak egyszerűen, hogy "join.me", és kész.

A kommentelés művészete

2010-07-29T17:20:00.000+02:00

http://stackoverflow.com/questions/184618/what-is-the-best-comment-in-source-code-you-have-ever-encountered

Entity Framework Feature CTP4

2010-07-16T09:33:00.000+02:00

Itt van, megjött. Csak távirati stílusban:

http://blogs.msdn.com/b/adonet/archive/2010/07/14/ctp4announcement.aspx

http://blogs.msdn.com/b/adonet/archive/2010/07/14/ctp4codefirstwalkthrough.aspx

http://blogs.iis.net/shanselman/archive/2010/07/14/simple-code-first-with-entity-framework-4-magic-unicorn-feature-ctp-4.aspx

TechNet magazin archívum

2010-07-09T11:14:00.002+02:00

Egy régebbi poszt hozzászólásaiban merült fel, hogy elérhetők-e a TechNet magazin régebbi számai valahol. Van ugye a hivatalos oldal, ahol az újabb (értsd: 2005-2008 közötti) számok elérhetők.

Többnyire.

A régebbiek viszont (megint csak többnyire) nem működnek, sajnos. Pedig ezekben a számokban is sok olyan cikk van, amit ma is szívesen a kezébe venne az ember - vagy azért, mert a tartalma ma is releváns (mint a fent említett posztban kivesézett garbage collector, de a T-SQL, vagy az XML technológiák alapjai se sokat változtak 2000 óta), vagy mert egyszerűen nosztalgikus érzés az IIS 5 finomhangolásáról, vagy a .NET 1.0-ról olvasgatni. Nosztalgiázni pedig szeretünk.

Mit gondolt Bill Gates a .NET technológiáról 2000 októberében? Érdekel, mi? Hát innen nem tudod meg, az biztos.

Így most Szolgálati közlemény következik: elő az !archive könyvtárakkal, foszladozó szélű írott CD-kkel, 2GB-os IDE33-as merevlemezekkel! Akinek megvannak ezek a régi számok, kérem, jelentkezzék!

IIS Express

2010-06-29T10:40:00.000+02:00

Mi mást is mondhatnék: http://weblogs.asp.net/scottgu/archive/2010/06/28/introducing-iis-express.aspx

Stílusrendőrség

2010-06-23T15:09:00.000+02:00

A különbőző névadási, kódolási konvenciók betartása létfontosságú, ha ugyanazon a codebase-en többen is dolgoznak. Más kódjának megértése amúgy se tartozik a legtriviálisab feladatok közé, ha pedig még a "közös nyelv" sincs meg, akkor igazi PITA. Egy baj van a dologgal, hogy a betartatása igazi robotmunka - akkor viszont nosza, csináltassuk robotokkal!

Több tool is elérhető a témakörben, például az FxCop, ami a már lefordított assembly-t elemezve ömleszti ránk a jótanácsokat, de ma nem róla lesz szó, hanem a testvéréről, a StyleCop-ról. Ő a forráskódot analizálja, ennélfogva némileg más szempontok szerint tudja segíteni a munkánkat.

Csináltam egy gyors teszet: letöltöttem az install .msi-t, a Visual Studio-ban csináltam egy új konzol alkalmazást, és az automatikusan legenerált alkalmazás-vázat egy magas színvonalú "Hello, World!" applikációvá bővítettem ki:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace StyleCopTest
{
    class Program
    {
        static void Main(string[] args)
        {
            Console.WriteLine("Hello, StyleCop!");
        }
    }
}

Ezután elindítottam a Tools menübe beépülő StyleCop-ot (Run StyleCop), ami megvizsgálta a kódot, és a standard Error list ablakban (amiben a fordításkor az Error-ok, Warningok jelennek meg), néhány Warning képépben materializálódott a végeredmény.

Ezután átszabtam úgy a kódot, hogy megfeleljek az alapból beállított szabályok mindegyikének.

Ezek között voltak olyanok, amikkel nagyon egyetértettem (pl. minden osztályon, metóduson legyen XML komment), valamire azt mondtam, hogy hát végülis jó, legyen (mindenképp legyen kiírva az access modifier az class-ok elé), valamit kimondottam furcsálltam (a using-okat hozzuk be a namespace alá).

A file elejére egy copyright note-ot reklamált, amit saját kútfőből nem is tudtam összehozni, szerencsére az adott warning kódja (SA1634) alapján a SyleCop doksiból kiderült, hogy pontosan milyenre vágyik. Végül ez lett a "Hello, StyleCop!" alkalmazásból:

// <copyright file="Program.cs" company="Öt Perc DotNet">
//      Copyright (C) 2010 http://otperc.net
// </copyright>

namespace StyleCopTest
{
    using System;
    using System.Collections.Generic;
    using System.Linq;
    using System.Text;

    /// <summary>
    /// A summary for the Program class.
    /// </summary>
    internal class Program
    {
        /// <summary>
        /// A comment for the Main method.
        /// </summary>
        /// <param name="args">A comment for the args parameter.</param>
        public static void Main(string[] args)
        {
            Console.WriteLine("Hello, StyleCop!");
        }
    }
}

Szerencsére ott, ahol nem értünk egyet beépített stílusrendőrünkkel, ott lehetőség van a konfigurálásra, vagy akár új szabály létrehozására. A StyleCop a build folyamatba is bepíthető, így akár automatikus visszajelzést kaphatunk, ha valaki a csapatunkból partizánakciókba kezd kódolási stílus terén.

Kínzó kérdés

2010-06-15T12:53:00.000+02:00

Az miért van, hogy lézernyomtatóból tudnak csinálni

fekete-fehéret,
színeset,
fénymásolósat,
scannelőset,
faxgépeset,
egyoldalas-nyomtatósat,
kétoldalas-nyomtatósat,
n-oldalas-nyomtatósat,
összefűzőset,
szétvágósat,
dokumentum-megőrzőset,
dokumentum-megsemmisítőset,
százezer forintosat,
egymillió forintosat,
tízmillió forintosat,

csak olyat nem, aminek ne kéne a papírtálcát minden második nyomtatás előtt ki-be rángatva a tudtára adni, hogy "nem, nem barátom, higyjed el, hogy van még papír abban az átkozott adagolóban, esküszök!".

Olvasóink küldték rovat

2010-06-11T16:16:00.000+02:00

"Névtelen" olvasónk kommentjében érkezett a következő "mit ír ki" rejtvény:

Console.WriteLine("{0}");
Console.WriteLine("{0}", "{0}");

Én ezt még ennyivel megfejelném:

Console.WriteLine(string.Format("{0}"));
Console.WriteLine(string.Format("{0}", "{0}"));

A kérdést már fel se teszem

2010-06-11T09:37:00.000+02:00

object o1 = true;
object o2 = true;
Console.WriteLine(o1 == o2);

GMail "plusszos címzés"

2010-06-10T11:04:00.000+02:00

Tudják mi az email címem?

Hát gerely+1@mail.com. Vagy gerely+2@gmail.com. Vagy gerely+akarmi@gmail.com.

A gmail ugyanis figyelmen kívül hagyja a usernévben a "+" jel mögötti rész, a levél így is megérkezik a postafiókba. A "figyelmen kívül hagyja" nem is teljesen pontos, mert cízett (To:) mezőben ott lesz, tehát ez alapján tudunk címkézni, filterezni.

Akkor is nagyon jól tud jönni ez a feature, ha pl. egy regisztrációs folyamatot tesztelünk, ahol mindig egyedi email címeket kell megadni, de érthető okokból nem szeretnénk 1000 postafiókot létrehozni...

További trükközésre nyílik lehetőseg a névben elhelyezett pont karakterrel.

Részletek a GMail Blog-on: http://gmailblog.blogspot.com/2008/03/2-hidden-ways-to-get-more-from-your.html

Megmondom mit ír ki

2010-06-10T09:37:00.001+02:00

A tegnapi kérdés megoldása: False, True... Gondolhattátok volna? :) Hehehe. Na de miért, az a nagy kérdés, azt is megmondom.

Szóval a második összehasonlítás értéke nem azért True, mert mindkét string "true", illetve azért, csak nem úgy, hanem... ehh. Kezdjük az elejéről.

A .NET-ben a string immutable, ami annyit tesz, hogy az értéke sosem változhat meg. Egyszer értéket adsz neki, úgy marad. A különböző sztring-mogyorózó műveletek is (.Replace(), .Substring(), .Trim(), stb), bár példány-metódusok, nem az adott példány állapotát változtatják meg, hanem egy új string példányt adnak vissza.

Nézzük példaként az alábbi kódot:

object o1 = "true";
object o2 = "true";
Console.WriteLine(o1 == o2);

Itt mind az első, mind a második sorban leírt sztring-konstans értéke "true", és az is marad, megváltoztathatlanul, örökre. De akkor minek kétszer tárolni, ha úgy is ugyanaz mindkettő, és nem lehet változtatni rajta?

Nos, nem kell kétszer tárolni, sőt, ami a legjobb, ezzel a spórolással nekünk nem is kell törődni, mert a .NET CLR automatikusan megteszi helyettünk. Csak egy darab "true" értékű string példány fog létrejönni, és mind az o1, mind az o2 referencia rá fog mutatni. Így o1 egyenlő lesz o2-vel - de ehhez az egyenlőség-vizsgálathoz már nem sok köze van a "true" stringnek, az összehasonlítás azt figyeli, hogy referenciálisan egyenlőek-e ("ugyanoda mutatnak-e", mondaná az unmanaged világ).

Ebben a kódban viszont a StringBuilder .ToString()-je "bekavar", nem az intern pool példányát fogja visszaadni, hanem egy újat, így ez az o1 ami nem lesz referenciálisan egyenlő a o2-vel:

object o1 = new StringBuilder("true").ToString();
object o2 = "true";
Console.WriteLine(o1 == o2);

Mit ír ki?

2010-06-09T17:43:00.000+02:00

Kód, szöveg nélkül:

var sb = new StringBuilder("true");
object o1 = sb.ToString();
object o2 = "true";
Console.WriteLine(o1 == "true");
Console.WriteLine(o2 == "true");

Az [Obsolete] attribútum esete a #pragmával (és sok más érdekes)

2010-06-03T19:12:00.015+02:00

Adott a szituáció, hogy van egy metódus a kódunkban, ami elavult, régi, legacy, azóta van jobb, azt kéne használni, a régit pedig nem kéne hívni. A legegyszerűbb lenne egyszerűen kidobni, de sajnos nem lehet, mert van néhány szintén elavult, régi, legacy kód, ami hívja, és azokhoz nem akarunk / tudunk hozzányúlni.
Mindenképp szeretnénk viszont biztosítani, hogyaz újonnan íródó kódok már az új metódust használják. Milyen módszerek vannak?

Írunk egy emailt mindenkinek, hogy használja az új metódust - ez EPIC FAIL.
A metódus XML kommentjében (ugye minden metóduson van?) jelezzük, hogy ne használd, és miért ne használd, és mit kell használni helyette - eggyel jobb, sőt, kiegészítő megoldásként kimondottan jó ötlet.
Megjelöljük az [Obsolete] attribútummal. - na, ez az, ez kell nekünk, az ultimate, überfrankó megoldás!

Az Obsolete attribútummal megjelelölt metódusok fordításakor a fordító egy warning-ot generál, ami remélhetőleg fel fog tűnni a fejlesztőnek a build output-ban.

Remélhetőleg - de messze nem biztos. Sokat segít, ha egyébként nem vagyunk tele warningokkal - azok sokszor amúgy is inkább error-ok, mint warningok - de még akkor sem hundert Prozent.

Van ugyan egy overload-ja az Obsolete attribútumnak, ahol egy bool paraméterben megmondhatjuk, hogy ne warning-ot, hanem error-t generáljon az elavult metódus hívásakor - azt már csak észreveszi a fejlesztő, hogy nem fordul a kódja.
Van viszont egy hátulütője is ennek a megoldásnak: az a régi, legacy kód sem fog fordulni, amit viszont nem akarunk átírni az új metódus használatára. Ennyi erővel ki is hajinthatnánk az elavult metódusunkat, úgy se lehet hívni sehogy (bár reflection-nel pl. lehet, de egyelőre maradjunk a keresztény kultúrkörben).

Meg egyébként is, ne bolygassuk a múltat, minden maradjon a régiben, ne jöjjenek mindenféle warningok, csak ha valami új kód próbálná hívni az elavult metódust, csapjon a fejlesző kezére a Visual Studio!
Maradjunk tehát az [Obsolete] annál az overload-jánál, ami nem dob hibát:

[Obsolete]
static void OldMethod()
{
    Console.WriteLine("Don't call me!");
}

static void Main(string[] args)
{
    OldMethod();
}

Ha ezt így lefordítjuk, egy "'OldMethod()' is obsolete" warningot kapunk. Tegyük fel, hogy ez az a pont, ahol a régi kód hív, tűntessük el a warningot:

static void Main(string[] args)
{
    #pragma warning disable 612
    OldMethod();
    #pragma warning restore 612
}

Megjegyzés: ha az Obsolete-nek azt az overload-ját használjuk, ami saját üzenetet ír ki, akkor nem 612-es, hanem 618-as kódú warning generálódik!

Eddig remek. Most már csak azt kéne elérni, hogy a Visual Studio egy warning-nál erőteljesebben hozza a tudomásunkra, ha olyat próbálnánk hívni, amit nem kéne.
Nosza, vegyük rá, hogy ezeket a warningokat hibaként kezelje! A projektünk properties ablakában, a build fül "Treat warnings as errors" szekcióban pont ezt tehetjük meg:

Ezzel el is értük, amit akartunk: a világ ismét megmenekült a pusztulástól.
Viszontlátásra.

C# Sealed Method

2010-05-28T10:37:00.003+02:00

Tudta ön, hogy meg lehet akadályozni egy virtuális metódusnál, hogy a mi override-unkat később, egy a mi implementációnkból öröklő új osztály felülírhassa? Erre szolgál a sealed method.
Azért az vicces, hogy így 5-6 év után is tud újat tanulni az ember.

Állásajánlat: vezető konzulensek

2010-05-26T07:49:00.003+02:00

Újra állásajánlat: három fő vezető konzulens kerestetik, az alkalmazásfejlesztés, SharePoint, illetve infrastruktúra területekre.

A feladat mindhárom esetben részvétel a tervezésben, implementálásban, nagyvállalati környezetben történő bevezetésben, a projektekkel kapcsolatos tevékenységek végrehajtása (projekt menedzsment, projekt adminisztráció, ügyfél kapcsolattartás), a projektek technikai támogatása - természetesen az adott szakterületnek megfelelő projektekben. Ennek megfelelően a szükséges kompetenciák is eltérőek: alkalmazásfejlesző konzulensként a .NET / C# / SQL ismeretek (SharePoint, BizTalk előny), SharePointosként természetesen SharePoint, infrastruktúrásként pedig AD, Exchange, ISA ismeretek elvártak.
Közös viszont, hogy az adott szakterületen több éves tapasztalattal és angol nyelvtudással kell rendelkezni.

Az érdeklődők leveleit Balogh Edina várja.

Na, és ez egy vagy kettő?

2010-05-14T15:45:00.001+02:00

Népszerű volt az "Egy vagy kettő?", úgyhogy jöjjön egy újabb egy vagy kettes kérdés:

int i = 1;
i =+ 1;
Console.WriteLine(i);

Egy vagy kettő?

2010-05-12T23:49:00.001+02:00

public int GetInteger()
{
    int result;
    try
    {
        result = 1;
        return result;
    }
    finally
    {
        result = 2;
    }
}

Senior C# fejlesztő, vezető fejlesztő kerestetik

2010-05-12T17:47:00.003+02:00

Ha valami számomra szimpatikus állásajánlattal keresnek meg, de nekem épp nem aktuális az álláskeresés, akkor publikálni szoktam azokat itt a blogon. Most is ez a helyzet, több senior fejlesztőt is keresnek egy neves multinacionális céghez (rádásul dolgozik ott ismerősöm, akitől jókat hallottam a helyről).

Több pozícióról van szó, így követelményekről csak általában: erős C# / .NET ismeretek, valamint - multiról lévén szó -, a használható angol alapfeltétel, ezen felül aztán pozíciótól függően SQL ismeretek, Java, C++ tapasztalat, team leaderi, project manageri tapasztalat / ambíció az, ami feltételként vagy előnyként szóba jöhet.

Akit érdekel a dolog, Cseh Orsolyától további információt kaphat.

"Paste as Unformatted text" hotkey a Word-ben

2010-04-30T11:02:00.001+02:00

Na akkor innen ebből a HTML doksiból copy, ebbe a Word-be paste... pfff... ez nagyon gányul néz ki.

A copy&paste képes átvinni a formázást is - ez néha jó, néha meg nem. A megoldás a Paste Special -> As Unformatted Text.
Amit, ha sokszor használunk, elég idegőrlő mindig a menüből előhalászni, szerencsére ennek a leírásnak a segítségével néhány egyszerű lépésben kalapálhatunk magunknak hozzá hotkeyt. Nálam most CTRL+SHIFT+V, remekül működik.

Caching in .NET 4.0 - System.Runtime.Caching

2010-04-27T00:38:00.003+02:00

Mikor a .NET Framework 4.0 még csak pre-béta állapotban volt, és a leendő újdonságokról csak a legjobban értesült piaci kofáktól lehetett némi információhoz jutni, közismert volt a tény: a caching háza táján muszáj lesz rendet vágni. Egyrészt, nagy szükség lenne egy eloszott cache-re - ez AppFabric Cache (született: Velolcity) néven cirka másfél éve a "még 1-2 hónap, és itt a relese!" állapotban van (de legalább van, és elég ígéretes).

In-process, objektum alapú cache pedig mindig is volt a .NET Frameworkben - viszont volt volt vele egy apró gond: eredetileg webalkalmazások gyorsítására szánták a keretrendszer tervezői, így - bár technikailag egyáltalán semmi akadálya nem volt, hogy ASP.NET alkalmazásokon kívül is használhassuk - mégis, ez a megoldás, mondjuk ki nyílt proletár őszinteséggel: meglehetősen bénácska volt.

A leggyakoribb ellenvetések azok voltak, hogy egyrészt, milyen már, hogy a System.Web assemblyt be kell referenciálni egy olyan alkalmazásba, aminek nem sok köze van a webhez, másrészt, ez a cache implementáció nagyon sok "beégetett" dolgot tartalmazott, konkrétan nem igazán lehetett bővíteni, testre szabni sehogyan sem.
Erre már a 4.0 első bétáiban körvonalazódott a megoldás: egy vadi új object cache implementáció, ami meglehetősen jól kusztomizálható, sőt, mi több: a System.Web.Cachig-et is átdolgozzák, pontosabban az implementációt kihajítják, a régi API pedig csak egy proxy, egy kompatibilitási réteg lesz az új cache fölött a legacy alkalmazások számára, hogy a kompatibilitás megmaradjon.

Most alaposan megreflektoroztam mind a régi, mind az új cache-t, és hát mivel nem vagyok a szavak embere, inkább idézném a Hooligans zenekar örökbecsű számát, ami a System.Web szerelvény 4.0-ás verziójában található cache implementációról írtak:

Hiába kéred, nem változom meg
Ilyen vagyok, más nem leszek
Ne szólj rám, ne változtass meg
Nem akarom, hogy irányíts, nem engedem

Nem akarom, hogy azt hidd, jobb lettem
Mert egy nap neked mindent megtettem
Bennem minden a régi, te rólam mást hittél
Mert a vér nem válik, a vér nem válik vízzé

Na szóval ez kurvára ugyanaz, mint a régi. Emelett persze van új is, ami azt jelenti, hogy .NET 4.0-ban két (perverzeknek akár) párhuzamosan használható object cache implementációt találhatunk. Hogy miért, arról a legviccesebb magyarázatként azt olvastam, hogy a régi az webre optimalizált, ami hát nekem laikusként oltári nagy hülyeségnek tűnik, valószínűleg egyszerűen a marketing ügyosztály szeretett volna mindenképp valamilyen jól hangzó választ kidolgozni arra a kérdésre, hogy na de mégis, miért??, és ennél jobb sehogy nem jutott eszükbe.
Inkább tippelnék arra, hogy az API-k annyira különböztek, hogy túlságosan sok kompromisszumot kellett volna megkötni a régi implementáció kidobásához, egy komolyabb breaking change behozása pedig nagyon nagy nyűg lenne azok számára, akik az eddigi cache implementációt használták. Ők pedig sokan vannak, ráadásul jellemzően nem is a a Pince 2000 Bt. kategória, inkább nagy forgalmú, komoly üzleti értéket képviselő portálok, ahol az üzemeltetés amúgy is könnyen agybuborékot kaphat az ötlet hallatán, hogy alattuk most cache implementációt fognak cserélni, de jobb lesz sokkal, esküszök.

Hogy jobb lesz-e vagy sem, arról ne higgyünk az égvilágon senkinek, próbáljuk ki inkább magunk. Hozzunk létre egy új konzol alkalmazást (vagy webest / WinFormsost, ami szívünkhöz közel áll), és referenciáljuk be a System.Runtime.Caching.dll-t. Ebben lakik az új cacheing. Using-oljuk be az azonos nevű névteret: ez alatt találjuk az új cache implemtáció, illetve API osztályait. Első körben érdemes egy pillantást vetni az ObjectCache osztályra: ez egy absztrakt oszály, amiből leszármazva saját cache implementációt készíthetünk. Kapunk pontosan egy darab ilyen implementációt is, a MemoryCache-t - ebből kedvünkre példányosíthatunk annyit per AppDomain, amennyit kedvünk tart, de ha nem akarunk semennyit, használjuk bátran a System.Runtime.Caching.MemoryCache.Default singletont. Itt egy Velocity-szerű API-val találkozhatunk, ami támogatja pl. a region-öket.
Mármint az API. A MemoryCache implementáció nem.
Vannak Add(), Get(), Remove() metódusok (ez nem túl meglepő), van Set() metódus (ha még nincs bent, berakja, ha bent van, update-el), illetve, ami nagyobbat változott, az a cache-beli elemek elavulásának kezelése. Minden elem mellé adhatunk egy CacheItemPolicy példányt, ami az adott elemhez tartozó "avulási szabályokat" reprezentálja. Property-ken keresztül szabályozhatjuk az abszolút- vagy csúszó elévülést, callback-eket adhatunk meg, amik meghívódnak, ha az adott elem elévül vagy frissítésre kerül, illetve a ChangeMonitors kollekcióba - micsoda meglepetés - change monitorokat tehetünk. Ez utóbbiak arra szolgálnak, hogy az adott elem cache-beli elévülését valamilyen külső körülményhez (filerendszerbeli file, SQL adatok, egy másik cache elem) megváltozásához kössük.

Tesztelni kéne a mail küldést...

2010-04-26T17:00:00.001+02:00

"Az alkalmazás erről automatikusan emailt küld" - ez valószínűleg egy elég gyakran előforduló mondat bármilyen üzlei szoftver specifikációjában. De vajon mit jelent? Mikor felelünk meg neki? Merthogy az "az alkalmazás elküldi" és az "a felhasználó postafiókjába megérkezik" között jelentős a különbség. Az email-forgalom 90-95%-a (!) SPAM, ami ellen hősi harcot vívnak az üzemeltetők - a sarokban álló PC-re telepített SMTP szerverrel való email küldés merőben teoretikus lehetőség.

A Port25.com-nak van egy szolgáltatása, amivel tesztelhetjük a mailküldést: a check-auth@verifier.port25.com címre küldött levelekre a Port25 automatikusan válaszol (az SMTP MAIL FROM címre), a válaszlevélben pedig (többek között) fény derül rá, hogy a külvilág számára mennyire tűnik SPAM-nek a levelünk.
Ugyanez a szolgáltatás elérhető a check-auth2@verifier.port25.com címen is, csak akkor a "From:" headerben megadott címre megy a válasz.

via CodingHorror

Megjelent az Enterprise Library 5.0

2010-04-23T10:13:00.003+02:00

Megjelent a Microsoft Enterprise Library 5.0 (aka "April 2010"). Az EntLib msdn oldalán megtalálható minden fontos link (download, doksi, relase notes, community, stb.).

Minden idők legrövidebb bugfixe

2010-04-20T17:05:00.001+02:00

Az, hogy egy site-unkon elérhető statikus tartalmak URL-je kis/nagybetű érzékeny-e (case sensitive) vagy sem, a webszervertől, illetve az alatta futó OS-től függ. A /Folder/MyImage.jpg és a /folder/myimage.jpg Windows/IIS alatt jó eséllyel ugyanazt a fájlt jelöli, Linux/Apache alatt pedig két különbözőt (bár annak se jósolok vidám, gondtalan jövőt, aki Linux, vagy más case sensitive fájlrendszert használó OS alatt csak casingben eltértő fájl-struktúrát épít, de teoretikusan működhet).
Így aztán, ha Windows/IIS alatt futtatjuk a szájtunk, akkor nyugodtan használhatjuk akármilyen casinggel a fájlneveinket.

Már ha a magunk ellenségei vagyunk.
Ha egy oldalon belül ugyanaz a grafikai elemet többször is felhasználjük (ikonok, lekerekítések, stb), akkor a browser csak egy HTTP requestet küld az adott képért - amennyiben a képek URL-je kis/nagybetűhelyesen megegyezik. A kliens browsere ugyanis nyilván nem fogja tudni, hogy a túloldali kiszolgáló case sensitive vagy sem, és a MyImage ugyanazt fogja-e jelenteni neki, mint a myimage. Ha nem szeretnénk ugyanazt az adatot többször megutaztatni, sem a beeső HTTP requestek számát duzzasztani, használjunk konzisztens casinget! Ha nagy forgalmú a site-unk, valószínű egyiket sem szeretnénk.

A poszt apropója, hogy én is belefutottam most az issue-ba - szerencsére könnyű volt javítani, így becsekkoltam valószű minden idők legkisebb bugfixét: a komplett changelist annyi, hogy egyetlen fájlban egyetlen betű változott. Nagyról kicsire.

Vizuális admin tool az AppFabric Caching-hez

2010-04-09T18:07:00.003+02:00

Az AppFabric Caching-et kizárólag PowerShellből tudjuk konfigurálni. Már ha nem telepítjük fel az AppFabric Caching Admin Tool-t.

Free ASP.NET 4.0 RC Hosting

2010-03-30T12:55:00.001+02:00

Az OrcsWeb ingyenes "Visual Studio 2010 and ASP.NET 4.0 RC hosting" programot indított. A cél az új feature-ök tesztelése - mind fejlesztői, mind hosting oldalról. Feliratkozás és további infó a http://www.orcsweb.com/programs/visual-studio-2010-free-hosting/ weboldalon.