XmlSerializer Sporadic Error in IIS Web Service RRS feed

  • Question

  • I am running a web service that gathers data for other web services and serializes the objects to xml to be returned to the calling application.  Everything works fine.  However, we see the error below.  I believe it happens when the IIS web application gets restarted and multiple threads are trying to interact with the Dll that gets created by the XmlSerializer class at run time.  I am unable to reproduce the issue in our test environments and looking for guidance on how to recreate issue and also how to fix it.


    Type: System.IO.IOException, mscorlib, Version=, Culture=neutral, PublicKeyToken=b77a5c561934e089
    Message: The process cannot access the file because it is being used by another process. (Exception from HRESULT: 0x80070020)
    Source: mscorlib
    Data : System.Collections.ListDictionaryInternal
    TargetSite : Void SavePEFile(System.Reflection.RuntimeModule, System.String, Int32, Int32, Boolean)
    HResult : -2146232800
    StackTrace :    at System.Reflection.Emit.ModuleBuilder.SavePEFile(RuntimeModule module, String fileName, Int32 entryPoint, Int32 isExe, Boolean isManifestFile)
       at System.Reflection.Emit.ModuleBuilder.Save(String fileName, Boolean isAssemblyFile, PortableExecutableKinds portableExecutableKind, ImageFileMachine imageFileMachine)
       at System.Reflection.Emit.AssemblyBuilder.SaveNoLock(String assemblyFileName, PortableExecutableKinds portableExecutableKind, ImageFileMachine imageFileMachine)
       at System.Reflection.Emit.AssemblyBuilder.Save(String assemblyFileName, PortableExecutableKinds portableExecutableKind, ImageFileMachine imageFileMachine)
       at System.Xml.Serialization.TempAssembly.GenerateRefEmitAssembly(XmlMapping[] xmlMappings, Type[] types, String defaultNamespace, Evidence evidence)
       at System.Xml.Serialization.TempAssembly..ctor(XmlMapping[] xmlMappings, Type[] types, String defaultNamespace, String location, Evidence evidence)
       at System.Xml.Serialization.XmlSerializer.GenerateTempAssembly(XmlMapping xmlMapping, Type type, String defaultNamespace)
       at System.Xml.Serialization.XmlSerializer..ctor(Type type, String defaultNamespace)
       at WebServiceSerializer<T>`1.SerializeObject(T objectToSaveToXml)


    public static class WebServiceSerializer<T> where T : class 
            public static string SerializeObject(T objectToSaveToXml)
                System.Xml.Serialization.XmlSerializer serializer = new System.Xml.Serialization.XmlSerializer(objectToSaveToXml.GetType(), string.Empty);

                using (System.IO.StringWriter writer = new Utf8StringWriter())
                    serializer.Serialize(writer, objectToSaveToXml);

                    return writer.ToString();


    • Moved by CoolDadTx Wednesday, December 20, 2017 2:59 PM ASP.NET related
    Tuesday, December 19, 2017 6:30 PM

All replies

  • Note that the constructor of recent XmlSerializer includes a lock block — https://referencesource.microsoft.com/#System.Xml/System/Xml/Serialization/XmlSerializer.cs,c57fd2fc59cc707b — therefore GenerateTempAssembly and the rest of the code is not executed in parallel, unless some other child threads are further invoked.

    To reproduce the problem, maybe create two or more parallel processes, not threads. Thought, it is possible that processes create different files.

    Maybe the problem is caused by some antivirus software. The workaround is to retry the operation.

    The documentation for XmlSerializer also shows that the serializers for each type can be cached and reused.

    Tuesday, December 19, 2017 9:00 PM
  • Please post questions related to hosting and running apps in IIS in the ASP.NET forums.

    Michael Taylor http://www.michaeltaylorp3.net

    Wednesday, December 20, 2017 2:59 PM
  • We did try the retry option thinking it might be the anti virus software but we still see the error on occasion. Do you think moving the directory that the temp assembly is located would help fix the issue? We have not tried that yet.
    Wednesday, December 20, 2017 7:57 PM