dotnet remoting: Hi there. I'm getting a deserialization error on my app. It was
originally created as a 1.1 app and was upgraded to framework 2.0.
One of our users pointed out that we can no longer open files that
were created long ago (seemingly, before the update to 2.0). Newly
created files work fine. Here's the code and error:

varName= CType(formatter.Deserialize(sStreamPath), className)

This throws an Exception "Unable to load type <<className>> required
for deserialization."
at System.Runtime.Serialization.ObjectManager.DoFixups() at
System.Runtime.Serialization.Formatters.Binary.ObjectReader.Deserialize(HeaderHandler
handler, __BinaryParser serParser, Boolean fCheck, Boolean
isCrossAppDomain, IMethodCallMessage methodCallMessage)
at
System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Deserialize(Stream
serializationStream, HeaderHandler handler, Boolean fCheck, Boolean
isCrossAppDomain, IMethodCallMessage methodCallMessage)
at
System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Deserialize(Stream
serializationStream)
at frmMain.cboSession_SelectedValueChanged(Object sender, EventArgs
e)

The class it's trying to deserialize has custom deserialization code
in it that gets called when a newly created file is reconstituted...
but it never makes it there on the older files.

There have been no substantive changes to the structure of the class -
the only thing I've done over the past few months is explicitly
initialize variables in the constructors and change Int32s to
Integers.

I would have thought that the custom deserializers would take care of
any object signature issues recompling in 2.0 - what am I missing?

Thanks,
Mike Brengartner

Also, when we did the upgrade to .NET 2.0, we changed the project name
as well to make a clean break. Looking in the binary for the files,
that project name information is in the header (and different). Could
that be an issue?