On May 7, 7:21 am, mrja...@gmail.com wrote:
> On May 5, 4:17 am, "Joe Fawcett" <joefawc...@newsgroup.nospam> wrote:
>
> > 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
>
> > <mrja...@gmail.com> wrote in message
>
> >news:1178299721.619902.148920@e......
>
> > >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