MSXML4 wird "gekillt" (im IE)

[Jeena Paradies]

Hallo,

Ich habe mir diesen anscheinend gar nicht mal so unwichtigen Beitrag im Microsofts XML-Blog durchgelesen: MSXML4 is going to be kill bit-ed.

Doch irgendwie werde ich überhaupt nicht schlau daraus. Bisher kannte ich nur ActiveXObject("Msxml2.XMLHTTP") aus der Mozilla-Ajax-Dokumentation. Handelt es sich dabei um genau das gleiche nur Version 2 davon, also eine sehr alte? Müsste man heutzutage eigentlich ActiveXObject("Msxml6.XMLHTTP") anwenden und alle paar Jahre im code die Versionsnummer auswechseln?

Hat das ganze eigentlich irgendwelche Auswirkungen auf den Wald-und-Wiese-Code der heute so produziert wird?

Jeena

[wahsaga]

hi,

Doch irgendwie werde ich überhaupt nicht schlau daraus. Bisher kannte ich nur ActiveXObject("Msxml2.XMLHTTP") aus der Mozilla-Ajax-Dokumentation. Handelt es sich dabei um genau das gleiche nur Version 2 davon, also eine sehr alte? Müsste man heutzutage eigentlich ActiveXObject("Msxml6.XMLHTTP") anwenden und alle paar Jahre im code die Versionsnummer auswechseln?

AFAIK reicht es aus,

new ActiveXObject('Microsoft.XMLHTTP')

zu benutzen - damit sollte immer die aktuellste verfügbare Version benutzt werden.

Ausserdem hat sich das problem mit dem IE 7, der XMLHttpRequest nativ unterstützt, doch sowieso irgendwann erledigt.

gruß,
wahsaga

[_hkl]

hi,

Doch irgendwie werde ich überhaupt nicht schlau daraus. Bisher kannte ich nur ActiveXObject("Msxml2.XMLHTTP") aus der Mozilla-Ajax-Dokumentation. Handelt es sich dabei um genau das gleiche nur Version 2 davon, also eine sehr alte? Müsste man heutzutage eigentlich ActiveXObject("Msxml6.XMLHTTP") anwenden und alle paar Jahre im code die Versionsnummer auswechseln?
AFAIK reicht es aus,

new ActiveXObject('Microsoft.XMLHTTP')

zu benutzen - damit sollte immer die aktuellste verfügbare Version benutzt werden.

Ausserdem hat sich das problem mit dem IE 7, der XMLHttpRequest nativ unterstützt, doch sowieso irgendwann erledigt.

gruß,
wahsaga

Schockschwerenot !

Ich hatte dich irgendwie im Hinterkopf dass es sowas wie "VersionIndependentProgIDs" gibt.

Stimmt auch - eigentlich, aber halt nicht hier gemäss der Doku
zum MSXML 6.0 SDK :

[cite]
MSXML 6.0 SDK
   |
   + MSXML
       |
       + MSXML SDK Overview
           |
           + GUID and ProgID Information

Why Version-Independent GUIDs and ProgIDs Were Removed

Although version-independent GUIDs and ProgIDs appear simpler for coding, they are not supported in MSXML 4.0 and later for the following reasons.
The introduction of Windows XP Side-by-Side installation. This technology allows you to simulate the effects of version-independent ProgIDs and replace mode in a cleaner and more manageable way.
Customer experience reveals that in previous implementations of MSXML, version independence and replace mode are complicated to manage and can introduce instability in the production environment.
For example, the following types of application errors and support issues can arise. These problems easily outweigh the benefits of version independence and replace mode that were provided by previous versions of MSXML.
For Active Server Pages (ASP) programmers, using version-independent ProgIDs can result in unintended upgrades of legacy ASP-based sites to the latest version of MSXML. You can avoid this problem by modifying your Web pages to reference version-dependent programming IDs. For more information, see Workarounds to Version Independence.
In some cases, updating MSXML to use replace mode is intended. More often than not, however, it is too complex to predict the overall impact of a replace mode upgrade on a system. Although some applications might benefit from such an upgrade, other applications might break as a result of it. In many cases, you will not be able to know or fully predict which applications on your system depend on MSXML and will be affected by a replace mode upgrade.
If a customer relies on the built-in XSLT support of Microsoft® Internet Explorer for wide client-side deployment of a Web-based application, replace mode might hide the fact that some client desktops were not upgraded to the appropriate version of MSXML. Therefore, users running previous versions of MSXML replace mode might experience incomplete or incorrect functionality. This means that end users might experience instability in the application, instead of receiving a notification message to "Upgrade to current version MSXML."

"Workarounds to Version Independence"

At least two solutions exist for working around the removal of version independence in MSXML 4.0 and later.
If you are developing for the Windows XP platform, you must use the new side-by-side installation technology to provide manifests for the appropriate version of MSXML and your application. These manifests can simulate the effects of version independence or replace mode.
If you are developing to another Windows platform, you can typically change to version-dependent programming IDs in your Web script or other applications.
The following sections discuss these two situations and some workarounds for each.
Windows XP Side-by-Side Installation
If your are developing applications for Windows XP and want to continue to use MSXML version independence, the side-by-side installation technology provided with Windows XP allows individual applications to reference objects in whatever way you want them to.
Windows XP Side-by-Side installation works by using manifests. A manifest is a small XML file that describes a component or components of an application. This allows you to avoid lookups in the Windows registry, and provides efficient side-by-side functionality without affecting the entire Windows environment.
If you are interested in using side-by-side installation to simulate MSXML version independence or replace mode functionality for MSXML 4.0 or later, you should complete the following steps:
Manually update the MSXML 4.0 or later manifest to make the new object imitate older versions.
Generate a manifest for your application and edit it to use the desired version of MSXML instead of an earlier version.
For more information, see MSXML and Windows, and the Windows XP Side-by-Side installation documentation.
Implementing MSXML in Web Scripting
You should be aware that any linking to a style sheet file from an XML file that uses the <?xsl-stylesheet?> processing instruction will default to using either MSXML 2.0 or MSXML 3.0. However, you can write either server-side or client-side script to use MSXML 4.0 and later versions instead.
[/cite]

Also : entgegen all dem was Mann/Frau mal über OLE/COM gelernt haben mag, reicht hier ein vertrauensvolles ("Msxml2.XMLHttp") nicht um die neueste Version automatisch zu instanziieren.

Ob der IE irgendeine Magic hat, um aus den ( bei mir mittlerweile 4 )Versionen die neueste auszuwählen oder einfach die "kill bited" Version sterben läßt weiss ich nicht, könnte sein aber wie ich Microsoft kenne gibt's einen üblen Fehler der eindeutig auf ein Versäumnis des Programmierers schliessen läßt. ;-(

Klar, war ja auch dem Terabyte von Doku eindeutig zu entnehmen dass die gute alte COM - Konvention nicht mehr gilt... ;-(

Manchmal spinnt MS auch nicht weniger als die Römer.

Grüsse

Holger

P.S.: Jeena, vielen Dank für das Posting !
P.P.S.: ("Msxml2.XMLHttp.6.0") statt ("Msxml6.XMLHttp"). Die VErsion wird angehängt. Das Msxml_2_ bezieht sich - glaub ich auf DOM/SAX 2.

[Jeena Paradies]

Hallo,

P.P.S.: ("Msxml2.XMLHttp.6.0") statt ("Msxml6.XMLHttp"). Die VErsion wird angehängt. Das Msxml_2_ bezieht sich - glaub ich auf DOM/SAX 2.

Aaah, ok, das würde es erklären, danke.

Jeena

[Cybaer]

Hi,

da man immer noch fast überall die "komplexere Syntax" sieht, möchte ich dein Posting nochmals explizit unterstützen! Diese "einfache" Syntax blieb aus Kompatibilitätsgründen (typisch für MS) für alle IEs gültig und für die Zukunft hat sie sich ja eh erledigt (wird aber sicherlich bis in alle Ewigkeit mitgeschleppt werden - s.o.). ;->

Gruß, Cybaer

[derletztekick]

Hallo wahsaga,

Ausserdem hat sich das problem mit dem IE 7, der XMLHttpRequest nativ unterstützt, doch sowieso irgendwann erledigt.

Nicht so ganz, wie ich kürzlich festgestellt habe, als ich lokal eine Datei einlesen wollte. Über das ActiveXObject konnt er es über XMLHttpRequest wiederum nicht.

Mit freundlichem Gruß
Micha