Safe place for XmlSerializer to save temporary files

To my attention, XmlSerializer should use disk space to execute its bets. If there is no folder for writing% temp%, then it does not work 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] 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 folder permissions is what I think is best left to the user, rather than a patch for the dodgy serializer, so instead I want to fix this problem by letting the serializer write its shit somewhere else. 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 for this setting that will not work on some client machines? If not, what are my alternatives? Does DataContractJsonSerializer match disk space in the same way?

+4
source share
1 answer

DataContractSerializer, NetDataContractSerializer and DataContractJsonSerializer are 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 to serialize and deserialize everything inside the AppDomain in which they work. XmlSerializer really requires disk space, as you know. On the plus side, you don't need to change any of your types - just replace the serializer, and you should be fine, because the DataContractSerializer supports the serialization formats, models and paradigms of all the other serializers that Microsoft has ever sent to .NET

+3
source

All Articles