Missing "assemblies.xml" file

Problem is - I'm not seeing this file in the $DLC directory tree.

AFAIK there is nothing like a default assemblies.xml file in the DLC folder.

There's on in the workspace root, however it has no references to anything in the $DLC directory.

The purpose of the file is to have references to Infragistics Controls and Microsoft .NET assemblies. The workspace root is the wrong location. It should be in the project root (if you haven't activated the Shared AVM on 10.2B) or the Shared AVM working directory or in a folder which is referenced by the -assemblies startup parameter (-assemblies c:\this-is-the-folder\subfolder).

The parameter needs to be added to the properties of the OpenEdge project.

Of course then you might get in trouble when the assemblies.xml file references the 10.2A UltraControls (something with v8.1) and you are on 10.2B that ships with newer UltraControls (9.2.20092.2017).

You might as well be o.k. to just add all Infragistics assemblies to your project manually from the Assemblies tab in the project properties.

mikefe wrote:
There's on in the workspace root, however it has no references to anything in the $DLC directory.
The purpose of the file is to have references to Infragistics Controls and Microsoft .NET assemblies. The workspace root is the wrong location. It should be in the project root (if you haven't activated the Shared AVM on 10.2B) or the Shared AVM working directory or in a folder which is referenced by the -assemblies startup parameter (-assemblies c:\this-is-the-folder\subfolder).
The parameter needs to be added to the properties of the OpenEdge project.
Of course then you might get in trouble when the assemblies.xml file references the 10.2A UltraControls (something with v8.1) and you are on 10.2B that ships with newer UltraControls (9.2.20092.2017).
You might as well be o.k. to just add all Infragistics assemblies to your project manually from the Assemblies tab in the project properties.

This is really counter-intuitive.

For one of my tests I created a workspace, then made a project in - which made it a sub-directory.  From what I'm reading that you're saying - the workspace and project root should be one and the same?

I found an assemblies.xml file in the zip file holding the demo code, and put it in the project root.

Now I'm getting a bunch of these complaints:

Could not load file or assembly Infragistics2.Documents.v8.1, Version=8.1.20081.1000, Culture=neutral, PublicKeyToken=7dd5c3163f2cd0cb or one of its dependencies. testui Unknown 1269720450748 52

Is this still a propath issue? If so, should I be pointing it to $DLC/bin/infragistics/winforms?

Could not load file or assembly Infragistics2.Documents.v8.1, Version=8.1.20081.1000, Culture=neutral, PublicKeyToken=7dd5c3163f2cd0cb or one of its dependencies. testui Unknown 1269720450748 52

It's looking for the 10.2A versions from Infragistics. Are you on 10.2B? Then change the filenames to v9.2 and the Version to 9.2.20092.2017

mikefe wrote:
Could not load file or assembly Infragistics2.Documents.v8.1, Version=8.1.20081.1000, Culture=neutral, PublicKeyToken=7dd5c3163f2cd0cb or one of its dependencies. testui Unknown 1269720450748 52
It's looking for the 10.2A versions from Infragistics. Are you on 10.2B? Then change the filenames to v9.2 and the Version to 9.2.20092.2017

Good grief. OEA should be able to figure this out by itself.

Thanks!

I thought there was some kind of update/conversion tool for this, but Mike would know much better than I.

Just be glad it isn't hardwired all over the application!  At least there is only one file to update.

I thought there was some kind of update/conversion tool for this, but Mike would know much better than I.

That conversion tool is expected to run when you migrate a 10.2A workspace to 10.2B. Not when creating a new project (and that's what I understand is what Tim did). One might purposely be working with "old" assemblies.

But the whole assemblies.xml topic is certainly something we'll discuss (hands on) at the NEPUG meeting on April 12: http://communities.progress.com/pcom/message/85154#85154

I found a doc on-line which discusses this issue:

http://documentation.progress.com/output/OpenEdge102b/pdfs/oearchitect/oearchitect.pdf#page=292

This led me to a menu option in OEA which is supposed to migrate the assemblies file - so I hit it, picked the appropriate projects, fired it off - and nothing happened.

I finally decided to go through and manually map the old versions to the new versions and now it seems to be doing better.

I must say - this has been a real pain in patooti.

Converting a workspace makes sense ... and you're right, one wouldn't want it to be automatic ... but it wouldn't have hurt to expose the tool.

Is it likely Tim could solve this by simply swapping in an assemblies.xml file from elsewhere?

Is it likely Tim could solve this by simply swapping in an assemblies.xml file from elsewhere?

Yes.

Or remove all (wrong) assembly references using the appropriate section of the project references and readding the proper version.

tamhas wrote:
Converting a workspace makes sense ... and you're right, one wouldn't want it to be automatic ... but it wouldn't have hurt to expose the tool.
Is it likely Tim could solve this by simply swapping in an assemblies.xml file from elsewhere?

The tool is 'exposed' - I didn't know it was there or what it's supposed to do. Even then, when I ran it nothing happened.

Second, there's no assemblies.xml file in the $DLC part of the system for me to swap over to.

PSC needs to update their examples so they'll work with 10.2B out of the box....

I wouldn't expect there to be an assemblies.xml under DLC necessarily since it is something that one tailors to the actual controls that one uses.  I was thinking that you might have another one which included all of the IG controls from converting a 10.2A workspace or some other project..

Updating the samples is a nice idea, but they should then have both versions of the assemblies.xml available since not everyone is going to be on the latest release.