XmlSerializer 保存临时文件的最安全位置
我注意到 XmlSerializer 需要使用磁盘空间来执行其命令。如果没有可写的 %temp% 文件夹,则会失败并出现如下错误:
源:System.Xml 消息:无法生成临时类(结果=1)。错误CS2001:找不到源文件'C:\ Windows \ TEMP \ c1ls4elp.0.cs'错误CS2008:没有指定输入StackTrace:在System.Xml.Serialization.Compiler.Compile(Assemblyparent,String ns,XmlSerializerCompilerParameters xmlParameters ,证据证据)在System.Xml.Serialization.TempAssembly.GenerateAssembly(XmlMapping[] xmlMappings、Type[] 类型、String defaultNamespace、证据证据、XmlSerializerCompilerParameters 参数、程序集程序集、哈希表程序集)位于 System.Xml.Serialization.XmlSerializer.GenerateTempAssembly(XmlMapping xmlMapping、类型)类型,字符串默认命名空间)位于System.Xml.Serialization.XmlSerializer..ctor(类型类型,字符串defaultNamespace)在StreamLib.Tuna.SerializationHelper.Deserialize [T](字符串预设字符串)...
供参考,StreamLib 的实现。 Tuna.SerializationHelper.Deserialize[T]
如下所示:
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;
}
}
}
我认为更改文件夹权限最好留给用户,而不是修补程序狡猾的序列化程序,所以我想通过将序列化程序放在其他地方来写入其临时文件来解决问题。这可以通过将以下内容添加到 app.config/web.config
来实现:
<system.xml.serialization>
<xmlSerializer tempFilesLocation="c:\\foo"/>
</system.xml.serialization>
我的问题是,是否有一个防弹位置用于此设置,并且在某些客户端计算机上不会失败?如果没有,我有什么选择? DataContractJsonSerializer
是否也以同样的方式需要磁盘空间?
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 tempfiles. 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?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
DataContractSerializer、NetDataContractSerializer 和 DataContractJsonSerializer 都是您不错的选择。它们不需要磁盘空间,也不会将程序集发送到磁盘。相反,它们会动态生成 IL(在内存中),并在后续序列化过程中使用它来在它们正在操作的 AppDomain 内进行序列化和反序列化。正如您所发现的,XmlSerializer 确实需要磁盘空间。从好的方面来说,您不需要更改任何类型 - 只需替换序列化器就可以了,因为 DataContractSerializer 支持 Microsoft 发布的所有其他序列化器的序列化格式、模型和范例在.NET中
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