Greg Fee — *the* CLR security man in the house

style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">You href="">asked
for it you got it…  I am happy
to announce that the primary dev on the
st1 ns = "urn:schemas-microsoft-com:office:smarttags" /> face=Arial size=2> style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">CLR face=Arial size=2>
style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">CAS face=Arial size=2> security
system has started a blog!  Every
wounder how the stack walking works or what is special about the security custom
attributes… read on and find
out />

style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"> 


Comments (2)

  1. Anil John says:

    Thank You! – Anil

  2. Don McNamara says:


    I’ve really been enjoying your blog. I have a topic that perhaps you or one of your co-workers could cover in the future: I really would like a better understanding of how the XMLSerializer works.

    We hit some noticeable lags on the first call to serializing a particular type — also the first call to a web service seems to behave the same. I am guessing that it uses reflection to generate some dynamic class on the fly and then caches it for subsequent use. On the server-side this is not a big problem since restarts are infrequent, but on the client side the application appear sluggish to our users the first time they do something.

    I’m wondering if there is a clean way to preload the XMLSerializer cache. I suppose I could spawn a thread and create an XMLSerializer for each type that supports serialization, but that seems like a hack.

    Okay. Sorry for the mini brain dump. Keep up the great posts!

Skip to main content