# Wednesday, November 19, 2003

The code was all working just fine in test (heh, heh), but in production, suddenly we were getting

exception: System.IO.FileNotFoundException:
File or assembly name ox0vcwlz.dll, or one of its dependencies, was not found.  File name: "ox0vcwlz.dll"
at System.Reflection.Assembly.nLoad(AssemblyName fileName, String codeBase, Boolean isStringized, Evidence assemblySecurity, Boolean throwOnFileNotFound, Assembly locationHint, StackCrawlMark& stackMark) 

Very sad.  Even more interesting was that on each run, the assembly name was different.  OK, probably the XmlSerializer then.  But why did it work in test, and not under other conditions. 

It all became clear when we logged the full exception...  Fusion says:

=== Pre-bind state information ===
LOG: Where-ref bind. Location = C:\WINNT\TEMP\ox0vcwlz.dll
LOG: Appbase = D:\Program Files\XXX
LOG: Initial PrivatePath = NULL
Calling assembly : (Unknown).
LOG: Policy not being applied to reference at this time (private, custom, partial, or location-based assembly bind).
LOG: Attempting download of new URL file:///C:/WINNT/TEMP/ox0vcwlz.dll.

Ah ha!  Turns out the user context we were running under didn't have permissions to the c:\winnt\temp directory.  Ouch.  An easy fix, but not one that was intuitively obvious, at least to me.  I knew that the XmlSerializer created dynamic assemblies, but I didn't know they had to be persisted to disk. 

Something to think about.

Work | XML
Friday, November 21, 2003 10:25:37 AM (Pacific Standard Time, UTC-08:00)
Here's a resource that I've found to be very useful:
Applied XML Programming for MS .Net
by Dino Espisito
There's a whole chapter on XML Serialization and even a section titled "Inside the XML Serializer" that describes the usage of temporary assemblies in the serializtion process.
It's available on the O'Reilly Safari Book Shelf, if you have access to a subscription.
Jim Klein
Wednesday, December 24, 2003 10:42:33 PM (Pacific Standard Time, UTC-08:00)
Or see:


for some hints.

Wednesday, May 05, 2004 2:45:56 PM (Pacific Daylight Time, UTC-07:00)
I ran across this error while trying to deserialize a large xml file to a class file generated by xsd.exe. I found that mine was not a permissions issue, but a whole slew of serializer errors generated because of xsd and the class file that it generated. I found an article on MS support that might be of interest to you.


Pay particular attention to the section about setting the <add name="XmlSerialization.Compilation" value="4"/> switch to the <system.diagnostics> element. I had to do this and then look into the <assembly-name>.out file to find out about all the errors that the serializer was throwing! Crazy, crazy stuff!

Ah well, another day wasted :D

Comments are closed.