Because of the nature of Silverlight 2’s API library, and its relationship with the APIs in the .NET Framework, finding content in the MSDN library using Search can be frustrating. (Even more frustrating than usual, that is 😛 )
Following are some tips and tricks that can help you find the Silverlight-specific information you are looking for, and avoid search hits that take you to topics that really mainly apply to .NET Framework (and perhaps even older versions of the Framework).
Note that these tips and tricks were tested using the main MSDN Search functionality powered by search.microsoft.com, but some of the basic concepts should also help with results using other search engines.
The brute force trick, API version: When you search for an API you know the name of, always use a string in the form of apiName apiType Silverlight. For instance, instead of just searching for “StackPanel”, search for “StackPanel Class Silverlight”. Note that adding the apiType will help push the managed API on top of the unmanaged (Silverlight 1.0) API in the results. If that’s NOT what you want (you wanted the 1.0 one) typically omitting apiType will push the unmanaged one higher.
The brute force trick, conceptual version: Use a string in the form of wordOrPhraseICareAbout Silverlight, for instance “Layout Silverlight”. Sometimes, you can maybe get really targeted results if you also include the word “Overview” or “How-To”; this will help push down blog results. But read on below for an even better way.
The filter trick: Guess what? MSDN has technology filtering on search results. For some development scenarios these filters are a mixed bag but for Silverlight they work pretty well! You need to be on an actual Live Search page to use this; there’s no technology filter on the Quick Search (and also this is a feature specific to Live Search, not present on other search pages). To get there fast, just use one of the brute force tips suggested above. Once on the Live Search page, look in detail at the Live Search box at the top of the page (as in, don’t just skip it like you usually do 😉 ). You’ll see Refine by Topic and Refine by Source options. If you set these to Silverlight and Library Documentation and Articles, you can really up the prominence of the entry-level topics that the SDK writing team wanted you to see first.
The geeky versioning trick: OK suppose you ignored all my other advice and searched for some API like MeasureOverride, and ended up on the reference page for the .NET / WPF version of the API. You might have noticed that there’s a little box on the upper right that you can use to bounce around between .NET framework versions, in this case from 3.5 to 3.0, useful if you happen to be targeting a 3.0 runtime and are a .NET developer. But sadly, no quick way to get to the “Silverlight version”. All is not lost! You can get there from here. All you need to do is a little address bar URL hackery. So, up in the address bar, change that URI http://msdn.microsoft.com/en-us/library/system.windows.frameworkelement.measureoverride.aspx to insert the string “(vs.95)” right before the “.aspx”. So for this example http://msdn.microsoft.com/en-us/library/system.windows.frameworkelement.measureoverride(vs.95).aspx. Viola! Now you are at the Silverlight “version”, which happens to be an advancement of the .NET framework version ID’s for geeky reasons that I totally don’t want to get into. (And, in case you care, the little box can take you “back” to full .NET 3.5 or 3.0 versions now.)
The versioning trick doesn’t generally work with conceptual topics, although there are a few topics that cover general CLR that really are re-versioned .NET -> Silverlight under the same scheme. But don’t rely on that.
(BTW, sometimes, you can use some of the information on .NET 3.5 page like MeasureOverride, but you’d have to be really an expert on WPF and Silverlight to know the pitfalls. And if that’s true of you … why did you need this documentation page again? 😉 )