views:

43

answers:

2

Hello,

I have a problem with xml-deserialization and dynamically loaded assemblys. I load my assembly directly from a zip-file to a byte array. Then i load this assembly. The assembly contains a data-model, which should be deserialized with XmlSerializer. The problem is that I always get an TypeInitializationException, if i try to load my xml.

The german exception is following:

System.InvalidOperationException: Fehler im XML-Dokument (62,13). ---> System.TypeInitializationException: Der Typeninitialisierer für "Microsoft.Xml.Serialization.GeneratedAssembly.XmlSerializationReaderOrder" hat eine Ausnahme verursacht. ---> System.NullReferenceException: Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt.

bei Microsoft.Xml.Serialization.GeneratedAssembly.XmlSerializationReaderOrder..cctor()

If i load my dll directly from a dll-file, and not from a zip into a byte-array, the xml could be sucessfully deserialized.

I the internet i found, that the problem could be Lists with own types, but the solutions i found there didn't solve my problem.

It would be great, if somebody could help me.

Thanks, Martin

EDIT:

I've found that I couldn't use generic Lists with own types, if I load the assembly via byte-array, as it is written on other website. I couldn't say, why I first hadn't success with this solutions, but after a second try it works. I've made a workaround with ArrayList, but im very unhappy with this. Is there a better solution, where I can use generic lists? Or if there isn't a better solution, is there a better Serializer/Deserializer for XML?

A: 

I got around this by using sgen to create serialization assemblies (*.XmlSerializers.dll) for each assembly that contained types I want to serialize and including them with my app whenever I do any XmlSerialization. Then make sure they exist in your bin path at runtime. XmlSerialization probes for the *.XmlSerializers.dll and uses these serialization types instead of creating them at runtime.

Wil P
The problem is that there shouldn't be a plugin specific-dll in the bin-path. My intention is that all plugin-specific things are loaded from the zip-file directly.
martin
Can you create serialization assemblies for your plugin dlls and load them at the same time you load the plugin dll from the zip?
Wil P
This could be possible, i will check this.
martin
A: 

what you get when you load a zip into a byte[] is a byte[] of the zip not the assembly, decompress the zip first. You can use something like http://dotnetzip.codeplex.com ), a free 3rd-party library, to create and read zip files from within any .NET application. . .

   string unpackDirectory = "ExtractedFiles";      
   using (ZipFile zip1 = ZipFile.Read(zipToUnpack))      
   {
       // here, we extract every entry, but we could extract conditionally          
       // based on entry name, size, date, checkbox status, etc.            
       foreach (ZipEntry e in zip1)          
       {            
           e.Extract(unpackDirectory, ExtractExistingFileAction.OverwriteSilently);          
       }      
    }
almog.ori
I do not load the zip as byte[], i load the dll from the zip as byte[], using SharpZipLib
martin
do you own the model type ie 1.can you give code sample, 2. what attributes applied? are you using xslt transform techniques? what other types does that type reference? you may have to use the other ctor of XmlSerializer to pass known types...
almog.ori