Yes, I agree I need to build xerces using visual studio .net 2003. Has any one done this before? Sometime the upgrade from 02 to 03 occurs automatically without errors, but I got tons of errors when I compiled, particularly with the namespaces... Virginia
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, June 26, 2003 6:04 PM To: [EMAIL PROTECTED] Subject: Re: Running xerces from VS .net 2003 / XMLString::transcode delete > Hello- > I am running on Windows XP. We recently upgraded our development environment > to VS .net 2003. Since we upgraded, I have been having a problem where a debug > assert occurs when we delete a string created by XMLString::transcode. I noticed a > note about this on http://xml.apache.org/xerces-c/faq-build.html#faq-12 . I see the > problem in xerces 1.6 and in xerces 2.3 (I upgraded trying to solve the problem.) > > 1) Why did this used to work and why does it not work any more? Did you rebuild Xerces-C using VS .net 2003? If not, you should, or else there will be two memory heaps, and you will get all sorts of problems. > 2) For for strings created by XMLString::transcode I can deallocate them using > XMLString::release as suggested in the link above, however I have the same debug > assert with the delete of an SAX2XMLREADER created by XMLReaderFactory::createXMLReader, > and that has no release method for me to switch to. createXMLReader's comment even > says I'm supposed to delete it myself. That's why the XMLString::release() is just a stop-gap. It doesn't really solve all of the problems with having separate heaps. > 3) Is the problem really because xerces-c comes with a VS .net 2002 xerces-all.sln > (solution) file with which to compile it, and my code is using vs .net 2003? So I am > calling a vs02 created dll from a vs03 created dll. Yes, that's the problem. Each uses a different version of the runtime, so each has its own heap. > 4) As an interesting side note, when I did compile the xerces-all.sln in VS .net 2002 > that came with the source code it would not link with out unresolved externals until > I commented out the unimplemented copy constructor of XMemory in XMemory.hpp I think these compilations problems are fixed in the latest CVS code. Dave --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
