SerializationException: input stream not a valid binary format

FireGarden posted on Wednesday, October 11, 2006

I have configured my application to use remoting. I am getting a serialization exception when I try to run it. I have checked all the usuals (Serializable etc).

I found a few posts saying I need to disable binary serialization to get the error message as follows:

"This error message is due to the fact that you are using Binary Formatting.   The only way I know how to get a human readable error message is to change to SOAP Formatting."

My question is: How do I enable soap formatting in my remoting configuration?

********** NEW **************

I have found that I had a typo in my remoting objectUri. I corrected that and got a new error as follows:

System.ArgumentException Invalid token for impersonation - it cannot be duplicated.

Next I decided to call "Logout()" before I login as per a few posts and this has fixed my problem.

My new question is why do I have to call logout before I call login to surpress the exception?

Regards,

Rob Wheeldon

RockfordLhotka replied on Wednesday, October 11, 2006

The most common causes for this issue (in my experience) are:

1. A typo in the web.config file - remember it is case sensitive
2. Business assembly not in bin directory on server
   
3. Virtual root not properly configured to work with .NET
   
4. ASP.NET not properly configured on the server
5. IIS security issue
6. ASP.NET not installed
   
7. IIS not installed

I know those last two seem odd, but they really happen from time to time...

But BY FAR the most common issue is a typo in the web.config file, or incorrect configuration of ASP.NET on the machine.

The result is that IIS returns some text - like a 404 or something - indicating an HTTP error. But Remoting just takes that text and tries to treat it like a valid result, so it tries to deserialize that data - which of course fails miserably.

Rather than trying to use the depricated SoapFormatter, you'd be better served by using one of the tcp trace tools to see what is actually going across the wire. That way you could actually see the text result coming from the server, which is the best debugging data you can get.

If you still really, really want to use the depricated SoapFormatter, I think you'll need to write your own Remoting channel for the data portal - or at least your own proxy on the client (see Chapter 4 for details on how the proxy is created currently). This is not something I've spent any time researching, because the SoapFormatter is on the way out, and should be avoided.

But again, odds are very high that your issue is a typo in a config file, or some setup issue with ASP.NET or your virtual root.

FireGarden replied on Wednesday, October 11, 2006

Thanks for your fast response Rocky. I have found a refernce to a post dealing with my new issue:

http://forums.lhotka.net/forums/thread/2584.aspx

I still have not solved why this is required.

Rob

RockfordLhotka replied on Wednesday, October 11, 2006

It is required because, when using custom authentication, the data portal requires that every call include a BusinessPrincipalBase-derived principal. The default .NET principal is GenericPrincipal, which won't work.

If you look at the logout code, you'll see that it establishes an unauthenticated custom principal on the thread - thus meeting the requirement put forth by the data portal.

FireGarden replied on Wednesday, October 11, 2006

Thanks again for your help Rocky. I understand why I need to call logout first.

As per pages 479 - 480 of Expert C# Business Objects 2005

Thanks,

Rob

vctanx replied on Wednesday, April 30, 2008

Hi there,

I need to lookup some user information in active directory, and I want to use types (basically Principal and UserPrincipal) in System.DirectoryServices.AccountManagement namespace. I got two problems, and I wonder anyone could confirm if they are just related to my incorrect configuration or to a more serious flaw.

1) When querying AD from within DataPortal_Insert method, I got an error related to invalid transaction of sort; (actually I now remember getting the same kind of error when calling a view that get data from another database server via linked server. It is no problem when retrieving these data outside or prior to calling DataPortal_Insert.)
2) With AD, I now not an SerializableException saying that Principal type is not marked as serializable.

Any helps and/or resolution suggestions to these problems would be greatly appreciated.

RockfordLhotka replied on Friday, May 02, 2008

vctanx:

Hi there,
1) When querying AD from within DataPortal_Insert method, I got an error related to invalid transaction of sort; (actually I now remember getting the same kind of error when calling a view that get data from another database server via linked server. It is no problem when retrieving these data outside or prior to calling DataPortal_Insert.)

If your data portal is configured to run on a remote server, you could be encountering a basic Windows security issue. Most remote data portal configurations involve the server components running in IIS - thus under an ASP.NET user account. That user account may not have access to your AD.

You'd solve this using any one of the many techniques available to make a web site run under a different user identity, or by granting the ASP.NET user access to your AD (not usually a good idea).

vctanx:

Hi there,
2) With AD, I now not an SerializableException saying that Principal type is not marked as serializable.

Your principal and identity classes must be serializable. If your classes are serializable and you are getting this exception, it is likely that some code (yours or Microsoft's) changed the principal to a WindowsPrincipal or something like that - which is not serializable.