Determine which assemblies are referenced by r-code

Run it and see where it falls over?

/sarcasm

Seriously though, good question!

I don't believe the AVM publicly exposes these. Sounds like a reasonable enhancement request. As Mike suggests, you could take a look at the text strings in the r-code, but this is unsupported and subject to change without notice.

I disagree that control over the build environment will solve the entire problem, because it is in exactly that type of environment where I look to incorporate this.

My concern is with assemblies that are used and shipped with the product at one time or another, but become redundant over time.

For instance, if somebody used a third-party assembly to consume REST based AppServices and later switch to 11.5, they can now consume these services directly. The existing code can stay active for years, but as developers encounter it they may remove it, without any deliberate effort to completely remove the assembly from the source base. Eventually all of it may be removed and the assembly will become redundant, but nobody will be sure off hand if that state has been reached.

This is where I want the continuous build process to warn me that I have an unused assembly reference in assemblies.xml. When I get the report, I can take proper steps to remove the assembly not only from assemblies.xml, but also from the list of files that must be included in a deployment.

The only alternative I can find this far is to remove lines from the assemblies.xml and recompile the entire source base to see if something fails, which is not a particularly attractive way of doing things and it is hardly the type of dirty process that I would want to automate.

Another use of this would be in configuration management, e.g. when you selectively ship modules based on a user's license. Some assembly may fall into disuse in a module that is the only module that user A had, referencing that assembly, but user B also have a different module referencing it. Now I need to go through the above exercise for every possible deployment permutation, while I would prefer to be able to build once and create the various permutations automatically by tailoring the assemblies.xml and files to ship as part of the build process.

Is your suggestion that, after a successful build, the build script should remove each assembly in turn and rebuild, reporting only if the build does not fail, so that you can remove the redundant assembly?

Remember I am talking about situations that can occur during long term system maintenance, not during a concious decision to get rid of a specific assembly.

Just like a piece of r-code can become redundant without anybody noticing, the same can happen to an assembly. Both will bloat the distribution, neither is wanted.

It just seems that it should actually be easy to detect and eliminate assemblies, especially as they can often be considerably larger than r-code.

Perhaps this is a silly question that reflects my limited experience with these assemblies, but why would one try to solve the problem in r-code?  It seems like it would not be a difficult extension of ABL2DB to keep track of what assemblies are referenced in the source code and where they are referenced.  Then, if one wanted to change one, one could quickly report on where used and make the changes.  And, it would be a trivial report to identify unused ones.  At a site without source, that wouldn't work, of course, but isn't the question asked here in the context of continuous integration builds?

That is certainly an option.

I was just thinking along the lines of the RCODE-INFO system handle that tells us:

1. DB-REFERENCES

2. TABLE-LIST

3. TABLE-CRC-LIST

4. DISPLAY-TYPE

Looking at these fields in r-code enable you not only to reliably find what is used (a grep in source may pick up stuff that is actually in large comment blocks) but also enables other house keeping.

While continuous build is definitely one application and also a good candidate for ABL2DB, I am also thinking about a way to assemble packages for distribution.

Unless your AppServer code is .Net bound, you can filter out all r-code that reference .Net assemblies when creating the server distribution.

If the whole system is mainly OO based, you could similarly start out with everything referencing the .Net assemblies as the base for the UI and then add whatever other classes are referenced by those (as well as the odd .p based pieces that are still needed). In theory that should give a distribution with the smallest possible footprint without the risk of missing something and the additional advantage that assemblies referenced only in tools assisting with development and building could be identified and omitted from deployment packages.

But as long as you have a complete source base, ABL2DB is most likely a more flexible tool to implement this.

Another application could be trouble shooting. If a troubleshooting utility can run through all r-code on a WebClient installation and determine which assemblies that are referenced cannot be found on the local machine, it could be a huge advantage, but I guess if you use build tools and ABL2DB (or similar) to keep assemblies.xml clean, it would most likely be more efficient to parse that.

So, is this a request to add assembly tracking to ABL2DB? :)

I Guess it is. :-)

Just to conclude this thread:

There is no programmatic way to determine a program's dependencies (neither assemblies nor classes referenced by it).

The only solution seems to parse the source of the entire inheritance tree, list everything exposes by the USING statements, and then

a) Determine which items in the list are used in variable, property and parameter definitions.

b) Determine which items in the list are used in TYPE-OF(), CAST() and GET-CLASS() functions.

c) Determine which fully qualified type names are referenced in the above constructs.

On the list ... www.oehive.org/.../2246