First off, this isn't necessarily a CSLA issue. I'm just hoping that somebody else on this forum has encountered something like this and can help save both my forehead and my wall!
I've been developing a hefty website most of this year and have recently just tried to host it (on Fasthosts). I've been trying to publish the site via Visual Studio.
I get the following exception (which has numerous entries in google which makes it hard to search for my specific problem!):
[SecurityException: That assembly does not allow partially trusted callers.]
This exception is in relevance to my CSLA library. From scouting around on the net I found a few articles that led me to add the following line to the AssemblyInfo.cs:
[assembly: System.Security.AllowPartiallyTrustedCallersAttribute()]
This hasn't seemed to help...
...but this leads me to the most bizarre issue. The exception states that the call to my CSLA library is pointing to the original path on my local machine!?
[SecurityException: That assembly does not allow partially trusted callers.]
XO.Store.ProductList.GetNewProductList() in C:\AlexandraSports\XO.Store\Product\ProductList.cs:51
...
...
??? Any help would really be appreciated as I'm completely lost with this !!!
CSLA requires a full trust environment.
It won't run in a Partial Trust environment which is what most website providers use.
It makes heavy use of reflection and other concepts which require Full Trust.
The latest version of CSLA is trying to address this issue because Silverlight can only be run with Partial Trust. If you used the latest version and re-wrote all your business objects then it might work.
For now your best bet is to find a website host that will allow you to run with Full Trust.
Joe
Hmm, I'll contact the hosting provider to see if they'll let it run in full trust.
It threw me due to the local path reference, and I still find that odd.
Just a quick query (which has likely been covered in a lot of other places), but how trivial is a conversion from CSLA 2?
I'll have a search about the partial trust issue and Silverlight - interesting stuff.
Thanks.
Update...
Our hosting provider only caters for high trust. That is unless we fork out more money for a dedicated server, which is not a viable option at the moment. Fasthosts are a highly regarding provider in the UK which is why I'm reluctant to cancel our hosting and find another UK provider, but I'm guessing CSLA will never work in high trust?
I've sworn by CSLA for years and have no intention of removing it from our application, especially as we have plans for the future to move it to an in-house server and integrating it with an EPOS system.
So I'm left with what seems to be a big dilema - strip out CSLA, or change hosting providers. The latter is a more preferable option, but I want to make sure I haven't missed anything before going ahead with this.
Does anybody know of other options I may have?
Thanks,
Dave
How would CSLA for Silverlight be beneficial over 3.6?
I'm assuming the Light version utilises 3.6 anyway, so does that mean they both aim to cater for partial trust?
I think this is looking like my best option - porting the code to 3.6 and finding a hosting provider that will cater for it.
Thanks for all the help so far. It's really appreciated. I'm an autocad developer by day, so this website has been eating up my weeknights and weekends for a while now, and will probably continue for a while longer which is why I want to make sure I go down the right path from now on!
As I understand it, if you code a single BO correctly it will run in both environments. I think each BO needs Regions for .Net and Silverlight - probably with compiler constants or something. Then the one BO can be used in the Silverlight client and serialize back to the same BO on the server and run in .Net.
I want to learn more about this too. But I am not going to commit my app to it until I understand it better.
If I were you I would find a Host that supports full trust and ship your current app. The re-write could take a while. Not sure if you have the time or interest.
Joe
Copyright (c) Marimer LLC