Hi,
We have a product written in C# that we are migrating to Visual Studio 2005
(beta 2) and .NET 2.0. Everything builds fine, but during runtime we are
hitting a new exception. When it is deserializing a some classes from disk
that were serialized with the .NET 1.1 version, we are now getting a
SerializationException() saying that it can't find our assembly. Our
assemblies are strongly-named, and we bump the assembly version in each
build, so we already dealt with this problem earlier by writing a
AppDomain.AssemblyResolve event handler which returns the correct assemblies.
The problem is that with .NET 2.0 our handler is no longer being invoked! Is
this a known issue with a known workaround? Is there another way to avoiding
this versioning problem with serialization in .NET 2.0?
--Matt Zinkevicius
Francisco Padron - 28 May 2005 19:29 GMT
I'm using AppDomain.AssemblyResolve in my app and it works fine for me, it
gets called whenever an assembly is not found.
So if there is a bug, there must be something more specific to what you are
trying to do.

Signature
Francisco Padron
www.chartfx.com
> Hi,
> We have a product written in C# that we are migrating to Visual Studio
[quoted text clipped - 14 lines]
>
> --Matt Zinkevicius
Daniel PS - 29 Jun 2005 13:45 GMT
Hi Matt,
I have exactly the same problem, but it has nothing to do with versioning.
When you serialize an object, the runtime writes the assemby information to
the stream. If these assemblies were loaded from other directories than the
main directory you have a problem with deserialization. I solved the problem
in 1.1 with appending all folders of my plugin assemblies
(AppDomain.CurrentDomain.AppendPrivateBinPath).
This will help you for now. The very bad thing about this solution is, that
it will not work with the .Net 2.0 final, because the Method is marked as
deprecated.
Instead of using this method you are supposed to use
AppDomain.CurrentDomain.SetupInformation.PriateBinPath.
The only drawback about that is you can't use this way for the
DefaultAppDomain.
> Hi,
> We have a product written in C# that we are migrating to Visual Studio 2005
[quoted text clipped - 10 lines]
>
> --Matt Zinkevicius
Richard Blewett [DevelopMentor] - 29 Jun 2005 21:40 GMT
Just because its been deprecated doesn't mean its not going to be there - it just means *at some point in the future is going to be pulled* In v2 you can do the same thing with an AppDomainManager which can also be used with the default domain Regards Richard Blewett - DevelopMentor
http://www.dotnetconsult.co.uk/weblog
http://www.dotnetconsult.co.uk Hi Matt,
I have exactly the same problem, but it has nothing to do with versioning.
When you serialize an object, the runtime writes the assemby information to
the stream. If these assemblies were loaded from other directories than the
main directory you have a problem with deserialization. I solved the problem
in 1.1 with appending all folders of my plugin assemblies
(AppDomain.CurrentDomain.AppendPrivateBinPath).
This will help you for now. The very bad thing about this solution is, that
it will not work with the .Net 2.0 final, because the Method is marked as
deprecated.
Instead of using this method you are supposed to use
AppDomain.CurrentDomain.SetupInformation.PriateBinPath.
The only drawback about that is you can't use this way for the
DefaultAppDomain.