Safest place for the XmlSerializer to save temp fi

It's come to my attention that the XmlSerializer needs to use disk space to do its bidding. If there is no writeable %temp% folder, then it fails with an error as follows:

Source : System.Xml Message : Unable to generate a temporary class (result=1). error CS2001: Source file 'C:\Windows\TEMP\c1ls4elp.0.cs' could not be found error CS2008: No inputs specified StackTrace : at System.Xml.Serialization.Compiler.Compile(Assembly parent, String ns, XmlSerializerCompilerParameters xmlParameters, Evidence evidence) at System.Xml.Serialization.TempAssembly.GenerateAssembly(XmlMapping[] xmlMappings, Type[] types, String defaultNamespace, Evidence evidence, XmlSerializerCompilerParameters parameters, Assembly assembly, Hashtable assemblies) at System.Xml.Serialization.XmlSerializer.GenerateTempAssembly(XmlMapping xmlMapping, Type type, String defaultNamespace) at System.Xml.Serialization.XmlSerializer..ctor(Type type, String defaultNamespace) at StreamLib.Tuna.SerializationHelper.Deserialize[T](String presetsString) ...

For reference, the implementation of StreamLib.Tuna.SerializationHelper.Deserialize[T] looks as follows:

    public static T Deserialize<T>(this string data) where T:class
    {
        var type = typeof(T);

        XmlSerializer serializer = new XmlSerializer(type);
        using (TextReader reader = new StringReader(data))
        {
            try
            {
                return (T)serializer.Deserialize(reader);

            }
            catch
            {

                return null;
            }
        }
    }

Changing permissions of folders is something I think best left to the user rather than a patch for a dodgy serializer, so instead I want to fix the problem by giving the serializer somewhere else to write its crap. This can be achieved by adding the following to app.config/web.config:

<system.xml.serialization> 
  <xmlSerializer tempFilesLocation="c:\\foo"/> 
</system.xml.serialization>

My question is, is there a bulletproof location use for this setting that won't fail on some client machines? If not, what are my alternatives? Does the DataContractJsonSerializer also require disk space in the same way?

DataContractSerializer, NetDataContractSerializer and DataContractJsonSerializer would all be good alternatives for you. They do NOT require disk space and do NOT emit assemblies to disk. Instead, they generate IL on the fly (in memory) and use it during subsequent serialization episodes to do serialization and deserialization all within the AppDomain they're operating in. XmlSerializer does require disk space, as you found out. On the plus side, you shouldn't need to change any of your types -- just replace the serializer and you should be good to go, since DataContractSerializer supports the serialization formats, models and paradigms of all the other serializers that Microsoft has ever shipped in .NET