Calling WCF from Console app (uses CSLA for windows)

Calling WCF from Console app (uses CSLA for windows)

Old forum URL: forums.lhotka.net/forums/t/7728.aspx


sammy posted on Monday, October 05, 2009


Hi,

I am trying to stress test one of my business object methods (a fetch) via making a WCF call from a windows console app.

Not sure what the best way to do this...

Currently we have our *.client files using CSLA for Silverlight (because the primary front-end is Silverlight). Is there a way to reuse my CSLA domain model as-is regardless of the front-end technology making the call?

I tried using CSLA for windows from my console app, but I get a CSLA Serialization exception.

Comments and suggestions much appreciated.

Regards,
Sam

RockfordLhotka replied on Monday, October 05, 2009

What are you trying to stress test? The WCF data portal host, or some back-end WCF data service?

If you are trying to stress the WCF data portal host, your only real option is to use a Silverlight client, because the Silverlight data portal isn't the same as the .NET data portal.

The Silverlight WCF client stack isn't quite the same as the .NET WCF client stack, and the actual on-the-wire service contract for the Silverlight data portal host is optimized for SL and so is different from the .NET data portal contract.

In other words, you can't call a Silverlight data portal endpoint from .NET - it has to be called from Silverlight.

Now if you are trying to stress your back-end WCF data service, then you can create a .NET client app (console, MStest, whatever) that interacts with your server-side business library assembly, and you can exercise everything from the server-side business objects through to the database.

sammy replied on Wednesday, October 07, 2009

Hi Rocky,

Thank you very much for your reply. Makes sense.

I have created a silverlight app, spawning threads to the *.client method. The *.client method is static and lives in my app.domain. The problem I am having (guessing here) is that all threads are trying to call the same instance of the dll, and so I am getting an Invalid Cross Thread Operation. Any ideas how I can solve this?

Thanks again,
Sam

RockfordLhotka replied on Thursday, October 08, 2009

If you are getting a cross-threading exception it is almost certainly because you have code on background threads that is attempting to interact with the UI - either directly, or indirectly by raising events that are handled by the UI.

Copyright (c) Marimer LLC