Is there anyway to reduce the size of the Openedge install?

I've posted on this problem before. With the new release cycle of

progress it's going to get to a point where people won't install the

newer versions because of the hassle involved. Quite apart from the

sheer physical side of things, having to deinstall before installing a

new version is problematical.

Ahh, the good old days when a progress installation was just a

directory that you could just delete ...

Progress need to make things much much simpler to get people to follow

the upgrade paths.

One thing that you may want to consider is to set up a server for each

group / site of pc's that has a dropbox account (or something similar)

. So you put the installation media into your folder and it then get's

automatically synced to all "child" servers. Once there, you can

install from the local copy

Julian

On 24 September 2013 09:12, Craig Roberts

Julian,

Exactly, you want to keep downtime on a live site to a minimum. As a developer I want to be using the latest versions of Openedge, but the hassle and time spent installing on live sites makes you think twice about upgrading to a newer version of Openedge.

The dropbox idea is definitely an option.

Thanks,

Craig

We have same problem here. But Progress seems to just ignore those problems and make them even worse from version to version.

To reduce size for 10.2B setup we have extracted the setup to a temporay folder than deleted every files and folders we thought we will not need. Reduced size = 467MB. We deploy this to our customers and make a silent instal there. So far no problems arised.

For the service packs we did the same. So SP6 for 10.2b has a size of 198MB. Again no problems here.

What we would need from Progress is more support and description to files and folders we can strip out.

Regards

Josef

I've posted on this problem before. With the new release cycle of

progress it's going to get to a point where people won't install the

newer versions because of the hassle involved. Quite apart from the

sheer physical side of things, having to deinstall before installing a

new version is problematical.

Are you saying you need to uninstall (say) 11.1 before installing 11.2? I have had up to 5 concurrent versions installed on my Windows machine without any problems.

Not saying the size isn't problematic, but wanted to clear that up too.

-- peter

if I upgrade my clients licence to 11.3, I am not allowed to keep the

11.2 runtime installed.

Plus, on top of that, you have all the hassle of trying to install

another version (different ports, processes etc)

this is not a trivial task for an unattended install ...

On 24 September 2013 13:45, Peter Judge

We too see this install size as a problem and also agree what Julian said about uninstalling and installing etc.

It would be nice if OpenEdge installation could optionally be upgraded to a newer version (without the need to uninstall), keeping the same ports and other settings. At minimum, we should be able to export and import selected settings (conmgr.properties, ubroker.properties etc.). This would help upgrading to a new version or moving an installation to another machine. There is always possibility for an error when manually editing/copying properties files.

Also, having several versions on one machine should be easier; now you have to manually change the AdminPort and other ports for every version so that they don't overlap. 

Another issue has been that if you have several versions and then uninstall an older one, the newer one could be crippled because the uninstall removed some common files which are needed also by the new version. I hope this is not an issue with the latest releases (OE11), I have not tested.

Silent install is a nice feature, but too often it fails because of missing Document Explorer, .NET framework version etc. Could we have a 'hybrid' installation method so that we can use normal non-silent install but still use a response file like in silent installation? The response file would be used as default values for installation data. Or alternatively, the silent install should show the reason for failure in a user friendly way.

I just hope that progress are listening ... perhaps they should try to

deploy and upgrade their products to hundreds of existing and new

sites ...

On 25 September 2013 09:17, Marko Myllymaki

While we are on the subject. Another inhibitor to upgrading is the fact that older versions of the DB can not connect to newer versions of the DB. Internally we had a number of legacy progress v9 systems which needed to be upgraded to v10.2 which all connect to each others DBs. Basically we had to migrate all the systems at the same time onto new servers with 10.2B installed, migrate all the data, tested it and then do a switch over (big project - fraught with problems). It would have been less time consuming and safer to do a staged upgrade one server at a time (smaller project - more manageable). We probably used v9 longer than we should have and will now stick with 10.2B for years because of the hassle of upgrading everything.

Can you elaborate on what you mean?  DBs don't connect to each other; clients connect to DBs.  A v9 client can't connect to a v10 DB; but a v10 client can connect, via TCP, to a v9 DB.  Same is true for moving from 10 to 11.

Was it not possible in your case to upgrade one system at a time on this basis?  Does each system have clients that connect to the others' DBs?  If that is the case then a change to the function of the OE installer isn't going to help you; what you really need is a redesign of your systems.

Yes, it's a v9 client that connects to mutiple DBs on different servers. So if one gets upgraded they all have to be.

And a redesign is in order but it is an issue of time and resources available to get it done.

And apologies it was more a comment on upgrading in general rather than the installer.

WebClient?

As to a fat client, in the past I have stripped an installation by starting with just a prowin32.exe and then adding all required bits that resulted in the runtime not starting. The end result is tiny. As soon as you start doing 'exotic' things like XML other dependency DLLs raise their head. This is used for a demo install, I would be hesitant to use this in a production environment.

For 11.2 from the %DLC% directory:

convmap.cp
progress.cfg
promsgs
startup.pf

From the %DLC%\bin directory:

icudata-psc.dll
icuuc-psc.dll
progress.ini 
prow32.dll
prowin32.exe
prowin32.exe.manifest
prox.dll 
proxml.dll
snbcdm.dll
xerces_psc.dll

Message was edited by: Stefan Drissen - added list of required files

craig.roberts@henderson-group.com wrote:
Yes, it's a v9 client that connects to mutiple DBs on different servers. So if one gets upgraded they all have to be.
And a redesign is in order but it is an issue of time and resources available to get it done.
And apologies it was more a comment on upgrading in general rather than the installer.

You should be upgrading the clients one by one and keeping the db on 9. When all clients are at 10 you can upgrade the databases to 10 one by one.