Best practice for upgrading Customizations in an extension Library (DAC cast issues post upgrade)

Hi,

Just looking for some advice on what steps need to be undertaken for the upgrade process when there are customizations using extension libraries.  

We always have issues on the live site post upgrade so obviously we are not doing something correctly.  This is our process:

1. We get a sandbox environment and take a snap shot,
2. Next create a local instance of the new build, import the snapshot, and test the code compiles.  This is done by the developer (ie. me) and as long as the code compiles and publishes locally I don’t do anything else 
3. We get our users to do some testing in the sandbox.  This is fairly undirected and probably too light (meaning there are problems on the sandbox that don’t get identified pre upgrade)
4. Assuming that no issues are picked up in the above we wait for the upgrade to occur
5. Post upgrade we republish the customizations.  On the new live site all customizations appear as unpublished.

That’s our process.  Post upgrade, things typically do not go well on the Live site.   A common problem we get is messages along the lines of:

This seems to happen when we have the following scenario in the same site:

Customization A extends a DAC within an extension library  (this customization is FertCo25 in the error message above and the DAC in question is SOOrder)

Customization B also extends the same DAC (SOOrder) adding in additional fields internally within MYOB (ie. not in an extension library)

This situation doesn’t create a problem pre upgrade, but post upgrade it does.  Typically what happens next is we: roll customization B into A in the local dev site on the new build so that we don’t have the same DAC extended in more than 1 place, republish to live,.. .  This is quite disruptive for our clients as there is usually a period of 4 hours during business hours where the can’t do things like create sales orders => not good.

Also, if we don’t have the same DAC extended in multiple customizations pre upgrade our current process seems to work without problem (still have questions around whether or not it is right though).  So far this has lead us to the conclusion that having the same DAC extended in more than one customization is problematic.  I don’t actually believe this conclusion is correct as pre upgrade it isn’t a problem.

In our most recent example we were moving from build 2022.121.302.3452 to 2022.217.202.5231

This is my theory (which I would like some confirmation on as I’m not 100% that this is correct)

1. During the upgrade process any customizations that don’t use extension libraries go through some internal recompile process.  However, this can’t reasonably happen to customizations using an extension library.
2. This means that post upgrade we end up with customizations with extension libraries compiled in this case 2022.121.302.3452 operating in 2022.217.202.5231 on the live site and this is what causes the problems.  These extension libraries were compiled with references to things like PX.Data, PX.Objects,… that are now out of date.

My thinking is that the current scramble we go through to resolve this post upgrade (by rolling Customization B in to Customization A so that we don’t have the same DAC extended  in multiple places), fixes the issue because in the process Customization A gets recompiled to the same build as Live post upgrade.

So, what we need to be doing is either just before or just after the upgrade, we delete out all customizations that use extension libraries on the live site and replace them with new customizations that have been compiled on a local site of the same build we are upgrading to?

That’s my question, is the above the missing step that we need to be doing?

Thanks in advance for any help,

John.