ApplicationContext.User problem if the server side hosted in WPF application

alexsychev posted on Tuesday, September 29, 2009

Hi,
in our project we  host our server side CSLA either in WPF application (for debug purposes, use it in development) or in Windows Service (for production).

Recently we came across annoying and hard to reproduce or debug issue in which server side code loses the ApplicationContext.User from time to time.

Can it be related to CSLA 3.6 fix of the way ApplicationContext.User is handled for WPF?
It is cached in static field ApplicationContext._principal.

So if two requests come simultaneously on two threads:
Request1.SetPrincipal -->> Request1.DoWork -->> Request2.SetPrincipal -->> Request1.RESETPrincipal --> Request2.DoWork failure, because the principal is null.

In general in means that CSLA server component should never be hosted in WPF application.

Is my understanding correct?

RockfordLhotka replied on Tuesday, September 29, 2009

That is correct. This was debated at some length a few years ago, and the general concencus was that making WPF work in the 99.999% case was more important than having it work in the incredibly rare (unique to you so far) case where WPF is used to host a multi-user server.

I take it you are creating some sort of peer-to-peer app or something?

Otherwise, in general you should never host server components in client applications like WPF or Windows Forms. The .NET runtime itself knows whether it is running in client or server mode and acts differently (in terms of garbage collection, etc), and the client mode really won't perform or scale well when used as a server.

alexsychev replied on Wednesday, September 30, 2009

Thanks for reply.
I agree that making WPF properly work with CSLA authentication is much more important.
Actually the side-effect I described in my post is not a problem for us, because we  use WPF-hosted server in development only (it produces some useful output on the fly) and both client and server are located on each developer's machine.