Missing compiler required member 'System.Runtime.CompilerServices.ExtensionAttribute..ctor'

A címben található hibát dobta a studio, amikor fordítani akartuk az MVC application-t. Olyan gépen, amin előtte nem fordult még soha MVC-s project. Ráadásul VS 2008, 2010, 2012 is van telepítve, hogy szebb legyen.

Sokat guglizva az volt a gyanú, hogy nem jó system.core-t használ, de hiába próbáltunk ebben az irányban ki bármit. Már minden dll referenciát eltávolítottunk, újra hozzáadtunk, semmi sikerélmény. A core assembly bindingokat beállítottuk a web.configban, sőt, a target framework verziót is állítgattuk hogy hátha észhez tér. Egyszerűen nem fordult le, panaszkodott hogy nem tud mit kezdeni az extension method-okkal. Találtam néhány fura bejegyzést, ahol azt írták hogy egy új osztály létre kell hozni ezzel a tartalommal:

Nem sok reményt fűztem hozzá, de megoldotta a problémát.

MVC Controller külön assembly-ben?

Nagyobb rendszereknél megfogalmazódhat a kérdés, hogy  lehet-e pluginelhetővé tenni a controllereket. Ha esetleg csak a controllerben változtatunk valamin, akkor elég legyen kicserélni csak azt a dll-t.

Erre egy rövid útmutató:
How to call controllers in external assemblies in an ASP.NET MVC application

NAGYON tömören az MVP-ről és MVC-ről

Egy rövid, de velős összefoglaló arról, hogy miben különbözik az MVP az MVC-től:
What are MVP and MVC and what is the difference?

MVC Validation in jQuery UI dialog

Az MVC validációja tökéletesen működik addig, amíg valamilyen dinamikusan generált tartalmat nem renderelünk az oldalunkra.

Abban az esetben ha pl. jQueryUI dialog-ot használunk az MVC alkalmazásunkban a validáláshoz fel kell fűznünk az újonnan megjelenített content-et a validációhoz.

Erről a következő linken olvashatunk:

http://chuyves.wordpress.com/2012/04/05/jquery-dialog-validation-mvc/

MVC4 webAPI Session hogyan

WEBAPI esetén MS elspórolta a Session létrehozását és kezelését alapesetben. Van rá mód, hogy legyen Sessionünk, csak egy marker interface kell hozzá:

Ha az ASP.NET MVC Controllert ControllerBase alaposztály szerint használjuk a már megszokott módon lesz Session-ünk a HttpContext-ben, amit a következőképpen lehet elérni:

HttpContext.Current.Session

Azonban ha MVC API-t használunk ami az ApiController osztályból származik, alapesetben nincs session-ünk.

Ahhoz, hogy legyen a következő lépéseket kell megtenni:

1. Saját SessionControllerHandler osztály létrehozása a HttpControllerHandler és az IRequiresSessionState Marker Interface leszármazásával:


public class SessionControllerHandler : HttpControllerHandler, IRequiresSessionState
{
        public SessionControllerHandler(RouteData routeData)
            : base(routeData)
        { }
}

A Marker Interface (IRequiresSessionState) fogja jelezni a Framework-nek, hogy létre kell hoznia a Session-t az eléréséhez.

2. SessionRouteHandler osztály létrehozása, amely az IRouteHandler interfészt valósítja meg

public class SessionRouteHandler : IRouteHandler

{
        IHttpHandler IRouteHandler.GetHttpHandler(RequestContext requestContext)
        {
            return new SessionControllerHandler(requestContext.RouteData);
        }
}

3. Az előbbiek tényleges használata a route tábla létrehozásánál:


RouteTable.Routes.MapHttpRoute(
             name: "DefaultApi",
             routeTemplate: "api/{controller}/{id}",
             defaults: new { id = RouteParameter.Optional }
         ).RouteHandler = new SessionRouteHandler();

A megoldásról többet a következő oldalon olvashatsz:

http://www.strathweb.com/2012/11/adding-session-support-to-asp-net-web-api/

MVC3 és vastag kliens

Természetesen teljes támogatás van ehhez is:
http://www.asp.net/web-api/overview/web-api-clients/calling-a-web-api-from-a-net-client

Így működik a vegyes kliens elég könnyen. Mivel elég alapszintű a megvalósítás, azért több meló van vele, mint a régi "WCF"-es megoldással, lásd auth.

Többszálúság és ASP.NET és MVC

Végre egy jó cikk arról, hogy azért mert Te egyszerű vagy és ehhez segítséget ad a környezet, még nem fogsz egyszerűen élni. Ergo ne legyél egyszerű és lusta, értsd a működését a keretrendszernek, tudd, hogy mi az a többszálúság, hogyan működik, és miért:
Elég erős a cikk, hosszú és bonyolult. Mégis érdemes végig rágni és megérteni és csak az utolsó bekezdéseket fenntartással kezelni (nem kell reflektorozni, ha tisztában vagy az alapokkal és olvasol):
http://tothviktor.wordpress.com/2012/11/05/async-vs-asp-net/

Kiegészítés: az "alapok" nem azt jelenti, hogy egyszerű dologról van szó, hisz MS is már vagy 4x fut neki ennek a témának más néven, és mindig lepattan róla, mert kurva bonyolult és főleg nehezen felfogható emberi gondolkodással a párhuzamos futás véletlenszerűsége. Azért, mert alapokról beszélek még igen komoly utánajárás szükséges.

Visszaküldött fájl törlése MVC-ben

Nem ritka dolog ASP.NET MVC-ben, hogy egy szerver oldalon létrehozott fájlt egy FilePathResult segítségével küldünk vissza a kliensre, valahogy így:

public FileResult GetFile()

{

    // TODO: itt a lényeg...

    return this.File( filePath, type );

}

Ha az adott fájl történetesen egy ideiglenes állomány, akkor felmerülhet a kérdés, hogyan tudjuk a teljes fájl visszaküldése után törölni az immár szükségtelen fájlt a szerverről?

http://balassygyorgy.wordpress.com/2012/11/05/visszakuldott-fajl-torlese-aspnet-mvc-ben/

Hasznos MVC DropDown editor template

Általában egy MVC projekten a lenyíló listák kezelésére jó ha saját editor template-et hozunk létre.

Van amikor a leghasznosabb az, hogy a template maga adatokat is le tud kérni valamilyen paraméter alapján, és fel is tölti a saját lenyíló listája elemeit azokkal az adatokkal. De ez nem túl szép megoldás, nem jó ha egy template (amit néha control-nak hívok, mert hasonlót jelent) tud az adatelérésről. 

Én egy olyant csináltam az imént, ami a megadott property (amihez az editor template tartozik) attribútumai alapján bindolja a dropdown-t. Úgy működik, hogy egy attribútumban meg van adva annak a lista property -nek a neve, amelyikben az adatok vannak. 

Pl a LoanCountry property-hez tartozik egy SourceList="CountryList" attribútum, ez a CountryList  property pedig IList típusú. 

És a LoanCountry property parent ViewModel-jéből egy extension method-ban (MyDropDownListFor) ezt a listát elérjük, és fel tudjuk használni.

Az ötletet ez a bejegyzés adta, ugyan itt elnevezési konvenciót használ és függvényt hív, nekem annyiban más hogy a csodás xml attribútumozással meg tudom adni hogy honnan vegye a listát, és ez nem fv hanem egy property.  

Ezt a listát egyébként automatikusan tölti. Mert minden ilyen lista úgymond "CatalogueData" típusú elemekből áll, amiben van key meg id meg displaytext stb. Ezt használjuk pénznemekre, országokra stb., szótár táblákra.

Hogyan tölti automatikusan? Ez egy következő blog bejegyzés lesz, a lényege hogy fel van attribútumozva, hogy milyen katalógus adat típus (country, currency stb), és az összes ilyen listán végigmegyek a ViewModel-ben reflection-el, és a megadott attribútumokból paramétert gyártva meg tudom hívni a controllerből a facade függvényt, ami a megfelelő listát adja vissza. Ezzel töltöm ki majd a lenyílót. 

Ezt a listát pedig a fent említett editor template ismeri (az attribútumnak köszönhetően amit xml-ben adunk meg), és automatikusan összerakja magát. Cool.

ViewModel attribútumok dinamikusan

A téma természetesen MVC.

Napok óta egy olyan elegáns megoldást próbálok kidolgzozni-beépíteni, amivel dinamikusan tudom kezelni (konfigurálni) az MVC View-khoz tartozó ViewModel-ek viselkedését.

Ezalatt azt értem, hogy például nagyon jól és egyszerűen lehet használni a gyári attribútumokat, többek között a validáláshoz és a control helperekhez tartozó label szövegek kiírásához, DE. Mindig van DE :).

Az alap problémám az volt, hogy ezek az attribútumok ugyan jók, de mi van, ha a validáció függ valamitől, valamilyen adattól, kliensen kiválasztott/beírt értéktől, parent view-tól függően más kötelező, workflow állapottól függően másképp kell validálni stb. Vagy mi van, ha ugyanígy a textbox elé írt label szövege függ valamitől. Például ha 2000 EUR-nál nagyobb az összeg, akkor CK Base Rate-et kell kiírni, ha kisebb akkor FH Base Rate-et. De a tartalom, mögötte a ViewModel-ben a property ugyanaz. Ezt nem olyan egyszerű megoldani, mert ha beégetjük az attribútumokat, akkor még a soksok if mellett is lesz fejtörés bőven.

Ugyan nem a spanyol viaszt találtam fel, de néhány ötletet találva és összerakva a végeredmény az lett, hogy egy custom meta data kezelőt írtam, ami egy adatforrásból kiolvassa (most épp xml-ből, de csatolható alá bármi) az atott típus adott property-jéhez az ADOTT KONTEXTUSBAN meghatározott attribútumait, és ezeket dinamikusan pakolja rá. 

Majd ezeket a HtmlHelper-ekben már a megszokott módon lehet kezelni, kiolvasni, és így egy komplett parciális View összerakásának kódja amiben 20 property adata van, nem több 20 sornál. És újrahasznosítható ez a 20 sor is, el tudom helyezni ugyanazzal a ViewModel-el egy print formra is, vagy egy tök más readonly felületre, beviteli formra, csak az xml-ben másképp kell felkonfigurálni a viselkedését, hozzá tartozó label szövegezését.

Ezen túl gyakorlatilag a határ a csillagos ég, hiszen írhatok custom attribútumokat, amikkel egyéb custom viselkedést írhatok le, és ezeket is az xml-ben írom le, vagyis fordítás és programozás nélkül meg tudom határozni. Sőt, továbbmegyek, EA-ban megrajzolt ábrákból az xml-t ki lehetne generálni.

Nem írnék konkrét kódot, inkább 3-4 linket, amiből el lehet indulni:
Using TemplateHint and other Model Metadata features in MVC
Get Custom Attributes from Lambda Property Expression
ASP.NET MVC LabelFor Helper With HtmlAttributes
Accessing attributes from Custom Html Helpers

Az alapötlet az első linken elérhető blogbejegyzésből jött, a többi az inkább segítség a továbbiakhoz.

AutoMapper

Van egy jelenlegi rendszer, amiben sok saját típus van. Zöme azokból az időkből maradt meg, amikor még nem volt nullozható datetime, int, stb. Ezen típusokból összerakott osztályok alkotják a mostani domain model-t.

Most az MVC -nek létrehozott Model DTO objektumait kellene előállítani valahogy okos módon, anélkül, hogy kézzel megírnánk minden oda-vissza mappert.

Ezt néztük ki egy lehetséges jó megoldásnak:
http://www.codeproject.com/Articles/61629/AutoMapper

Ismeri valaki ezt az AutoMapper nevű cuccot? Használtátok? Van valami, amire vigyázni kell, különösen szivató?

JSON sorosítás, performancia

Balássy Gyuri ideillő bejegyzését érdemes elolvasni, mielőtt kitaláljuk a JSON sorosítás mikéntjét.

És itt le lehet tölteni a performancia teszthez használt forrást is, és a json.NET-et is

IDataErrorInfo

Példa az interface-re és a partial method-ra.

http://www.asp.net/(S(pdfrohu0ajmwt445fanvj2r3))/learn/mvc/tutorial-37-cs.aspx