MSXML issues in 64 bit

[mrjaxon]

I have a C# web application which leverages MSXML that I am trying to
migrate to a 64 bit environment. Currently the application is built
on the .NET 2.0 Framework and using MSXML 6 (though I had the same
issues using version 4). The OS I am running the app on is Windows
Server 2003 x64. I am using the x64 version of MSXML 6 on the
server. My dev environment is Windows XP 32 bit SP2. I have tried to
compile the projects for "anycpu" and "x64" with the same results.
The Interop.MSXML2.dll was generated by my dev environment
automatically when I added the MSXML 6 reference to my project.

Essentially whenever the program tries to instantiate a
FreeThreadedDOMDocument40, it throws an exception with the message,
"Object reference not set to instance of an object". I have tried to
use MSXML 4 and 6 (both are installed on the server) with the same
results. The line of code is:

cXMLDOM = new FreeThreadedDOMDocument40Class();

The program seems to be able to find the Interop.MSXML2.dll (I used
FuselogVW.exe to confirm it), but it is still unable to find the
necessary DLLs in the system directories. The msxml6.dll and
msxml6r.dll are present in both the system32 and SysWOW64 directories,
and the application works fine in a 32bit environment.

[Joe Fawcett]

I've no idea but using msxml in .NET is deprecated at best, why not use the
in-built classes?
--

Joe Fawcett (MVP - XML)
http://joe.fawcett.name

<mr*****@gmail.comwrote in message
news:11**********************@e65g2000hsc.googlegr oups.com...

>I have a C# web application which leverages MSXML that I am trying to
migrate to a 64 bit environment. Currently the application is built
on the .NET 2.0 Framework and using MSXML 6 (though I had the same
issues using version 4). The OS I am running the app on is Windows
Server 2003 x64. I am using the x64 version of MSXML 6 on the
server. My dev environment is Windows XP 32 bit SP2. I have tried to
compile the projects for "anycpu" and "x64" with the same results.
The Interop.MSXML2.dll was generated by my dev environment
automatically when I added the MSXML 6 reference to my project.

Essentially whenever the program tries to instantiate a
FreeThreadedDOMDocument40, it throws an exception with the message,
"Object reference not set to instance of an object". I have tried to
use MSXML 4 and 6 (both are installed on the server) with the same
results. The line of code is:

cXMLDOM = new FreeThreadedDOMDocument40Class();

The program seems to be able to find the Interop.MSXML2.dll (I used
FuselogVW.exe to confirm it), but it is still unable to find the
necessary DLLs in the system directories. The msxml6.dll and
msxml6r.dll are present in both the system32 and SysWOW64 directories,
and the application works fine in a 32bit environment.

[mrjaxon]

On May 5, 4:17 am, "Joe Fawcett" <[e-mail]:

I've no idea but using msxml in .NET is deprecated at best, why not use the
in-built classes?

--

Joe Fawcett (MVP - XML)http://joe.fawcett.name

<[e-mail] in message

news:11**********************@e65g2000hsc.googlegr oups.com...

I have a C# web application which leverages MSXML that I am trying to
migrate to a 64 bit environment. Currently the application is built
on the .NET 2.0 Framework and using MSXML 6 (though I had the same
issues using version 4). The OS I am running the app on is Windows
Server 2003 x64. I am using the x64 version of MSXML 6 on the
server. My dev environment is Windows XP 32 bit SP2. I have tried to
compile the projects for "anycpu" and "x64" with the same results.
The Interop.MSXML2.dll was generated by my dev environment
automatically when I added the MSXML 6 reference to my project.

Essentially whenever the program tries to instantiate a
FreeThreadedDOMDocument40, it throws an exception with the message,
"Object reference not set to instance of an object". I have tried to
use MSXML 4 and 6 (both are installed on the server) with the same
results. The line of code is:

cXMLDOM = new FreeThreadedDOMDocument40Class();

The program seems to be able to find the Interop.MSXML2.dll (I used
FuselogVW.exe to confirm it), but it is still unable to find the
necessary DLLs in the system directories. The msxml6.dll and
msxml6r.dll are present in both the system32 and SysWOW64 directories,
and the application works fine in a 32bit environment.

well at this point moving to system.xml is not an option because all
of our stylesheets aren't compliant. that is the eventual plan, but
at this time we need to continue with MSXML 4 or 6.

[zuligag]

On May 7, 7:21 am, [e-mail] wrote:

On May 5, 4:17 am, "Joe Fawcett" <[e-mail]:

I've no idea but using msxml in .NET is deprecated at best, why not use the
in-built classes?

--

Joe Fawcett (MVP - XML)http://joe.fawcett.name

<[e-mail] in message

news:11**********************@e65g2000hsc.googlegr oups.com...

>I have a C# web application which leverages MSXML that I am trying to
migrate to a 64 bit environment. Currently the application is built
on the .NET 2.0 Framework and using MSXML 6 (though I had the same
issues using version 4). The OS I am running the app on is Windows
Server 2003 x64. I am using the x64 version of MSXML 6 on the
server. My dev environment is Windows XP 32 bit SP2. I have tried to
compile the projects for "anycpu" and "x64" with the same results.
The Interop.MSXML2.dll was generated by my dev environment
automatically when I added the MSXML 6 reference to my project.

Essentially whenever the program tries to instantiate a
FreeThreadedDOMDocument40, it throws an exception with the message,
"Object reference not set to instance of an object". I have tried to
use MSXML 4 and 6 (both are installed on the server) with the same
results. The line of code is:

cXMLDOM = new FreeThreadedDOMDocument40Class();

The program seems to be able to find the Interop.MSXML2.dll (I used
FuselogVW.exe to confirm it), but it is still unable to find the
necessary DLLs in the system directories. The msxml6.dll and
msxml6r.dll are present in both the system32 and SysWOW64 directories,
and the application works fine in a 32bit environment.

well at this point moving to system.xml is not an option because all
of our stylesheets aren't compliant. that is the eventual plan, but
at this time we need to continue with MSXML 4 or 6.

- don't use MSXML in multi-threaded code. You may need to use
FreeThreadedDOMDocument. Make sure to stress test before release.
The MSXML/CLR interop issues are likely to only show up under stress/
high-load.

- It has been ages since I played with this, but if I remember
correctly, the best bet is to use tlbimp.exe to generate an interop
assembly against the MSXML interfaces. The CoCreate
MSXML6.DOMDocument (or whatever you need) and cast as the generated
interop classes.... YMMV

-derek

[Alex Krawarik [MSFT]]

I know its not what you want to hear, but managed interop with MSXML has
never been supported by the team, or ever recommended as a possible
solution.

<mr*****@gmail.comwrote in message
news:11**********************@e65g2000hsc.googlegr oups.com...

>I have a C# web application which leverages MSXML that I am trying to
migrate to a 64 bit environment. Currently the application is built
on the .NET 2.0 Framework and using MSXML 6 (though I had the same
issues using version 4). The OS I am running the app on is Windows
Server 2003 x64. I am using the x64 version of MSXML 6 on the
server. My dev environment is Windows XP 32 bit SP2. I have tried to
compile the projects for "anycpu" and "x64" with the same results.
The Interop.MSXML2.dll was generated by my dev environment
automatically when I added the MSXML 6 reference to my project.

Essentially whenever the program tries to instantiate a
FreeThreadedDOMDocument40, it throws an exception with the message,
"Object reference not set to instance of an object". I have tried to
use MSXML 4 and 6 (both are installed on the server) with the same
results. The line of code is:

cXMLDOM = new FreeThreadedDOMDocument40Class();

The program seems to be able to find the Interop.MSXML2.dll (I used
FuselogVW.exe to confirm it), but it is still unable to find the
necessary DLLs in the system directories. The msxml6.dll and
msxml6r.dll are present in both the system32 and SysWOW64 directories,
and the application works fine in a 32bit environment.