Deployment problem with PL3

I just tried deploying my application for the first time since
LiveUpdating to PL3 (I have successfully deployed several times in the
past).

The deployment failed due to a circular dependency problem.  Upon
investigating, I find that the classes AXAutomationAspect and
AXRecordAspect are not packaged, and this seems to be the cause of the
circular dependency.  I added them both to the ActiveX Automation
package and all the red X's in the package tool went away.

However, this time when I went to deploy, I was warned that my
application may depend on classes in the Development System package,
which is, of course, a no-no.  I investigated and determined that the
above two classes are subclasses of Aspect, which is in the Development
System package.  So, I don't actually depend on this, but it is the
cause of the warning.

I then tried moving those two classes to ActiveX Automation Development,
but that cause a circular dependency between ActiveX Automation and
ActiveX Automation Development.

Where should these two classes be packaged to avoid these problems?

Thanks,
Randy
--
Randy Coulman
NOTE: Reply-to: address is spam-guarded.  Reassemble the following to
reply directly:
rvcoulman at acm dot org

"Randy Coulman" <[hidden email]> wrote in message
news:b3hlas$1lkq9l$[hidden email]...
> I just tried deploying my application for the first time since
> LiveUpdating to PL3 (I have successfully deployed several times in the
> past).
>
> The deployment failed due to a circular dependency problem.  Upon
> investigating, I find that the classes AXAutomationAspect and
> AXRecordAspect are not packaged, and this seems to be the cause of the
> circular dependency.  I added them both to the ActiveX Automation
> package and all the red X's in the package tool went away.

This is because of a bug in the unpatched LiveUpdate discussed in the Patch
Level 3 Available thread, that also describes how to install the patches so
that this problem doesn't occur. Basically you have to install PL2 first
individually.

Their correct home is ActiveX Automation Development, however the patch also
installs some methods that should be loose in AX Automation Development
(e.g. AXRecord>>publishedAspects).  You can correct this by viewing the
dependencies in the Package Browser, selecting items in the list and using
the 'Package...' command to repackage them. However I would recommend that
you save out your packages, backup your image, and then start afresh with a
new image, installing PL2 and PL3 separately.

Regards

Blair

Blair McGlashan wrote:
>
> This is because of a bug in the unpatched LiveUpdate discussed in the Patch
> Level 3 Available thread, that also describes how to install the patches so
> that this problem doesn't occur. Basically you have to install PL2 first
> individually.
>

I had (beta) PL2 installed already when I installed PL3.

Thanks for the help,
Randy
--
Randy Coulman
NOTE: Reply-to: address is spam-guarded.  Reassemble the following to
reply directly:
rvcoulman at acm dot org

"Randy Coulman" <[hidden email]> wrote in message
news:b3j97q$1legbb$[hidden email]...
> Blair McGlashan wrote:
> >
> > This is because of a bug in the unpatched LiveUpdate discussed in the
Patch
> > Level 3 Available thread, that also describes how to install the patches
so
> > that this problem doesn't occur. Basically you have to install PL2 first
> > individually.
> >
>
> I had (beta) PL2 installed already when I installed PL3.
>

The fix to LiveUpdate was only introduced to PL2 when we noticed during the
final stages of preparation of PL2. It wasn't in the beta patches.

Regards

Blair

Blair McGlashan wrote:
Ahhh, that would do it.  I ended up rebuilding my image from scratch and
everything is fine now.

On a related subject:

Is there an easy way to "transfer" settings and window positions from
one image to another.  I always cringe when I have to rebuild my image,
because I have to re-do all of the settings I've changed, re-set all of
the window positions, make sure I re-load all of the little patches and
utilities I had loaded, etc.  My main development packages are no
problem, but what all of the other stuff makes it a pain.

How do other people handle this stuff?

Thanks,
Randy
--
Randy Coulman
NOTE: Reply-to: address is spam-guarded.  Reassemble the following to
reply directly:
rvcoulman at acm dot org

Randy,

> Is there an easy way to "transfer" settings and window positions from
> one image to another.
[]
> How do other people handle this stuff?

I have a script file that does it for me.  After starting a new image I just
have to fileIn the one file and about 30 seconds later the image has been
tweaked, all required packages installed, the image saved under a new name
and all three files backed up.

Anything that can be changed in "User Preferences" can be changed
programmatically in the script.  You can file in st files (for patches and
fixes) and pac files.  There are occasionally situations where you might
have difficulties (dynamically changing that might interfere with the
loading/execution of the script) but they are few and far between.

FWIW - here's my current script file.  Yours will obviously be different but
it should give the idea

~~~~~~
SmalltalkWorkspace defaultFont: (Font name: 'Microsoft Sans Serif'
      pointSize: 10).
Compiler syntaxColorAt: #Comment put: '\cf4 '.
SystemBrowserShell defaultShowInheritedMethods: false.
TipOfTheDay showTipsAtStartup: false.
SmalltalkSystem current defaultBrowserClass: SystemBrowserShell.
TranscriptShell flashOnOutput: false.
Debugger showWalkbacks: false.
SmalltalkSystemShell playSystemSounds: false.
ApplicationDeploymentWizard saveImageOnDeploy: false.
SourceManager default fileIn: (FileLocator imageRelative localFileSpecFor:
       'Ian Bartholomew\install.st').
PackageManager current packages do: [:each | each resetChangeFlags].
View destroyAll.

[    Processor sleep: 500.
    SmalltalkSystem current
        playSaveImageSound;
        sessionManager saveImage: (SessionManager current imageBase ,
'Working').
        SourceManager default compressChanges.
        #('chg' 'sml' 'img') do: [:each |
            File
                copy: SessionManager current imageBase , 'Working.' , each
                to: SessionManager current imageBase , 'backup\Working.' ,
each]] fork.
~~~~~~
--
Ian

Ian Bartholomew wrote:
>
> I have a script file that does it for me.  After starting a new image I just
> have to fileIn the one file and about 30 seconds later the image has been
> tweaked, all required packages installed, the image saved under a new name
> and all three files backed up.
>

Cool!  Thanks, Ian.  It looks like I'll have to play with that idea a
bit to discover where some of the settings I want are, but your script
gives a nice starting point.

Randy
--
Randy Coulman
NOTE: Reply-to: address is spam-guarded.  Reassemble the following to
reply directly:
rvcoulman at acm dot org