Service Pack 2 and Ultra Controls

Is it just me and my ignorance regarding what assemblies.xml is all about or would it be reasonable to think that the service pack ought to handle that in the future and that this is just a one-time oversight?

You are right that assemblies.xml IMHO should be updated automagically.

Call me stupid (for this and other reasons), but I'm happy with maintaining the Assemblies.xml file manually.

Maybe an option during the service pack setup - like the one asking if you'd like to upgrade the Dynamics repository when installing a new Progress release - would be helpful.

When an how? I have an assemblies.xml file in every project. A rough guess are ~ 30 occurances all accros my hard drive. Which one do you want to have updated automatically? And when? During the SP process or when starting the workspace?

And how about end users? They usually will be using the assemblies.xml file from %DLC%\bin\infragistics\winforms. The old one was replaced by the SP setup. If the assemblies.xml file in the application root directory (or a folder pointed to by the -assemblies parameter) still refers the old dll files, the user is in trouble. I'd rather deploy the dll files with the assemblies.xml in a folder referenced by the -assemblies parameter (we usually use -assemblies Assemblies). That ensures that the users are using the version of the Infragistics controls "released" by the application vendor. So to say, it's not uncommon, that I have multiple copies of the Infragistics dll files here and there.

IMHO deploying the assemblies dll files and the assemblies.xml should be done by the application vendor, not a Progress service pack setup.

I would expect a question the first time a project is opened in the new version.

Can you have more than one directory in the -assemblies startup parameter ? I would like to keep the .dll's for each vendor in a separate directory so I can track different versions of each control.

Julian

Can you have more than one directory in the -assemblies startup parameter ?

I don't believe so.

I would like to keep the .dll's for each vendor in a separate directory so I

can track different versions of each control.

Do you always copy the DLLs to -assemblies (even when they're in the GAC)? Do you deal with GAC-registered assemblies differently? Enquiring minds etc

-- peter

I will try to answer all questions asked but I may miss one or two so please keep me honest.

OpenEdge Service Packs:

Our goal (as always) it to keep a service pack install as simple as possible. When a new version of UltraControls is put into a service pack, it is always a replacement for the "current" release. In the case Mike points out the UltraControls version went from Version=8.1.20081.1000 to Version=8.1.20081.2150. Since this is always a replacement, the assemblies.xml file does not need to be changed. Instead there is a file installed in dlc\bin called Prowin32.exe.config which automatically performs this redirection every time an assembly of the old version is referenced by an OpenEdge application.

If you are managing your assemblies.xml files yourself, you can hand-edit the version change or post 10.2B use the Assemblies migration tool to update the assembly references for a service pack update. Neither of these are necessary.

Note: There is a bug on VMs where the replacement and the original version of the UltraControls are both kept on the VM after the update install. The redirection Prowin32.exe.config still works you just need to know which version you are using. Our development team is working with Infragistics on fixing this bug.

OpenEdge Releases:

When a new version of OpenEdge and UltraControls is released that is a side-by-side install not a replacement (a new major/minor version), i.e. 9.1.x), existing assemblies.xml files and toolbox.xml files need to be updated. This is best done using the Assemblies migration tool. Within Architect of a new OpenEdge release, the first time an "old project" is opened, you will be prompted to update any local assemblies.xml and toolbox.xml files. If you say yes, the UltraControls references are all updated. If you say no, the references are left alone and it is your responsibility to update them at a later time. It is unsupported to run a newer version of Architect on an older version of the UltraControls.

Assemblies Directory:

There is only a single assemblies directory per session, by default it is the working directory for Prowin32. It can be overridden using the -assemblies startup parameter. The assemblies directory and its sub-directories are where all third party assemblies not installed into the GAC must be found. During development many controls are installed into the GAC but their deployment model uses local files. This means that you assemblies.xml file must take into consideration development versus deployment.

.NET will only search a single directory to find assemblies that are not loaded from the GAC or dlc\bin. .NET will not search ProPath or any hard-coded assembly paths. The assemblies.xml file lists the assemblies references by name not location. You can have as many files listed in the assemblies.xml file as you want as long as they are in the GAC or can be found relative to your assemblies directory.

-Shelley

I believe this warrants a white paper...

Hi Shelley,

The Whitepaper sounds great!!!

The automatic redirection did not work for me. I got compile errors

until I updated the assemblies.xml file.

No VM involved.

Mike

Hi Shelly - a quick question:

The assemblies directory and its sub-directories are where all third party assemblies not installed into the GAC must be found

What do you mean by "and it's sub-directories" ? Can I put .dll files in subdirectories of the assemblies directory ?

Julian

Mike

When you have a chance please log a bug on the failure of the .config file. It should have worked.

Thanks

-Shelley

Hi Julian,

Yes, the assemblies (.dlls) can be in a subdirectory of the assemblies directory.

I realized that I did not provide a solution to your question on different versions of the same vendor dlls in different assemblies directories. I would put those in different subdirectories on my development machine and have the assemblies.xml for an application specify which version to use.

-Shelley

Will do - the prowin32.exe.config file is present - and it contains (probably) the right directives:

In 10.2a02, user has to explicitly update the assemblies.xml and toolbox.xml manually because control versions are upgraded.

OpenEdge ultra controls get updated automatically from 10.2B during workspace startup.