Discussions

Sven Groot wrote:

stephbu wrote: Hi Sven, yes I can confirm that this issue was raised, and has been fixed for release in early April.

It doesn't appear to be fixed yet, or has the fixed not been deployed yet?

Was deployed yesterday

http://msdn2.microsoft.com/en-us/library/system.argumentnullexception(VS.80).aspx">http://msdn2.microsoft.com/en-us/library/system.argumentnullexception(VS.80).aspx

Heheh - for the Win95/Chicago betas, I remember getting a new 1st generation Pentium 120Mhz,  huge 300Mb hard-disk, 128Mb of RAM, and this strange popout cupholder - I still chuckle at the support calls that went something like 'how do I fit this CD thing into the floppy drive?'

That first distribution of Win95 shipped on 13 high-density floppies

That was great time to be in the industry...

W3bbo wrote:

...Solid-state HDDs have existed for ages, what's so innovative about slamming it in a laptop?

Yeah I remember an article by Jerry Pournelle in the late & sadly missed Byte Magazine - review of a "huge" 8Mb production flashdisk ISA card made by Digipro way back in late 89/90.  Price at the time was enormous ($1000's) 

Now I think even my car has more non-volatile memory

Hi Sven, yes I can confirm that this issue was raised, and has been fixed for release in early April.

Titled, "Aliases for types/members containing with "null" don't work", the bug impacts any friendly-named URL with Null in the name.
e.g.

Impacts "ArgumentNullException"
http://msdn2.microsoft.com/en-us/library/ArgumentNullException(VS.80).aspx">http://msdn2.microsoft.com/en-us/library/ArgumentNullException(VS.80).aspx

Doesn't Affect "Nullable Generic Structure"
http://msdn2.microsoft.com/en-us/library/b3h38hb0(VS.80).aspx">http://msdn2.microsoft.com/en-us/library/b3h38hb0(VS.80).aspx

Search is reacting to the 404 the bug generates by dropping it from the crawl, leaving the existing Everett document as next best match.

*dupe post*

PetKnep wrote:

Searched for SHParseDisplayName on the old search and the first result is right. Searched it on your updated one and the correct result is missing.

BTW - IE7 search provider addon was a good idea. I'll try to keep using the beta search to see if it gets any better.

Thanks Pet for the participation and feedback ... 

A large part of the project is exposing an area of missing documents buried in the fabric of the original Library system (ASP circa 199x...)   Generally documents linked to by external sites or crawlers with "MSDN Shims" were discovered in this soup. 

Piece-by-piece we're moving these documents to the MSDN2 platform where crawling works and we get much enhanced metatagging for some of the fun we'll have in future releases.

I'm glad you like the IE7 search too - we're working on a slew of ideas around exposing search as an XML data-provider.

Steve Butler
Software Architect
MSDN & Technet (http://blogs.msdn.com/msdnsearchblog/)

Karim wrote:

stephbu wrote: As I've said in other posts on C9 and on our blog, send me mail, comment on our blog, or blog about MSDN Search yourselves.  We're watching, listening, and responding.

A few days ago, I wanted to create an OpenSearch Provider for IE 7... and did an MSDN search on "opensearch" -- got 5 results, none of which were related to OpenSearch.

Today I get 6 results -- one of which is related, but it's just the word appearing in a chat transcript...

I originally thought this was due to the quality of MSDN search.  I eventually realized it was probably because MSDN didn't have any documentation on OpenSearch.   (I eventually found what I needed by doing a Google search on "opensearch," which led me to the AddSearchProvider method.)

If you know enough to search MSDN for the AddSearchProvider method, you currently get two hits, both of which say

If you would like to add/implement access to your site's search provider, implement the window.external.AddSearchProvider(URL) call in your webpage to prompt the end user (see our Internet Explorer blog).

If the IE Blog is where we're supposed to go for this information, maybe MSDN Search should crawl it...?

(When searching for "AddSearchProvider," Google points to the IE Blog as well...)

Yes Karim, finding Opensearch on MSDN document site seems pretty hard a the moment.  Investigating further, there is one article missing from the index, that should be addressed by some engineering we're doing to make the MSDN library pages more crawlable. 

Biggest issue is that the calls aren't documented on the main MSDN site yet.  Our approach at the moment is to segregate searching between "reference sources" like the main site, and community contributions like blogs, forums and other partner community sites. 

In this case the Blogs tab of the lab search did find "opensearch".

http://lab.msdn.microsoft.com/search/Default.aspx?__VIEWSTATE=&query=opensearch&siteid=0&tab=3

So I have an interesting question for the thread...  How important is the that differentiation between the sources? 

We're ideas around alternate searches around, e.g. Search main site and blogs with the same query - such that if you searched for say "Opensearch" you'd get the results for all sites back.  Of course this increases the signal to noise ratio somewhat though.  (for a general query like XML, combined it'd look like this...)

Another approach we're looking at is doing much broader queries and providing some neat one-click filtering options. 

We're in the process of identifying features for the next development cycle, as always thoughts and feedback really welcome.  (MSDN Search Blog)

Steve Butler
Software Architect
MSDN & Technet

Yeah it is a pretty tough job, the balance is to make a search that works well across a couple of million documents in tens of languages for a few dozen technologies all using the *same* terminology - e.g.  what does Window, SELECT, INPUT mean?

Live.Local API - unlike other Service APIs (Mappoint, Search etc.) isn't documented on MSDN yet.  I guess that Live isn't ready to commit formal docs up there until they release. 

I've just adding local.live.com/help to our test environment's search scope though it introduces some noise to the rest of developer search (much of /help is interface help rather than url reference)

If that works out I'll put it live later tonight.  The urls it returns give a bunch of script errors (i'd assume because they need other page structure to work).  We'll work with the Local guys to see if we can make that better.  It'd be cool if they had a development center on MSDN of course.

We're working on a bunch of different projects to improve crawling discoverability, ways to slice/dice/filter results, and in general improve the quality results for customers searching on ours and external search engines.

As I've said in other posts on C9 and on our blog, send me mail, comment on our blog, or blog about MSDN Search yourselves.  We're watching, listening, and responding.

Another revision of MSDN Search went into Labs tonight - we think we've got the script errors beaten and can no-longer repro the errors.  I'll nod my head to Nikhil Kothari's Web Dev Helper as a great tool to watch browser interaction...

A few improvements in the UI behaviour switching tabs, and cleaned up stylesheets quite a bit,  though there is still more work to do in there.  Quite some back-office work put in to monitor performance and errors.

Feedback and comments as always welcome on all aspects of the project.

Steve Butler
Software Architect
MSDN & Technet Product Group
( Email me... )

Thanks Androidi for trying out the search.

You're running into one of the larger challenges of our problem domain - the same term being used in *many* different contexts.  This of course is compounded by some content issues through articles "attractive nuisance" titles in this case. 

We agree that that vanilla site search results for general or broad queries can be pretty misleading, we will be looking to address these issues in future revisions through the use of scoping interfaces like "search from here" in the documentation. 

(possible now with the new API now but the syntax is pretty ugly - example scoped to just VSS docs here...)

We're also working on some ideas around categorized results and one-click result filtering to make it easy to find the "Win32 Temporary Files" and ignore the VSS articles for example.  Watch this space... 

Why Display Urls?  Couple of good reasons - a) they're not always cryptic, and b) basic copy and paste. 

The cryptic URL is requirement to keep URLs around for at least the lifespan of the product - 7 years or more, with multiple revisions in at least 9 languages.  Its pretty tricky do that and keep the URL name stable and meaningful without resorting to IDs.  We do at least support human readable aliases for common paths e.g. http://msdn2.microsoft.com/System.String

We'll be posting on our blog and keeping the labs & live iterations going over the coming months - keep using the pages, let us know what you think!