SAJAGI: jen upřesním, pokud nastravím preCondition="managedHandler", tak se daný modul nespouští nejen pro statický obsah, ale ani nikde jinde (tj. ani ne pro MVC controller, apod.)

Řeším tu jeden problém - ASP.NET MVC 2, .NET 3.5, IIS 7.5 express integrated. Chci dosáhnout toho, aby se mi určitý http modul nespouštěl pro statický obsah. Bohužel, pokud nastavím runAllManagedModulesForAllRequests="false", tak se mi nespustí žádný modul, který má preCondition="managedHandler". Tuší někdo proč? (chtěl bych to takhle nastavit právě pro ten můj modul, ale nespouští se ani FormsAuthentication, apod.)

NECROMAN:

We've traced the call and it's coming from inside the house: A function call that always fails - The Old New Thing - Site Home - MSDN Blogs
http://blogs.msdn.com/b/oldnewthing/archive/2011/11/03/10233277.aspx

To neni pokus o vtip, bohuzel s tim mam take zkusenosti (:

NECROMAN: něco podobného se mi stávalo taky - z nějakého důvodu se nepřegenerovávaly pdb. Pomohlo je promazat.

To je fakt nejaka magorina - ted jsem nahradil ten test (t == null) za ReferenceEquals(t, null) a porad me t haze do te vyjimky, i kdyz watch ukazuje
ReferenceEquals(t, null) | false

Panove, potreboval bych drobnou pomoc - mam dva delegaty vytvorene pomoci DLR
(metody Compile()) a potreboval bych videt, jaky IL mi to vygenerovalo. Dokaze se do toho nekdo rychle podivat? Je to jen testovaci projekt, jeden .cs soubor...

ted koukam, ze == a != je mozne overloadnout... nevim, zda je to i u te moji tridy, ale je to kazdoapdne pekna prasarna :)

TENCOKACISTROMY: t == null vraci true, object.ReferenceEquals(t, null) vraci false
t.FullName vrati spravne nazev typu

takze zkusim vymenit t == null za to druhe porovnanvani a melo by to fungovat :)

NECROMAN: Spíš zkus Debug.WriteLine(t.FullName); co ti to vypíše

NECROMAN: Opacne porovnani (null == t) nepomaha? Co vraci object.ReferenceEquals()?

TENCOKACISTROMY: i po rebuildu to same. Vypise to System.RuntimeType

NECROMAN: Urcite se ti ten kod znovu prelozil? Neblbne jen debuger?

Co to udela, kdyz das: "Debug.WriteLine(t.GetType().FullName);" ?

dotaz - nacitam assembly se ze souboru pomoci
Type t = Assembly.Load(assemblyuName).GetType(typeName);

dale testuji:
if (t == null) throw new ...

kdyz si dam breakpoint na ten if (), tak tam mam jasnou tridu, se vsim vsudy, ale stejne skoncim na tom throw, WTF?

Prosimvas, nevite jak pro pouzivani System.Linq.Dynamic zavolat metodu FirstOrDefault na vysledku ? Prevadim to pak do JSONa a je docela zasadni jestli mi to vytvori pole s jednim objektem nebo jen ten objekt.

Zkoušel někdo hledat podle computed property v LINQ dotazu na NHibernate?
Tohle by mohlo fungovat, zítra vyzkouším.
NHibernate: Linq-ing Calculated Properties « Hendry Luk — Sheep in Fence
http://hendryluk.wordpress.com/2011/09/06/nhibernate-linq-ing-calculated-properties/

JACHYMKO: diky

Pokud v OnActionExecuted ... melo byt v OnActionExecuting

JACHYMKO: kazdy controller odvozujeme od vlastniho controlleru, ktery ma override na OnActionExecuting a OnActionExecuted

Pokud v OnActionExecuted neco ulozim do HttpContext.Items a pozom v prubehu requestu k tomu pristoupim ze static metody pres HttpContext.Current.Items mam jistotu ze

a. vzdy dostanu stejna data co jem ulozil v OnActionExecuting
b. k temto datum se nedostane soubezny request ?

Ve webovy aplikaci si chci ukladat cas posledni aktivity jednotlivych uzivatelu. Ale nechci si to zapisovat pri kazdym requestu co poslou (posilaji hodne request => hodne zapisu do DB).

Rikal jsem si, ze bych si udelal buffer, kam bych si ukladal ID uzivatele & cas aktivity. A v nejakych intervalech bych to pak ukladal na server. Ten buffer musi byt thread-safe, to je jasny. Nevadi mi, kdyz by nahodou nejaky ten cas "zmizel" a neulozil se do DB. Ty casy jsou stejne jen orientacni.

Jak udelat to ukladani v nejakym intervalu?
Mam pri zapsani casu k uzivateli kontrolovat kdy naposled se to ulozilo a pak to ulozit?
Nebo mam mit nejakej timer, kterej mi bude ukladat? Pokud timer, tak jakej zvolit na IIS?

Diky.

Teda divil bych se, kdyz by v jednu chvili v jednom vlakne byly zpracovavany dva requesty. Vzdyt zpracovani toho requestu zacina v nejakym IHttpHandler.ProcessRequest a tam to jede porad dal, dokud tahle metoda nezkonci, ne?

Co se ale nejspis muze stat (netestoval jsem to, ale prijde mi to logicky), ze po dokonceni requestu se vlakno neukonci, ale pouzije se na zpracovani dalsiho requestu.