Forum Post: RE: Determine which assemblies are referenced by r-code

[Simon L. Prinsloo]

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.

Continue reading...