Normal 0 false false false EN-US X-NONE X-NONE MicrosoftInternetExplorer4
Need help on some issues we’re experiencing with trying to make one of our products (which is based on CSLA 3.8 and .NET 3.5.SP1) run under SL4. Basically, I took a naïve approach in simply setting the target version on all our Silverlight projects to “Silverlight 4,” including the CSLA SL project. After all the references were updated, we tried to run an installation on a virtual machine, but were presented with an interesting error – one that we can’t run down in development. No one can reproduce it in development.
The error seems to point to a difference in the way data is transferred between the client and server. A simple example can be found during the log in process where the client sends the server some credentials which it checks against the database. On success, the client creates and provides principal information to an “ApplicationContext” object. From what I can tell, the server does not appear to be “getting” the same context information set by the client as server-side checks against the ApplicationContext fail.
I commented out our server-side checks against the ApplicationContext's principal (which ensure the user has been authenticated) and re-deployed. This time, I was presented with another exception related to some problems serializing/deserializing data which make me think this is a more fundamental change in the way SL4 transfers data.
Is it even possible to make CSLA 3.8 target SL4? If not, what about upgrading to another version such as 3.8.4? I should mention that we would like to avoid making the move to .NET 4.0.
Any help would be appreciated.
Thanks.
http://www.lhotka.net/weblog/RunningCSLANET382UnderNET4AndSilverlight4.aspx
Sounds like this will require .NET 4 though, correct? We were hoping to avoid that. Perhaps it's required.
I don't know why it would require you to shift to .NET 4 on the server. You'll have to go to VS10 I would think, but probably not .NET 4.
There are some issues around getting the code to compile and actually work in SL4 - but that's all SL-related and shouldn't affect the .NET 3.5 SP1 side of things (or if it does, you can use #if SILVERLIGHT blocks to overcome the differences).
One thing Jaans might not have addressed in his blog post, because we discovered it late, is that SL4 reserved a state name that we were happily using in SL3. The result is that PropertyStatus didn't work right, and fixing that required changing the state name in PropertyStatus and in its related xaml file. I blogged about this issue though, so you can find info on my blog (www.lhotka.net/weblog).
Copyright (c) Marimer LLC