We have one huge application model, with a variety of business systems.
These business systems are what groups the Action Block Types.
Services, which are exposed to the client tier are in the Services Business System.
Operations, which are consumed by services, are in the Operations Business System (and so forth).
The problem we have, if a Service (build Pstep and AB) calls a lot of Operations (ABs), then these are all linked into the same C# DLL - there is no concept of static/dynamic packaging in C#. We haven't had a big issue since we converted from COBOL, but now that the application has grown, there are more Operations consumed by Services and the total size of the application is becoming quite large (++GBs).
Build times are also large ... because if a common Operation is changed (not the interface for it), then all affected Services are rebuilt. Adding up to some considerable build time. Another negative artefact is that the DLLs themselves are starting to become quite large ...
So, what is the expectation of packaging the target Operations into Opslib? Will these be included into the Service DLL? Or at link time it determines that the target AB is in an Opslib and doesn't need to add to the Service DLL as there already is an Opslib DLL that contains the AB.
I gave it a go and found that if the Operations and Services where in the same model, even though Opslib were generated for the Operations, the Operations were statically linked into the Services DLL.
Only when I separated the Services into another model did it work as I expected. However, this is not the behaviour I want - as it is considerable effort to move the large amount of services to another model - not counting the transition time for developers to conform to the new structure.
We are running Gen 8.5 at this site, with a CSE and GuardIEn.
Any advice is appreciated!