Scott Hanselman

Ok, now I'm confused.  I just noticed this on Dare's blog and again Oleg's blog:

The problem was that the XPathDocument had a radically different programming model than the XmlDocument meaning that anyone who'd written code using the XmlDocument against our v1.0/v1.1 bits would have to radically rewrite their code to get performance improvements and new features...

For this reason we've reverted the XPathDocument to what it was in v1.1 while new functionality and perf improvements will be made to the XmlDocument. Similarly we will keep the new and improved XPathEditableNavigator XPathNavigator class which will be the API for programming against XML data sources where one wants to abstract away what the underlying store actually is. We've shown the power of this model with examples such as the ObjectXPathNavigator and the DataSetNavigator.

So what are we saying here?

• XPathEditableNavigator functionality is being rolled into XPathNavigator, adding functionality to XPathNavigator and removing XPathEditableNavigator all together. Oleg infers that XPathDocument won't be editable. But it seems to me that Dare still called it new and improved and says later in Oleg's comments (emphasis mine):
• The XPathNavigator will be editable in Whidbey. However the XPathDocument will not be.
• XPathDocument in 2.0 will be the same as it was in 1.1, and the new perf improvements will be rolled into XmlDocument. This should speed up all the XSLT transformations people are doing against XmlDocuments today, rather than forcing them to use XPathDocument.

Is this correct?  Time to go re-write my chapter on XML! :)

UPDATE: I fat fingered the quote and reversed the meaning.  Dare cleared it up in the comments.

Dare sez:  "I said XPathDocument will still be read-only but the XPathNavigator interface will allow editing. This means I can use the XPathNavigator API to edit an XmlDocument but not an XPathDocument."

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

About   Newsletter

Hosting By

Here's a useful gem...basically 'preloading' the __EVENTTARGET in a hidden form field - from Developer.com:

Imagine you've created an ASP.NET Web page with a search button. The user taps a phrase into a text box and presses Enter. On most regular Web pages (think: Google), the form would be submitted and the results returned. In other words, the search button is automatically "clicked" for you.

However on an ASP.NET Web page, pressing Enter resubmits the form to the server, but actually does nothing... which is pretty useless, really.

So, how do you set a default button to be clicked when the user presses Enter? Simply add the following line to your page's Load event, replacing "btnSearch" with the name of your button. It uses a hidden Page method called RegisterHiddenField and works splendidly:

Page.RegisterHiddenField("__EVENTTARGET", "btnSearch")

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

About   Newsletter

Hosting By

Thanks Jim!  This is my "payment" for speaking at DevDays and doing well. This year my presentation was the highest rated of all DevDays in the US, last year Carl Franklin had that distinction. It was a very jazz-hands presentation and a lot of fun.  Jim is my DE in Portland, and Rory is the DCC. 

Now the real question is, what will Rory schmooz me with? XBox games? A new Keyboard? Come on, M$FT, let's have some coupons! ;)  Sigh, I'll probably get only a warm handshake (probably not even that) and a lump of coal.

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

About   Newsletter

Hosting By

Had a short conversation over email and John Lam had this to offer around Web Gardens.  I checked with Corillian's scalability labs and heard that we have found similar results (we recently more than doubled our previous scalability numbers.)

Web gardens look interesting at first, but I spent a lot of time talking with folks at MS about web gardens and the consensus is that web gardens are only useful on very large SMP boxes – 16-way and up. The reason why is that IIS’s sweet spot is on 4-8 proc boxes. By using web gardens on large (>16 proc) SMP boxes and affinitizing CPU’s, you can make IIS think it’s running on a 4-8 proc box when in fact it’s running on a much larger box.

Fantastic information for anyone who's been disappointed with 16 proc IIS performance or for the two-proc folks who are thinking of adding horsepower.

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

About   Newsletter

Hosting By

A day may come when you want to turn off the Debug dialog that appears when a .NET program has an unhandled exception.

Option 1: Registry key from Enabling JIT Debugging

For an application that includes managed code, the common language runtime will present a similar dialog to JIT-attach a debugger. The registry key that controls this option is called HKEY_LOCAL_MACHINE\Software\Microsoft\.NETFramework\DbgJITDebugLaunchSetting.

• If value = 0, prompt the user by means of a message box. The choices are:
  • Continue. This results in a stack dump and process termination.
  • Attach a debugger. In this case, the runtime spawns the debugger listed in the DbgManagedDebugger registry key. If none, control is returned, and the process is terminated.
• If value = 1, simply return control. This results in a stack dump, after which the process is terminated.  (No more dialog)
• If value = 2, spawn the debugger listed in the DbgManagedDebugger registry key.

Option 2: If you want to disable the JIT debug dialog, but still want an error dialog:

Visual Studio.NET|Tools|Options|Debugging|Just-In-Time and deselect "Common Language Runtime" and now you’ll get an OK/Cancel dialog instead of the select a Debugger Dialog.  Note: The registry entry from Option 1 above will need to be 0 for the dialog to show up.

Thanks to Eric Deslauriers of Corillian QA for these tips!

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

About   Newsletter

Hosting By