IFS Developer Studio - bugs

Suppose you have two components, A and B, and A depends dynamically on B, with an entry in deploy.ini as well. During deployment, B needs to be deployed before A. Since the deployment order of components is not predefined unless there is a static dependency between them, if A starts deploying before B has been deployed, you will get deployment errors if the conditional compilation is not set properly in the code.

we are trying to catch these type of scenarios beforehand at development time to avoid these errors.

CC ​@Jonas Feigl 

Suppose you have two components, A and B, and A depends dynamically on B, with an entry in deploy.ini as well. During deployment, B needs to be deployed before A. Since the deployment order of components is not predefined unless there is a static dependency between them, if A starts deploying before B has been deployed, you will get deployment errors if the conditional compilation is not set properly in the code.

our attempt was to identify these type of potential issues at the development time before they become deployment isssues

CC ​@Jonas Feigl 

​@InfFilipV 

• Conditional compilation is not just used for the solution sets but also plays a vital part in deployment order handling. Even if a component is enabled in the solutionset, it will still be treated as “inactive” during the delivery installation if that component is also included in the delivery, to avoid object dependency errors.
• @DynamicComponentDependency was deprecated as it was causing an unjustifiable amount of non-deterministic deployment issues: If a view is sometimes created and sometimes not based on the content of the delivery it makes the installation behaviour unpredictable as other views/packages that reference the view will then sometimes deploy successfully… and sometimes not. 
• Your example 4 is the exact approach that I would suggest for a large view with many different dynamic dependencies as it is still readable and avoids deployment issues.
• Regarding you final question how this can cause issues: Dynamically dependent components are not deployed in a specific order so you are not guaranteed that the objects of the referenced components actually exist and are valid at the point that the view is deployed. Example:
  • You have referenced Inventory_Part_API in your view
  • Inventory_Part_API, deployed via InventoryPart.api sits in the INVENT component.
  • As you seemingly do not have a static dependency from your component to the INVENT component you are not guaranteed that INVENT, and therefore Inventory_Part_API, will be deployed before your view is deployed.
  • There are now multiple scenarios where this can fail deployment of your file:
    • If something is included in the delivery that makes Inventory_Part_API temporarily invalid until the INVENT component is fully deployed, your view will fail deployment.
    • If the method in Inventory_Part_API you are referencing is also introduced from the delivery, your view will fail deployment. Of course in this particular case you know that this will not be the case because it is a Core method but we have to have a solution that works for all methods and not just for some.
    • If you are doing a Fresh Install of a new environment the Inventory_Part_API will not exist at all yet. Again, this might not be a scenario you are currently performing but again we have to ensure that the deployment works for all scenarios and eventualities. 
  • Therefore:
    • Adding conditional compilation around the call to Inventory_Part_API will ensure that the API call is not added to the view when both, the view and the INVENT component are included in a delivery. The view will then be redeployed later on in the installation process when all components have been deployed and the dynamic dependencies are guaranteed to be present.
    • Not allowing usage of @DynamicComponentDependency ensures that the view is still always created and any other objects that reference it are also guaranteed to deploy successfully.

The amount of support cases we receive because of deployment issues caused by unhandled dynamic dependencies (i.e. lack of conditional compilation) in modifications and the fact that even you, who seems to have an otherwise solid understanding of the process, are asking how this can cause deployment failures, kind of proofs the point why this check is now enforced.

I do understand your pain though and agree with your point that this should’ve come with better communication and ideally only be enabled for 26R1 onwards.

​@hamalk I don’t think it is a feasible approach to give developers the option to disable the alerts as that will completely counteract the goal of enabling them in the first place. Ideally I would suggest to review if we can disable the check for 25R2 and before to allow customers to address the alerts as part of the RU going to 26R1 or later and not being caught off guard half way through an implementation.

References for this topic

Dynamic Dependencies - Technical Documentation For IFS Cloud
Component Deployment Profile File - Technical Documentation For IFS Cloud
Entity Modeling - Technical Documentation For IFS Cloud
Components - Technical Documentation For IFS Cloud
Dynamic Calls to Optional Components - Technical Documentation For IFS Cloud

Upvote everything ​@Jonas Feigl puts out: Layer Support for deploy.ini | IFS Community
So, they don’t sit for 3 years.