As per request, this is the official resurrection of the \"File in Use\" exception arising when working with MemoryStreams that have had XMLDocument .Save() on the stream explicitly.
\nPrevious report and example are in http://dotnetzip.codeplex.com/discussions/44663
\nNotably, I can always reproduce this behavior, namely, unless I null the XMLDoc and call out GC.Collect the subsequent zip.Save() will always fail. I have tried staggering the thread (simulating \"old\" computer that seemed to work for previous poster), sleeping, and even copying memory streams to no avail. XMLDocument has no IDisposable or Close implementations, so \"using\" is out the window.
\nFYI,Windows7 + VS2010 Express C# with 4.0NETClient target. Also using latest available DotNetZip (reduced) assembly dll.
\nHere is the code:
\n\n
MemoryStream stream_core = new MemoryStream();\nXmlDocument xmldoc_core = new XmlDocument();\n\n// We actually check if extracting worked in the working sample\nZipEntry e_core = zip[\"\\\\somepath\\\\somefile.xml\"];\ne_core.Extract(stream_core);\nstream_core.Seek(0, SeekOrigin.Begin);\n\n// This is validated too\nxmldoc_core.Load(stream_core);\n\n// This class function takes the xmldocument and modifies ut by appending some nodes, nothing fancy.\nxmldoc_core = update_document(xmldoc_core, \"1\", \"2\", \"3\", textBoxRevision.Text);\n// xmldoc is valid, commence pushback\n\nMemoryStream stream_o_core = new MemoryStream();\n\n// save to another stream\nxmldoc_core.Save(stream_o_core);\n\n// If this is uncommented, Saving works\n// xmldoc_core = null;\n// GC.Collect();\n\n// Rewind\nstream_o_core.Seek(0, SeekOrigin.Begin);\n\n// Remove and re-add\nzip.RemoveEntry(\"\\\\somepath\\\\somefile.xml\");\nzip.AddEntry(\"\\\\somepath\\\\somefile.xml\", stream_o_core);\n\n// This will fail with IOException = sharing violation, file in use\nzip.Save();\n\n
Please let me know what other details you need.
\nRespectfully,
\nK.
", "PostedDate": "2011-02-23T21:22:51.993-08:00", "UserRole": null, "MarkedAsAnswerDate": null }, { "Id": "573430", "ThreadId": "247356", "Html": "Hi kommi,
\r\nI think the problem is that internally the XmlDocument.Save method wraps your stream in an Xml.XmlDOMWriter to perform the save, but it doesn't call Close / Dispose afterwards. I don't know if this is a bug, or whether it's by design, but it's probably what is causing the sharing violation by holding a reference to your stream_o_core until you kill the XmlDOMWriter with an explicit call to GC.Collect().
\r\nIt sounds like the garbage collector is probably more aggressive on slower machines (maybe because of less memory?) and calls GC.Collect() itself before the code gets to enter zip.Save().
\r\nHope this helps,
\r\nMike
", "PostedDate": "2011-02-28T11:45:31.12-08:00", "UserRole": null, "MarkedAsAnswerDate": null }, { "Id": "573530", "ThreadId": "247356", "Html": "Uhm, that would make sense, but what does .Save() of DotNetZip is actually doing to the MemoryStream to get the sharing violation? Should I instead explicitly instantiate an XMLWriter, write to stream, close the Writer and then pass the MemoryStream to DotNetZip? (XMLWriter does have a close)
", "PostedDate": "2011-02-28T14:30:51.667-08:00", "UserRole": null, "MarkedAsAnswerDate": null }, { "Id": "573570", "ThreadId": "247356", "Html": "Hi kommi,
\r\nIt's probably just trying to read data from the stream to zip it up, but if the XmlDocument it stream locked with \"Sharing = None\" then the zip object won't be able to read from it until the XmlDOMWriter is closed. I don't really have time at the moment to dig too deep into it at the moment, but you could try replicating the behaviour of XmlDocument.Save, and closing the XmlDOMWriter afterwards. Or you could copy the data from stream_o_core into a separate memorystream and pass that to DotNetZip.
\r\nI can take another look if you can post a stack trace of the exception, but your best bet might just be to live with GC.Collect for now.
\r\nCheers,
\r\nM
", "PostedDate": "2011-02-28T16:14:42.013-08:00", "UserRole": null, "MarkedAsAnswerDate": null }, { "Id": "574017", "ThreadId": "247356", "Html": "Ill try your suggestions, it's very hard to debug though: it happens sporadically, for example, right now I can not trigger the sharing violation to occur at all. Speaking of which, if stream is locked with no sharing, then I wouldn't be able to clone it either, no?
", "PostedDate": "2011-03-01T11:43:38.287-08:00", "UserRole": null, "MarkedAsAnswerDate": null }, { "Id": "574059", "ThreadId": "247356", "Html": "Possibly. I guess it depends on what locks XmlDOMWriter holds vs the ones DotNetZip wants. e.g. if DotNetZip wants Write even though it only needs Read then you might be able to get away with copying just using Read access. You might have to suck it and see...
\r\nImplementing your own version of XmlDocument.Save is probably the \"best\" workaround. It's only half a dozen lines of code anyway.
\r\nM
", "PostedDate": "2011-03-01T12:39:52.053-08:00", "UserRole": null, "MarkedAsAnswerDate": null }, { "Id": "577805", "ThreadId": "247356", "Html": "Seems to me you would want to try using the ZipFile.AddEntry() method that accepts a WriteDelegate.
\r\nIn that case you would not need the extra stream. I guess the code would look something like this:
\r\nXmlDocument xmldoc_core = new XmlDocument();\r\n using (MemoryStream ms1 = new MemoryStream()) \r\n {\r\n // We actually check if extracting worked in the working sample\r\n zip[\"\\\\somepath\\\\somefile.xml\"].Extract(ms); \r\n ms1.Seek(0, SeekOrigin.Begin);\r\n\r\n xmldoc_core.Load(ms1);\r\n }\r\n // This class function takes the xmldocument and modifies it by\r\n // appending some nodes, nothing fancy.\r\n \r\n xmldoc_core = update_document(xmldoc_core, \"1\", \"2\", \"3\", textBoxRevision.Text);\r\n // xmldoc is valid, commence pushback\r\n\r\n // ** Note 1: Why assign the output of the above? If the method\r\n // simply modifies the XmlDocument, why do you need to assign\r\n // the value? Check your implementation.\r\n \r\n // Remove and re-add\r\n zip.RemoveEntry(\"\\\\somepath\\\\somefile.xml\");\r\n zip.AddEntry(\"\\\\somepath\\\\somefile.xml\", (name,stream) => {\r\n xmldoc_core.Save(stream);\r\n });\r\n\r\n // This will fail with IOException = sharing violation, file in use\r\n zip.Save();\r\n\r\n\r\n