[Webinar] Streamline your web hosting managementRegister Today

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1946
  • Last Modified:

URGENT! Breaking Changes - .Net 1.1 -> 2.0 Remoting --> SerializationException - Unable to find Assembly

Hi there,

I need some urgent help with this and hopefully one of you guys have come across similar:
In .Net 1.1 the object I was passing to another process via remoting worked fine, I upgrade to .net 2.0 and discover that whenever I pass the object to the other process I get a SerializationException, informing me it is Unable to find Assembly.

The assembly *is* in the same directory as both processes and is the same version listed, I can see no reason why I am getting this, I have taken the object and run it through a test remoting project and it's worked absolutely fine.

Any help would be greatly appreciated, I will take all suggestions!

Cheers

Wint
(The exception I get follows)
//
//EXCEPTION
//
 Exception: System.Runtime.Serialization.SerializationException: Unable to find assembly 'MyAssembly, Version=1.0.2293.19593, Culture=neutral, PublicKeyToken=null'.

Server stack trace:
   at System.Runtime.Serialization.Formatters.Binary.BinaryAssemblyInfo.GetAssembly()
   at System.Runtime.Serialization.Formatters.Binary.ObjectReader.GetType(BinaryAssemblyInfo assemblyInfo, String name)
   at System.Runtime.Serialization.Formatters.Binary.ObjectMap..ctor(String objectName, String[] memberNames, BinaryTypeEnum[] binaryTypeEnumA, Object[] typeInformationA, Int32[] memberAssemIds, ObjectReader objectReader, Int32 objectId, BinaryAssemblyInfo assemblyInfo, SizedArray assemIdToAssemblyTable)
   at System.Runtime.Serialization.Formatters.Binary.__BinaryParser.ReadObjectWithMapTyped(BinaryObjectWithMapTyped record)
   at System.Runtime.Serialization.Formatters.Binary.__BinaryParser.ReadObjectWithMapTyped(BinaryHeaderEnum binaryHeaderEnum)
   at System.Runtime.Serialization.Formatters.Binary.__BinaryParser.Run()
   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.Remoting.Channels.CoreChannel.DeserializeBinaryRequestMessage(String objectUri, Stream inputStream, Boolean bStrictBinding, TypeFilterLevel securityLevel)
   at System.Runtime.Remoting.Channels.BinaryServerFormatterSink.ProcessMessage(IServerChannelSinkStack sinkStack, IMessage requestMsg, ITransportHeaders requestHeaders, Stream requestStream, IMessage& responseMsg, ITransportHeaders& responseHeaders, Stream& responseStream)
0
WinterMuteUK
Asked:
WinterMuteUK
1 Solution
 
enwhyseeCommented:
This is possibly a known issue/bug that is documented here:
http://lab.msdn.microsoft.com/ProductFeedback/viewFeedback.aspx?feedbackid=b08b64df-49f2-44a3-ac10-7811281eb149

It seems to have to do with a version mismatch of the client and the server. In other words, it sounds like you have to rebuild both the client and the server to make this work.

There are a few workarounds mentioned, one of them being this:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconassemblybindingredirection.asp
0
 
WinterMuteUKAuthor Commented:
Hi enwhysee,

Yes, I've looked at the BinaryFormatter problem listed on the product feedback page, but it's not quite the same issue. Both my client and server in this case have been built from scratch and each references the same project i.e.:

  Server |
            |-- reference --> MyObject (Project)
  Client   |
 
As they are referencing the project I can force them to rebuild just by adding a space etc to the MyObject project. If I look at the relative copies of the dlls in the server/client bin/debug dirs, I can see they are the same version, size everything.

I'm going to look into the AssemblyBindingRedirection thing, and the AssemblyResolve event.

In the mean time anything else??!!

Thanks

Wint.
0
 
vo1dCommented:
have you checked your referenced assemblies in your project? are all assemblies are version 2.0?
0
The new generation of project management tools

With monday.com’s project management tool, you can see what everyone on your team is working in a single glance. Its intuitive dashboards are customizable, so you can create systems that work for you.

 
WinterMuteUKAuthor Commented:
Hi Vo1d,

Yes, everything being referenced is .net 2.0, the solution is a closed solution in the sense that all the projects are within the solution itself.

Cheers
Wint
0
 
vo1dCommented:
and do you referenced that 'MyAssembly' ?
if so, have you checked the version number in the assemblyinfo?
0
 
WinterMuteUKAuthor Commented:
I reference the project that compiles to 'MyAssembly' yes, as I mentioned originally, the version numbers are the same.
By hooking up to the 'AssemblyResolve' event I can see the assembly it is trying to load is the correct one, from the correct location.

Wint
0
 
WinterMuteUKAuthor Commented:
Just to give you guys an update on the situation, I've managed to get the serialization working, albeit in a way I'm not too happy with, well, actually I've managed to make it work in two ways:

  1. Using the GAC
      - If I put the assembly into the GAC the serialization worked fine, unfortunately this is inpractical and not what I want to do, but it does show the code is ok I guess :)

  2. By inserting a new local variable into the constructor of the 'receiving' server, for example:

    Client sends MyObject to Server, server throws exception, by adding this line to the constructor of the server:
       ..{
            MyObject o;
            //More code
         }
    when the client now sends the object to the server, there are no problems.

I've currently implemented solution 2 as it's easily added to the source control and prevents any changes to the way the team works. However, I still don't know *why* this solves the problem.

Has it changed the order of the compilation?
??

Cheers Wint.
0
 
WinterMuteUKAuthor Commented:
Ahhh,

I have found the problem, the difference lies between Visual Studio 2003 and 2005 in the way the IDE works when compiling projects. Lets take this as the project structure:

  MyServerHost (exe)
  MyServer (dll)
  MyObject (dll)

each of these are projects in their own right. MyServerHost has an instance of MyServer, and MyServer has an instance of MyObject. Importantly, MyServerHost doesn't have a reference to MyObject as it knows nothing about it.

Now, in VS2003, compiling MyServerHost copies an instance of the 'MyObject.dll' file to the build directory, even though it's not referenced explicitly in the MyServerHost project references. In VS2005 this doesn't happen. So, with 2 identical solutions, one in 2003 the other in 2005, the 2003 will work, the 2005 won't. The solution that has been implemented then is to add the 'MyObject' reference to the 'MyServerHost' project.

I apologise for my wording of the problem as well, where I put 'the assembly *is* in the directory of the processes' I should have put '*is* in the directory of the library being referenced' as it patently wasn't in the process directory.

I'm not sure how to resolve this question, any suggestions?

Cheers
Wint.
0
 
vo1dCommented:
why dont you reference the projects instead of the compiled assembly?
so if you rebuild the whole solution, all project assemblies should be build.
0
 
WinterMuteUKAuthor Commented:
vo1d, as I said a few posts up:

  "I reference the project that compiles to 'MyAssembly' yes"
0
 
vo1dCommented:
oh sorry, did not see that.
maybe you solution or project files are corrupt? have you setuped them again?
0
 
WinterMuteUKAuthor Commented:
Hi Vo1d,

The problem lies with the way VS2003 and VS2005 deal with copying dlls to different locations on compiling, (see the entry I wrote here posted on 04/21/2006 12:38PM BST, 4 comments up). I can replicate this with a brand new project / solution without any troubles at all.

The problem lies with VS2003 / 2005 working differently.

Thank you for your suggestions though,

Cheers,
Wint.
0
 
WinterMuteUKAuthor Commented:
I'm going to ask to have this question closed as I have answered it myself, please let me know if you think that is unfair.

Thanks

Wint.
0
 
vo1dCommented:
no problem wint ;)that is a very interesting thing. maybe you should post it in a microsoft newsgroup or give that feedback to the msvs devteam to get a comment from them.
glad that you found a solution.
0
 
WinterMuteUKAuthor Commented:
It's being put forward to MS through their product feedback pages, we'll see what happens with that!
0
 
vo1dCommented:
that's fine. could you post the microsoft feedback, if they post, in a new 0 point question?
0
 
WinterMuteUKAuthor Commented:
Yup, will do.
0
 
GranModCommented:
Closed, 500 points refunded.
GranMod
The Experts Exchange
Community Support Moderator of all Ages
0

Featured Post

Free Tool: Site Down Detector

Helpful to verify reports of your own downtime, or to double check a downed website you are trying to access.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now