Questions about upgrade path

Questions about upgrade path

Old forum URL: forums.lhotka.net/forums/t/12600.aspx


bgilbert posted on Thursday, April 24, 2014

My team currently supports a WinForms application (~100k lines of code) built on top of CSLA 3.6.3. We are using mainly unmanaged properties (we got started before managed properties were introduced). The few classes we built using managed properties were done in 3.6.3. We are now looking at upgrading to the newest version and have some concerns.

I should mention that, while we are using DataPortal methods, everything runs locally and we are not considering an application server. We are also not considering any other client technology, like a web UI. 

As Rocky mentioned in this post on Stack Overflow, the amount of work looks daunting. In some of my recent experience with managed properties, it can save a little work and a few lines of code, but can introduce some complexity and a learning curve that seems like a distraction. A couple of examples:

  1. We like being able to hover over a backer field in the ide to see its value; harder to do with a managed property.
  2. We recently spent two days trying to understand why a child object was not garbage collected and turned up in another object; moving to an unmanaged property immediately solved the issue, though I'm still not sure why. Very frustrating.

 

Before we start down the path of upgrading, we want to be really sure it will be time well spent. We have two other options: stick with our current version (3.6.3) or ditch CSLA and rewrite some key functionality into our own base classes. If we do decide to upgrade, we are facing a huge task. We cannot upgrade in pieces, so we would likely spend several months fixing the code before we could ever get it to compile and by then we might conclude that we fundamentally misunderstood how to use managed properties. The same holds true for the way validation rules are now structured.

My questions: are there any good ways to do this gradually? Could we reference two versions of CSLA? Could we use unmanaged properties and the older validation rules methods in the newest version? What are the risks of other significant changes to the basic model of CSLA down the road?

 

tiago replied on Sunday, April 27, 2014

bgilbert

Before we start down the path of upgrading, we want to be really sure it will be time well spent. We have two other options: stick with our current version (3.6.3) or ditch CSLA and rewrite some key functionality into our own base classes. If we do decide to upgrade, we are facing a huge task. We cannot upgrade in pieces, so we would likely spend several months fixing the code before we could ever get it to compile and by then we might conclude that we fundamentally misunderstood how to use managed properties. The same holds true for the way validation rules are now structured.

My questions: are there any good ways to do this gradually? Could we reference two versions of CSLA? Could we use unmanaged properties and the older validation rules methods in the newest version? What are the risks of other significant changes to the basic model of CSLA down the road?

Hi BGilbert,

A small application just for the purpose of mastering the new business rules might make it easier to estimate the time cost of the upgrading.

Concerning gradually upgrading, since you can't reference two different versions, maybe you could do it the dirty way: grab the latest source and rename the namespace to Xsla instead of Csla.

tiago replied on Sunday, April 27, 2014

You can read JonnyBee reply on this thread. Jonny explains how you can upgrade bit by bit.

ajj3085 replied on Sunday, April 27, 2014

Actually you can reference two versions of Csla and upgrade over time http://forums.lhotka.net/forums/p/9893/46391.aspx#46391

More information about upgrading here http://www.lhotka.net/cslanet/faq/CslaVersions.ashx

bgilbert replied on Monday, April 28, 2014

Thanks, Andy. We have successfully referenced two versions and are starting to do a gradual upgrade.

Copyright (c) Marimer LLC