Recommended Migration Path to CSLA.Net 2.0

stever posted on Friday, June 30, 2006

Our product is currently using CSLA.Net 1.1 and .Net Framework 1.1.

We're considering upgrading the CSLA code to 1.3 or 1.5 to better position ourselves for the move to CSLA 2.0 and .Net 2.0.

Does anyone have a recommendation on the migration path to CSLA.Net 2.0 and .Net Framework 2.0?

Thank you,

Steven

RockfordLhotka replied on Friday, June 30, 2006

Certainly 1.53 is much closer to 2.0 than any previous version, but it is still different. If you are actively development (adding lots of new classes, etc.) then it might be worth moving to 1.53 to ease some effort later. But if you are in maintenance mode now, I'd hold off and just migrate to 2.0 in one move.

It is also worth noting that a couple people have emailed me to say that they are running a 1.x version in parallel with 2.0 - under .NET 2.0 of course. To do this, get the 1.x version running under .NET 2.0 (which is usually pretty easy) and then change the namespace of either the old or new version. Your app should now be able to use both versions - just choose the namespace for the version you want.

The only complexity here is with a remote data portal, where you'll have to make sure to configure remoting to have two endpoints (within the same virtual root) - one for each version of the framework. Since the two versions of CSLA use different config elements on the client, you should be able to configure both 1.x and 2.0 data portals without conflict.

rohancragg replied on Thursday, July 13, 2006

I was about to post a new topic on migration until I saw this reply.

I have been considering running in parallel (C# v.151 and C# 2.02), and had been wondering if it would be enough to just rename the assembly to (say) Csla2.dll? I guessed probably not because of namespace conflict.

However, the reason I ask anyway is that I noticed that in version 1 the default namespace is 'CSLA' (note the upper case) but in version 2 the default namespace is 'Csla'. Do you think this difference in case would help to avoid conflict? I can always try but if anyone knows enough about the framework to say one way or the other it would save me some wasted effort.

If I do need to rename the namespace, is it simply a case of a find/replace on the string Csla to (say) Csla2?

Many Thanks. Rohan

Tom Cooley replied on Monday, July 03, 2006

My company is mid-way through a rather large project using CSLA 1 and .Net 1.1. But there are some nice new features to CSLA 2 that I didn't want to wait for. So, I created a BusinessBase class that sits between my business objects and the CSLA 1 framework. I also recreated the CSLA 2 security model for CSLA 1. The result is, my property declarations look exactly like they would for CSLA 2. There are some differences in the static factory methods (because generics don't exist in .Net 1) and the data portal methods (because MS decided to replace Parameters.Add with Parameters.AddWithValue), but aside from those changes and a change in case to the Csla namespace, most of my code will port over very easy. And since I use code generation, re-generating the classes that existed before this was or will be pretty painless. When I move to CSLA 2, I'll just drop the intermediary class, re-gen the classes to use generics, and do some search & replace and be most of the way there.

Misled replied on Thursday, July 13, 2006

I tried running 1.X and 2.0 in the same appliaction. Works fine except for Remoting. Rocky said in this thread that remoting can work. However, when I tried it, I got an error saying "The channel 'HttpBinary' is already registered" when I tried to open the second dataportal. What was I doing wrong? Would it have anything to do with the fact that I didn't change the name of the CSLA namespace? In the classes that I was using, I only imported the library I needed, so I don't think that would come into play.

The case of "CSLA" as opposed to "Csla" only comes into play with the config files. You need to watch that in both the class name and Authentication type.

If you use the templates from 2.0, watch the factory methods. Some (if not all) factory methods for fetch have Dataportal.Create instead of DataPortal.Fetch. There's quite a lot code to be rewritten but it seems really stable and is easier to use I think. Either that or I'm just getting more comfortable using Rocky's framework. :)