Whidbey has now left the building...

Whidbey has now left the building...

  • Comments 11

"May I have your attention please: Whidbey has now left the building."

That's right folks, after much ado, Whidbey (VS2005 + .Net Framework 2.0) has finally shipped. There's allot of great stuff in this release; looking back at the Everett (v1.1) release, who would have that the next version of our product would not only outperform Everett, but would also blow the doors off our native stack as well! In addition, Whidbey is our first release where we have put a large effort into improving the Xml tools that ship in Visual Studio. You can see the fruits of this in the new xml editor and xslt debugger. That's not even to mention the huge amounts of work we performed making a generally more secure, reliable product. Clearly, I don't have space to mention all the xml goodness in this release, so get ready to grab a copy and find out for yourself.

And congratulations to all the developers, testers, program managers, build engineers and everyone else who worked on the Whidbey XML team for putting out one great product!

Erik Saltwell

  • Eric,
    I am dissapointed by the fact that you do not have an xpath preview tool available in vs.net 2005.
    example: When setting the Xpath of an XmlDataSource, it would be nice to see a preview of the selected data.
    -raj
  • I noticed this release includes MSXML 6.0. Will there be an SDK release for this version? It seems to maybe be something that VS2005 internally uses, but is not intended for developers to use and redistributes?
  • Congrats, guys! Whidbey rocks.
  • MSXML6.0 will definitely have an SDK and we would love for developers to adopt it and add it to their apps... it's got some changes from previous MSXML versions - particularly in the security area so you may want to check out the docs. The web download for the runtime will be available on 11/7 and the SDK and docs will follow on a week later... Stay tuned here and we'll keep you updated on where to pick up the latest MSXML goodies.

    Thanks,
    Adam Wiener
    Program Manager - MSXML
  • Adam, thanks for the reply. This leads to the next obvious question - will MSXML continue to be developed and supported going forward?

    The reason I ask is that, I read in the help for a previous version of MSXML that MSXML would not be developed further, and that .NET XML services should be used instead.
  • Well, I can certainly see how that would be confusing! If you point me specifically to the documentation in question I will make sure to get a bug filed internally to get that cleaned up. In terms of the larger question here, let me break that into two different questions - In addition to being part of Visual Studio 2005 and SQL Server 2005, MSXML6 is going to be part of the Windows Vista operating system and so we will definitely continue to address bugs and issues as they come up in accordance with the lifecycle policies for the OS and for Visual Studio and SQL Server. In terms of new features, we are still working out the roadmap for MSXML beyond MSXML 6 - as the core stack begins to stabilize we need to look at where we can provide the most value. Is it new features in MSXML or layered on top of MSXML? Is it embedded MSXML for the plethora of devices that want to leverage XML? In any single release we've only got so much bandwidth to produce new stuff and want to make sure we're hitting the high points. We're starting to get a bit off-topic here... but perhaps I'll get a post going on "what's missing in the native XML world on Windows" and I'd love to get your (and everyone's) feedback.

    Thanks,
    Adam Wiener
    Program Manager - MSXML
  • Hi Adam, I don't see those statements in the newest version of the MSDN library, so they must have already been removed. I remember seeing that in the MSDN library around a year ago.

    Our biggest requests would be, convergence/harmonization with .NET XML services, and support for XQuery.

    Convergence with .NET XML services would be helpful so that we see the same interface in either environment, same performance, and same behavior. Right now, we use both .NET XML and MSXML. Do they share any common implementation already? How should we choose between one or the other?

    XQuery is important, because right now, we are having to call a Java XQuery engine (Saxon) from our applications. This works okay, but it requires our applications to have both .NET and JRE installed. We'd like to not have the Java stuff.

    Also, we don't see XSL as a substitute for XQuery, since XQuery is more functional, which makes it more suitable for the tasks we use it for. We'd prefer to see XQuery added to .NET, but if it were added to MSXML, that would be fine also.
  • I'm glad to see MSXML 6.0 released publicly. I always thought it was a little unfair how MSXML 5.0 was "exclusive" to Office 2003...
  • We're glad to see it ship too - even though MSXML6 doesn't have a lot of new features I think it is a big step up over MSXML4SP2 particularly in terms of reliability, security, and to tzagotta's point - compatibility with .Net 2.0. Perf should be about on par with MSXML4 - we actually improved scalability on 4 and 8-way machines but 1P should be about the same. System.Xml has a perf advantage in some scenarios - the System.Xml 2.0 XmlTextReader and XslCompiledTransform underwent major perf tuning - I'd be interested to hear from folks on what their performance experiences are with Syste.Xml 2.0 vs. MSXML6.

    In terms of compatibility with System.Xml 2.0 - we focused on "data" compatibility rather than "api" compatibility. We focused on ensuring the parsers parsed the same files (according to the W3C 1.0 rec), that the schema implementations were compatible, etc.

    And as for XQuery in MSXML, most likely that is not one of the places we will look to innovate on the native side. Have you looked at XLinq - http://msdn.microsoft.com/VBasic/Future/XLinq%20Overview.doc ?

    Thanks,
    Adam Wiener
    Program Manager - MSXML
  • We use XQuery scripts as templates that our end-users can customize. Since XLinq would require a compilation cycle, we can't consider that for our application.
  • Can you describe your scenario where you are using XQuery in a paragraph? We are trying to understand the scenarios that are not covered by XLinq.
Page 1 of 1 (11 items)