Hi,
We are planning to move our Winform application to an XBAP (WPF) application. Our application must be an inline application publiched on a IIS web server. I know that XBAP run in internet zone security sandbox in this case.
I need to know how this can impact CSLA business object. We use business objects in 2 and 3 tiers, XBAP application are restricted for accessing WCF webservice , can we also have problem with remoting?
Is there other problems that we should be aware of (ado.net, serialization....)?
Thanks
Alain Martineau
CSLA .NET requires FullTrust, and so it can't run in a restricted sandbox. This is because CSLA .NET makes use of FullTrust technologies like Remoting, WCF, Reflection and more.
Even without CSLA .NET you'll find that you can't use private reflection, Remoting, WCF, BinaryFormatter, ADO.NET, etc. because they all require elevated permissions. Sandboxes are pretty restrictive...
For local storage look at IsolatedStorage, and maybe (just maybe) SQLce (though I think that requires elevated permissions at the moment as well).
Due to Silverlight, I am researching the possibility of creating a CSLA Light which would run in an Internet zone sandbox, and in the even more restrictive Silverlight environment. The Silverlight alpha available today doesn't have enough functionality to even come close to hosting something like CSLA, but Microsoft's plan for Silverlight should provide enough functionality to create a stripped down, client only version of CSLA.
That means no data portal, no Clone() method, and the requirement to implement GetState() and SetState() methods to support n-level undo (thanks to no private reflection). But it does mean that I should be able to provide the full validation, authorization, data binding and n-level undo capabilities of CSLA .NET in the CSLA Light version. I also plan to provide the data portal interface so factory methods can remain consistent, but the back-end implementation will be quite different. (I can't do mobile objects due to no serialization, and I can't do the strongly-typed DP_XYZ calls due to no private reflection).
I anticipate that around 80% of the code you'd write in a business object today will be the same in CSLA Light, perhaps even more.
Of course CSLA Light would most likely end up working in an XBAP setting as well, or for a Windows Forms app deployed using ClickOnce with restricted permissions. The lack of a real data portal is pretty hard to take, but I haven't figured out a way to do it, so it is probably unavoidable...
Thanks for the quick response.
We have requirements asking for XBAP; browser base, ASP hosting etc....
We will look for elevating permission by installing an trusted publisher certificate. I don't think XBAP can manage the certificate installation in the application startup process. We should deploy certificate by using group policies (GPO) or by running some kind of preinstall requirement msi in the startup process.
Thanks a lot
Alain
Hey Alain,
Any progress on using XBAP with CSLA? This is something that would be useful for an upcoming project I may be working on.
Please keep us posted on any discoveries you make.
Thanks...
-- Mike :-)
The XBAP project has a "This is a full trust application" setting in the security tab of the project. Will this allow us to use the current framework? We have been trying to prototype this and seem to have ran into some serialization issues with the ApplicationContext.User property, centered on the Thread.CurrentPrincipal.
I'm new to the CSLA framework so I was wondering if I'm wasting my time.
I don’t know an answer to this issue.
The issue is that you have a custom principal on the thread, and
the XBAP framework appears to create a new AppDomain for each frame content
object – which means that the thread’s principal must be
serialized/deserialized into that new AppDomain.
There’s a well-known “feature” of .NET that
causes serialization issues when .NET is hosted in various environments –
including IE. There’s also a workaround to this issue, but the workaround
requires a bit of code be run when the appdomain is created – which you
can’t do in this case because you aren’t creating the appdomain.
What I’m getting at, is that this isn’t an issue
with CSLA, or that is unique to CSLA. It is an issue with the use of a custom
principal on the thread.
So the solution is to not use a custom principal on the thread. Either
use the Windows principal, or re-load the principal on every transition (and
make sure to clear it before the next transition).
It seems to me that the XBAP framework is pretty broken on
several levels – this just being one example. Personally I expect XBAP
will become the next Active Document once Silverlight comes out. Why deal with
this complex and quirky model when Silverlight offers a cleaner setup.
Rocky
From: Darren [mailto:cslanet@lhotka.net]
Sent: Friday, May 02, 2008 6:03 PM
To: rocky@lhotka.net
Subject: Re: [CSLA .NET] CSLA and WPF XBAP applications
The XBAP project has a "This is a full
trust application" setting in the security tab of the project. Will
this allow us to use the current framework? We have been trying to
prototype this and seem to have ran into some serialization issues with the
ApplicationContext.User property, centered on the Thread.CurrentPrincipal.
I'm new to the CSLA framework so I was wondering if I'm wasting my time.
Copyright (c) Marimer LLC