XmlSerializer initiated with given type returns object of different type (other assembly)

[Philipp Sumi]

Hello Newsgroup

I have a strange situation with a VS.net Add-In that uses the
XmlSerializer class for deserialization. As the problem seems to be the
same for the Add-In as for designers, I thought I might be lucky here...

In the code below, I pass a given type to the serializer class. However,
the type of the object that is returned by the serializer is a different
one so I cannot cast it.

//get the type -> same problem with typeof(...)
MappedObjectNode node = new MappedObjectNode();
Type type = node.GetType();

//store assembly location
string loc1 = type.Assembly.Location;

XmlSerializer serializer = new XmlSerializer(type);
using (Stream stream = file.OpenRead())
{
//perform deserialization
object obj = serializer.Deserialize(stream);

//get assembly location
string loc2 = obj.GetType().Assembly.Location;
}

When running this code, the strings loc1 and loc2 are different. VS.net
creates some kind of shadow copies for the add-in. However, the
serializer and the add-in use different assemblies:

loc1 (object created in add-in):
c:\dokumente und einstellungen\sumi\
lokale einstellungen\anwendungsdaten\assembly\
dl2\2dao39nh.tnl\4ehanxn5.m8y\
3bed8731\d814a9c3_828fc401\dao.net.dll

loc2 (object created by serializer):
c:\dokumente und einstellungen\sumi\
anwendungsdaten\microsoft\visualstudio\7.1\
projectassemblies\qcwp2ofq01\dao.net.dll

Strange enough, if I don't touch my solution and immediately open the
add-in, the copy within the "visualstudio\7.1"-folder is not being used
(loc1 and loc2 are the same as loc1 above) and my cast succeeds. This
works fine for me, but the add-in is part of an open-source project
which will hopefully be used by many people...

Right now, I'm stuck - any suggestion is highly appreciated

Thanks for your advice

Philipp

[Frank Hileman]

Hello Philipp,

You are correct that Visual Studio uses shadow copies. We found this problem
with custom designers, not with add-ins. But perhaps the same problem exists
for add-ins.

Usually when you have a type mismatch VS is loading one via LoadFrom and one
via the normal mechanism. In this case the CLR thinks they are two different
dlls and gives a different identity to the same type from each. I am not
sure what is going on in your situation, but the best solution we found is
to make sure problematic dlls are strongly named and stored in the GAC. We
do not do this with our add-ins, but we do this with our designer dlls.

If your tool uses reflection then you may have even more problems. If you
can redesign to avoid that reflection based serializer, and instead do your
own custom serialization to xml, you may have better luck.

Best of luck,
Frank Hileman

check out VG.net: www.vgdotnet.com
Animated vector graphics system
Integrated Visual Studio .NET graphics editor

"Philipp Sumi" <spam...@thisdomaindoesntexist.org> wrote in message
news:efTy$5OuEH...@tk2msftngp13.phx.gbl...

[Philipp Sumi]

Hi Frank

Thanks for your reply. The GAC solution works very well, thanks for this
one :-)

However, i came up with a simpler solution that works for now - as my
add-in only needs a very small subset of the referenced library, I added
a link to the needed classes to my add-in project and compiled them
right into the add-in assembly. This works very well and I don't have to
install anything into the GAC by now. Of course, this solution doesn't
scale very well - if the add-in gets more complex, I will have to fall
back to the GAC...

Best wishes

Philipp