GOSHEWAN: kolega na to narazil vcera na stejnem miste, tak mi dnes psal poznatek:
Tried ReferenceEquals and it didn't seem to make any difference.
I beginning to think that it's an issue with the debugger. Even though the debugger steps into the block and hits the throw statement, the exception isn't thrown and the code keeps on executing. When I actually set the object to null, however, the exception is thrown. This could just be a feature in VS.

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.

MILL: IIRC, může se stát, že jeden request se bude provádět postupně na různých threadech. Nevím, co to přesně znamená „současně […] ve stejném threadu“. ;-)