I don't understand why this code works within a normal exe test application but it doesn't work in a DLL (it returns the exception in deserialization: unable to find assembly (InvisibleLists....etc.. ):
Config.SaveOption(cmb.Items); DataListView[] data = Config.LoadOptions(); ... [Serializable] { ... } |
Note: the DLL is composed by 3 files and 1 of them contains the DataListView class that is the one that is serialized.
I solved the problem by forcing an assembly load like this:
AppDomain.CurrentDomain.AssemblyResolve += new ResolveEventHandler(MyResolveEventHandler); static Assembly MyResolveEventHandler(object sender, ResolveEventArgs args) { Assembly a = null; string serializationAssemblyPartialName = "InvisibleLists"; if (args.Name.IndexOf(serializationAssemblyPartialName) != -1) { string sSerializersDLL = "InvisibleLists.dll"; string smartDeploymentHostLocation = @"c:\"; a = Assembly.LoadFrom(smartDeploymentHostLocation + sSerializersDLL); } return a; } |
Could someone explain me why do I need to do this
Thank you in advance,
Ricardo Sabino.
Deserialization problem in DLL (unable to find assembly)
werner5
If you use serialization for communication, the dll should be on both ends. In your exe, there is only one assembly, it's already load, the serializer can find the type info.
PanBocian
it would be easier, just set a reference to that dll, then Visual Studio will put that dependent dll there, in the build, the dll would be loaded, when you run the application.
Barb M
I would but this is just a simple plugin I'm developing for Messenger Plus! (MsgPlus)that's also a plugin for MSN Messenger so.. I gess I'll have to do it the way I described in the first post.
I also have other question but this one doesn't have anything to do with serializing and I don't know if this is the right place to ask so, if not I appologize right away.
MsgPlus is a plugin made in c++ and there are some plugins for MsgPlus that are made in c# and what happens is that when initializing the plugins, only one of the c# stays visible in the Plus! plugin's list. What I suspect is that this has something to do with AppDomains. Is there a collision between plugin's appdomains if they're all loaded with a default AppDomain
Another thing is that a c# plugin can't be unloaded without closing msn messenger but this I've almost sure that it's because the AppDomain isn't unloaded by MsgPlus since it wasn't made thinking in these plugins.
Since I don't want to be sent to the MsgPlus as I was when posted in MSN Development section of these forums, just think of it has being a c++ dll that loads c# plugins:
1- is there a problem with appdomains when loading multiple c# plugins (since no appdomains are being used and so the .net framework just loads the default appdomain for the dll)
2- how can this be solved (I know to solve it in c#, just have a appdomain and load the assemblies of the secondary appdomains (the dll's appdomains) but I don't know how to do this since it has to be done by the c++ code)
(I already asked these questions at the MsgPlus forums but nobody knows the answer for this or if someone does, didn't reply to me yet).
I'm sorry if this isn't the appropriate place to ask this.
Thank you,
Ricardo Sabino.
Manlovefox
I don't anything about Messenger plugins. Using plugins does not create new appdomains, the plugin dll's are loaded into the default appdomain, there can be multiple assemblies load into the default appdomain, they do not require their own domains, multiple appdomains would require marshalling cross appdomain, only complicate things.
It's is really simple to use plugins with .NET Winform applications, just define an interface for the plugin to implement, then build the dll, place the dll in the folder, the host .exe should have code, so it will look for all the dll's in the folder, find those have implemented the plugin interface, load the dll into the domain of the host .exe, and also add a menu item, or a button, to invoke the plugin. It's really a powerful, flexible way of creating extensible applications.
I don't know the rules for Messenger plugins. There should be some doc for it. As for unloading, maybe by designed. I use plugins, but have never thought of unloading.
Let's hope some one who knows Messenger plugins well will see your post, and give an expert answer.
DaveGoliath
i didn't realize that I was calling this in a function where the dll hasn't been fully loaded (it was in fact an initialize function).
Just to double check I tested the code in other part of the code that would only be called with the dll loaded and it worked without having to indicate where the dll was.
Once again, thank you for your time and help.
Ricardo Sabino.