dataportal fail

dataportal fail

Old forum URL:

BunnyStrider posted on Wednesday, March 16, 2011

I'm trying to get this old website project running and I'm stuck on this error:

My Page fires an event that calls my BusinessLayer...I can follow the debug all the way to this line:

child = DataPortal.Fetch<UserChild>(new UserNamePasswordCriteria(userName, encryptedPassword));

but DataPortal_Fetch() method never gets called and instead this exception is thrown:

"The input stream is not a valid binary format.  The starting contents (in bytes) are: 53-79-73-74-65-6D-2E-52-75-6E-74-69-6D-65-2E-52-65 ... "

This is what the stackTracke looks like:


Any ideas would be appreciated.



RockfordLhotka replied on Wednesday, March 16, 2011


  1. You have the same version of .NET on both sides of the wire (including service packs)?
  2. You have the same version of the CSLA assemblies on both sides of the wire
  3. You have the same version of your business assemblies?
  4. Have you double-checked point 2?

Those are the most likely things that would cause this sort of serialization issue.

BunnyStrider replied on Wednesday, March 16, 2011

added the port VS uses on localhost to the CslaDataPortalUrl and that fixed it.

By "both sides of the wire" what do you mean?  

Is there any way to debug the DataPortal_Fetch method?  I put a breakpoint in it but it never fires...

Now I have a different error on the same line which I have no idea what it is:

{"The underlying connection was closed: An unexpected error occurred on a receive."}

InnerException: {"Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host."}


Server stack trace: 

   at System.Runtime.Remoting.Channels.Http.HttpClientTransportSink.ProcessResponseException(WebException webException, HttpWebResponse& response)

   at System.Runtime.Remoting.Channels.Http.HttpClientTransportSink.ProcessMessage(IMessage msg, ITransportHeaders requestHeaders, Stream requestStream, ITransportHeaders& responseHeaders, Stream& responseStream)

   at System.Runtime.Remoting.Channels.BinaryClientFormatterSink.SyncProcessMessage(IMessage msg)


Exception rethrown at [0]: 

   at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)

   at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)

   at Csla.Server.IDataPortalServer.Fetch(Type objectType, Object criteria, DataPortalContext context)

   at Csla.DataPortalClient.RemotingProxy.Fetch(Type objectType, Object criteria, DataPortalContext context) in \\cqi-master2\CQI-BIGSITES\Installers\CSLA.Net Framework\2.1.4\csla20cs\csla20cs\Csla\DataPortal\Client\RemotingProxy.cs:line 111

   at Csla.DataPortal.Fetch(Type objectType, Object criteria) in \\cqi-master2\CQI-BIGSITES\Installers\CSLA.Net Framework\2.1.4\csla20cs\csla20cs\Csla\DataPortal\Client\DataPortal.cs:line 185

   at Csla.DataPortal.Fetch[T](Object criteria) in \\cqi-master2\CQI-BIGSITES\Installers\CSLA.Net Framework\2.1.4\csla20cs\csla20cs\Csla\DataPortal\Client\DataPortal.cs:line 140

   at CareTracker.BusinessObjects.User.UserChild.GetUserChild(String userName, String encryptedPassword) in C:\CQI\Projects\CareTracker\CareTracker.BusinessObjects\User\UserChild.cs:line 2769


RockfordLhotka replied on Wednesday, March 16, 2011

"both sides of the wire" is jargon, sorry. You have a client, and a server, and they are connected by a network - a network consists of wires. So "both sides of the wire" means both sides of the network: the client and the server.

The original problem you were having was a serialization issue - which means that the message flowing across the network didn't make it to any CSLA code or business code - it failed at the point .NET tried to understand the message. That is why you couldn't debug DataPortal_Fetch - that code would never run if the issue is a network or serialization issue.

Your new problem is also a networking problem. Now it sounds like the client is entirely unable to establish a connection to the server. So obviously no server-side code will run, so you can't debug it.

Remoting can be hard to troubleshoot. You should consider using a network sniffer, like fiddler, to watch what is going across the network (or what your app is trying to send anyway). That can sometimes give you clues about why the network connection is failing.

BunnyStrider replied on Thursday, March 17, 2011

Right now I'm just hitting the 'play' button in VS.  I don't see how it could be a network issue since everything's on my machine but I will google the error and see if I cant figure anything out.  I'll also try deploy/publishing the solution to see if that changes anything but I do have this question.

I'm using ASP.NET to serve up some client side code, when the client enters their user/pass and clicks submit it's sent to the server where the code runs.  I'm then on the server using my BO dll's (from the bin folder of the website?) to call DataPortal.Fetch<>()....Should I have some kind of service waiting on the end of my url: <add key="CslaDataPortalUrl" value="http://localhost:1225/ApplicationServerRemotingHost/RemotingPortal.rem"/>

Maybe I'm missing a piece.  I'm trying to figure this out but it's hard looking into an infrastructure that's already half there a certain walkthrough/tutorial that might shed some light on how this design is implemented?

Thanks for the help, will update if i can figure anything else out...

Oh, and I think dll hell was the reason for the first error, btw! So you were right on that.

RockfordLhotka replied on Thursday, March 17, 2011

Part of the challenge is that Remoting is very old at this point. WCF became the recommended network technology in 2006, and it has been more than 5 years since I've personally used Remoting... Although WCF can be hard to configure, it is easier to troubleshoot than Remoting was.

Here's some info

That's just one article from here:

If you look at the articles from 2005 and older, there's a lot of content around the data portal and Remoting.

BunnyStrider replied on Thursday, March 17, 2011

I'm thinking about giving up on this guys implementation and going WCF since that's what's being used now ...  I'm currently using CSLA version  Will this version work with WCF?  Could you point me to a starter on getting a WCF implementation going?

RockfordLhotka replied on Thursday, March 17, 2011

You need to go to 3.0.5 to get WCF support. But honestly that's what you should be running anyway, because it is basically 2.1 with tons of bug fixes plus WCF support.

The Using CSLA 3.0 ebook has a chapter covering the use of WCF in version 3.0.x.

RockfordLhotka replied on Thursday, March 17, 2011

Here's the instructions for building CSLA .NET 3.0.5 for .NET 2.0:

BunnyStrider replied on Thursday, March 17, 2011

Can I read an eBook on the computer? or do i need an appropriate reader?

BunnyStrider replied on Thursday, March 17, 2011

I have another question.  For simplicities' sake, and to get a working demo/temporary solution.  How hard would it be to not have a physical layer in between?  In other words, If I put the whole website and business layer on the same server as the database then shouldn't I not need any kind of client/server portal solution?  What exactly controls the DataPortal functionality and how does it know what protocol to use?  How do I make it just use the layer it is in instead of looking for a remoting protocol or web service?

RockfordLhotka replied on Thursday, March 17, 2011

The ebooks are in PDF format - they are best viewed on a computer, or perhaps an iPad. Unfortunately for me, not as well on a Kindle :(

(though the new ASUS Win7 tablet looks like a totally awesome machine - and it would display the ebooks just fine!)

To your question about not having a network connection at all, especially for a web app that's usually the recommended solution. The only real good reason for having a separate app server in a web app is when the web server needs to go through a second firewall to talk to the app server that is inside the corporate network. In other words, where the web server is running in a DMZ.

Otherwise having an app server is just overhead - costing performance for (usually) no gain.

All the Expert Business Objects books from 2005 onward, the Core 3.8 video series, and the Using CSLA 4: Data Access and Using CSLA 4: Data Portal Configuration ebooks discuss or demonstrate how to use the data portal in local mode.

It is "easy" though, because it is the default on .NET. Just do the following:

  1. Entirely remove the web.config appSettings entry for CslaDataPortalProxy
  2. Make sure your database connection string is in the web.config file on the web server (just like it is on the app server now)
  3. Make sure your web server can physically call the database server (there's no firewall in the way, ASP.NET is running under a valid user account for the database, etc)
  4. Make sure your data access assemblies (if they are separate) are installed on the web server, just like they are on the app server now

That's it. Steps 2 and 3 are the places you are most likely to encounter trouble. It is quite possible that the web server is in a DMZ, in which case this just won't work. It is also quite possible the web server has ASP.NET running under an account that has no login access to your database, but you can fix that either by changing the ASP.NET account, or adding its credentials to the database, or by using an explicit username/password in the connection string.

BunnyStrider replied on Friday, March 18, 2011

Wow, that easy, huh?  Thanks for all that information.  I'll end up implementing WCF as we go along but for now this helps to get it running.

Thanks again.

Copyright (c) Marimer LLC