rockfordlhotka
commented
7 years ago I doubt this is the issue, but I always recommend against hosting in a Windows service because you have to take ownership of all the plumbing around the service (as opposed to IIS hosting, where you get some automatic failure management, logging, etc.).
So what you will need to do in this case is add some logging code so you can trace the issue and figure out where your code, WCF, or CSLA are failing in the request pipeline. Otherwise I don't see how anyone could figure out what's going on.
The data portal has hooks where you can insert code to help with logging/tracing. You can find info on most of these in the Using CSLA 4 ebook.
On a per-type level you can implement DataPortal_XYZ methods that are invoked before/after each operation for that type (with a third method invoked in the case of exception). DataPortal_OnDataPortalInvoke, DataPortal_OnDataPortalInvokeComplete, and DataPortal_OnDataPortalException.
You can be notified of every inbound dataportal request by implementing IAuthorizeDataPortal and logging each call before any processing starts.
There's an interface you can implement (IDataPortalExceptionInspector) to gain access to every server-side exception before the call returns to the client.
And you can create a subclass of Csla.Server.Hosts.WcfPortal, which is the very first/last bit of CSLA code invoked on the server - you can then override methods to do logging there if necessary.
Brad-IMS
We have a large WPF application currently using CSLA 4.5.4 which has been deployed commercially for about a year. Up until recently, all sites were running in a configuration where the client and server side dataportals were on the same machine.
Recently a client requested a configuration where the database would be located at our offices and they would access it across the internet. We set up a WCF link with the Server side dataportal running in a Windows service. Initially, everything seemed to be working correctly. Our single-record classes, based on BusinessBase, performed all of their CRUD functions without a hitch. The corresponding collection classes, based on BusinessBindingListBase (although it's WPF, we don't use BusinessListBase, because we use Infragistics controls, which bind with the older interface), seemed at first to be working correctly. The Read function worked perfectly. However, we quickly realized that Insert, Update, and Delete, the functions invoked by Save(), were not working. While they were accomplishing their mission (i.e. an Insert would actually add the record and an Update would actually perform the update), the application would lock up at that point because they never returned control to the client-side.
We have a temporary work-around, where if someone wants to update a record in a collection, we read it in as a single record, update it, then refresh the collection. Obviously, this is not a satisfactory long-time solution.
I'm enclosing one of our simplest classes, plus an Update SQL proc for the class. I'm enclosing the proc, not because I think it has anything to do with our problem, but just for completeness. I'm hoping that someone with a lot more experience with remoting will look at this and instantly perceive where we've gone wrong. POS.txt USP_UpdatePOS.txt