Freigeben über

Whidbey has now left the building...

  • Artikel

"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

Comments

  • Anonymous
    October 31, 2005
    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
  • Anonymous
    October 31, 2005
    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?
  • Anonymous
    October 31, 2005
    Congrats, guys! Whidbey rocks.
  • Anonymous
    November 03, 2005
    The comment has been removed
  • Anonymous
    November 03, 2005
    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.
  • Anonymous
    November 06, 2005
    The comment has been removed
  • Anonymous
    November 06, 2005
    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.
  • Anonymous
    November 07, 2005
    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...
  • Anonymous
    November 08, 2005
    The comment has been removed
  • Anonymous
    November 08, 2005
    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.
  • Anonymous
    November 13, 2005
    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.