Vibrant discussion about CSLA .NET and using the framework to build great business applications.
I was wondering if any one has experience using CSLA 4 with CSLA 3.8. The issue we have can be summarized as follows:
1) Library 1, is built using CSLA 3.8, and is responsible for authentication, etc.
2) The main application using Library 1 has been upgraded to CSLA 4. It may be a while before Library 1 is updated to CSLA 4.
The issue we face is with the ApplicationContext. COEPrincipal (BusinessPrincipalBase) in the code below is part of Library 1 (csla 3.8). So we have a mismatch, and was wondering what you would recommend for an interim workaround.
if (COEPrincipal.Login(criteria.Username, criteria.Password)) { this.IsAuthenticated = true;
COEPrincipal coep = (COEPrincipal)Csla.ApplicationContext.User; COEIdentity coeid = (COEIdentity)coep.Identity; Csla.ApplicationContext.GlobalContext["Ticket"] = coeid.IdentityToken;
Thanks.
I'd be really surprised if you could get this to work properly. Csla 4 is compiled for .NET 4 and Csla 3.8 compiles for .NET 3.5 and you would run into InvalidCastException and MissingMethodExceptions being thrown.
This article may provide a better description of the problem: Best practices for Assembly Loading
Jonny Bekkum, Norway CslaContrib Coordinator
This might be possible if you can get 3.8 compiled (and working) for .NET 4.
In that case, you could rename the Csla base namespace in 3.8 to Csla38 or something, and thereby avoid ambiguous type issues.
Then you'd change your existing code to use Csla38.???, thus switching all existing code to work with the existing framework.
As you move code to CSLA 4, you'd write that code to use Csla.???, thus using CSLA 4.
People did this when moving from CSLA .NET 1.x to 2.1 and it was quite effective.
However, I know there are some parts of 3.8 that don't work in .NET 4, at the UI level in XAML anyway. But if all you are trying to do is get business object code working, this might be a technique you can try.
Rocky
Thanks, I'll give it a shot.
I forgot to mention one more issue. Library 1 above still targets .NET 3.5, so targeting CSLA 3.8 to .NET 4 may be a non-starter. Library 1 is maintained by a different team, and I am trying to get them to upgrade sooner than later.
Well that's the core issue, not CSLA but .NET.
You can't run more than one version of .NET in an AppDomain, so one application can't use more than one version of .NET.