I found this while reflectoring. It appears that certain generic types are preloaded in order to prime the JIT compiler, and reduce type allocation (setting up MethodTables and EEClasses) latency.

A reasonable thing to do, and probably testing of the framework found unsatisfactory results, so hacks were inserted, and clearly labeled. I wonder if a subsequent service pack will eliminate these?

 How did this mixup get past legal? It doesn't matter - we must STOP THE EVIL EMPIRE. Long live teh LINUX!!!!!11one.

Some good info on what will be in the upcoming Jan (or Feb) CTP for Visual Studio 'Orcas'. It's hard to commit to a mapping layer technology when this is coming out - even if it is February.

http://download.microsoft.com/download/5/9/c/59cd0dc5-4691-4c3e-840c-66d865f27692/mapping.xps

My quote got on a book I reveiewed for Addison Wesley: VSTO for Mere Mortals.

I actually meant it too - it's a good book. Great for the Word and Excel macro-heads who want to dive into more power - power that the CLR and .Net languages give.

I used to disdain departmental power users who took up the code shovel and started digging... but now I'm rather encouraged by it. I think these kind of inroads could indicate paths of least resistance as an organization evolves. Not, probably, what corporate IT wants to embrace. I think the CLR, with Code Access Security, type safety, hostable runtime, adaptable client-side / server-side story, peerless toolset, access to legacy code assets has the lead here.

I am implementing an instance of IBindingListView for a UI binding scenario. This is a fairly complex undertaking, given also that the list is relying on some dynamically generated runtime code to avoid reflection yet give the list the flexibility in dealing with multiple types. Ultimately, I need knowledge of the properties of the type being displayed in the list, so I can parse the IBindingListView.Filter property string and behave correctly under a call to IBindingListView.ApplySort. Enter System.ComponentModel.PropertyDescriptor and the related type description API.

Since I will be dealing with potentially incorrectly cased values in the filter, I need to know how to get a property out of the PropertyDescriptorCollection regardless of case. There is an .Item property, mmm, ok... but what about case? The 'Remarks' section comes to the rescue (as jfo also observes at her new digs):

The Item property is case-sensitive when searching for names. That is, the names "Pname" and "pname" are considered to be two different properties.

This is not the first time that the Remarks section has helped me out. Indeed, it is often the only valuable information in my effort to understand the behavior of the type or operation. This is good to consider when decorating my own types with the <remarks></remarks> xml doc tag - what does the user of this API need to know to eliminate having to make explorations with mockup code?

Now, if only the same existed for expected behavior for an IBindingListView's 'Contains', 'Find' and 'IndexOf' methods in the presence of a non-null 'Filter'. I suppose this is where MSDN Community Comments come in.

A nice corpus to try tuning various algorithms against.