Dependency Tracking for Solution Components
Solutions are made of solution components. You will use the Solutions area in Microsoft Dynamics CRM to create or add solution components. You can perform these actions programmatically by using the AddSolutionComponentRequest message or any messages that create or update solution components that include a SolutionUniqueName parameter.
Solution components often depend on other solution components. You cannot delete any solution component that has dependencies on another solution component. For example, a customized ribbon will typically require image or script Web resources to display icons and perform actions using scripts. As long as the customized ribbon is in the solution, the specific Web resources used by it are required. Before you can delete the Web resources you must remove references to them in the customized ribbon. These solution component dependencies can be viewed in the application by clicking Show Dependencies.
This topic describes the types of solution components you can include in your solutions and how they may depend on each other.
In This Topic
The complete list of available solutions component types is located in the system Component Type (componenttype) global option set. The supported range of values for this property is available by including the file SampleCode\CS\HelperCode\OptionSets.cs or SampleCode\VB\HelperCode\OptionSets.vb in your project. However, many of the solution component types listed there are for internal use only and the list does not provide information about the relationships between solution components.
Solution Component Dependencies
Solution component dependencies help make sure you have a reliable experience working with solutions. They prevent actions that you normally perform from unintentionally breaking customizations defined in a solution. These dependencies are what allow a managed solution to be installed and uninstalled simply by importing or deleting a solution.
The solutions framework automatically tracks dependencies for solution components. Every operation on a solution component automatically calculates any dependencies to other components in the system. The dependency information is used to maintain the integrity of the system and prevent operations that would lead to an inconsistent state.
As a result of dependency tracking the following behaviors are enforced:
Deletion of a component will be prevented if another component in the system depends on it.
Export of a solution will warn the user if there are any missing components that could cause failure when importing that solution in another system.
Warnings during export can be ignored if the solution developer intends that the solution is only to be installed in an organization where dependent components are expected to exist. For example, when you are creating a solution that is designed to be installed over a pre-installed ”base” solution.
Import of a solution will fail if all required components are not included in the solution and also do not exist in the target system.
Additionally, when importing a managed solution all required components must match the package type of the solution. A component in a managed solution can only depend on another managed component.
- Additionally, when importing a managed solution all required components must match the package type of the solution. A component in a managed solution can only depend on another managed component.
There are three types of solution component dependencies:
- Solution Internal
- Internal dependencies are managed by Microsoft Dynamics CRM. They exist when a particular solution component cannot exist without another solution component.
- Published dependencies are created when two solution components are related to each other and then published. To remove this type of dependency the association must be removed and the entities published again.
- Unpublished dependencies apply to the unpublished version of a publishable solution component that is being updated. After the solution component is published, it becomes a published dependency.
Solution internal dependencies are dependencies where actions with a solution component require an action for another solution component. For example, if you delete an entity, you should expect that all the entity attributes will be deleted with it. Any entity relationships with other entities will also be deleted.
However, an internal dependency may lead to a published dependency and still require manual intervention. For example, if you have included a lookup field on an entity form and then delete the primary entity in the relationship, you cannot complete that deletion until you remove the lookup field from the related entity form and then publish the form.
When performing actions programmatically with solutions you can use messages related to the Dependency entity. See Dependency Entity Messages and Methods for messages you can use to identify dependencies that may exist before you delete a component or uninstall a solution.
Check for Solution Component Dependencies
When you edit solutions by using Microsoft Dynamics CRM 2011, you may find that you cannot delete a solution component because it has a published dependency with another solution component. Or, you may not be able to uninstall a managed solution because one of the components in the managed solution has been used in a customization in another unmanaged solution.
The following table lists the messages that you can use to retrieve data about solution component dependencies.
Returns a list of dependencies for solution components that directly depend on a solution component.
For example, when you use this message for a global option set solution component, dependency records for solution components representing any option set attributes that reference the global option set solution component are returned.
When you use this message for the solution component record for the account entity, dependency records for all of the solution components representing attributes, views, and forms used for that entity are returned.
Returns a list of the dependencies for solution components that another solution component directly depends on. This message provides the reverse of the RetrieveDependentComponentsRequest message.
Returns a list of all the dependencies for solution components that could prevent deleting a solution component.
Returns a list of all the dependencies for solution components that could prevent uninstalling a managed solution.
These are the solution components displayed in the application and the components that you will work with directly when adding or removing solution components using the solution page. Each of the other types of solution components will depend on one or more of these solution components to exist.
Application Ribbons (RibbonCustomization)
Ribbon customizations for the application ribbon and entity ribbon templates. Application ribbons do not include definitions of ribbons at the entity or form level.
Custom application ribbons frequently have published dependencies on Web resources. Web resources are used to define ribbon button icons and JScript functions to control when ribbon elements are displayed or what actions are performed when a particular ribbon control is used. Dependencies are only create when the ribbon definitions use the
$webresource: directive to associate the Web resource to the ribbon. For more information, see$webresource directive.
Article Template (KBArticleTemplate)
Template for a knowledge base article that contains the standard attributes of an article. There is always an internal dependency between the article template and the KbArticle entity.
Connection Role (ConnectionRole)
Role describing a relationship between a two records. Each connection role defines what types of entity records can be linked using the Connection role. This creates a published dependency between the connection role and the entity.
Contract Template (ContractTemplate)
Template for a contract containing the standard attributes of a contract. There is always an internal dependency between the contract template and the contract entity.
Dashboard or Entity Form (SystemForm)
System form entity records are used to define dashboards and entity forms. When a SystemForm is used as an entity form there is an internal dependency on the entity. When a SystemForm is used as a dashboard there are no internal dependencies. Both entity forms and dashboards commonly have published dependencies related to their content. An entity form may have lookup fields that depend on an entity relationship. Both dashboards and entity forms may contain charts or subgrids that will create a published dependency on a view, which then has an internal dependency on an entity. A published dependency on Web resources can be created because of content displayed within the dashboard or form or when a form contains JScript libraries. Entity forms have published dependencies on any attributes that are displayed as fields in the form.
Email Template (EmailTemplate)
Template for an email message that contains the standard attributes of an email message. An email template typically includes fields that insert data from specified entity attributes. An email template can be linked to a specific entity when it is created so there can be an internal dependency on the entity. A global email template is not associated with a specific entity, but it may have published dependencies on entity attributes used to provide data. A process (workflow) frequently is configured to send an email using an email template creating a published dependency with the workflow.
The primary structure used to model and manage data in Microsoft Dynamics CRM. Charts, forms, entity relationships, views, and attributes associated with an entity will be deleted automatically when the entity is deleted because of the internal dependencies between them. Entities frequently have published dependencies with processes, dashboards, and email templates.
|The use of dependencies changes some of the behavior compared to behavior found in Microsoft Dynamics CRM 4.0. For example, in Microsoft Dynamics CRM 4.0 you could delete a custom entity that has a 1:N entity relationship with another entity as long as the lookup attribute in the related entity wasn’t in a published form. The new behavior is that you will not be able to delete the custom entity until you first delete the lookup attribute in the related entity or the entity relationship, which would remove the lookup attribute.|
Field Security Profile (FieldSecurityProfile)
Profile that defines the access level for secured attributes.
Mail Merge Template (MailMergeTemplate)
Template for a mail merge document that contains the standard attributes of that document. A mail merge template has a published dependency on the entity it is associated with.
Option Set (OptionSet)
An option set defines a set of options. A picklist attribute uses an option set to define the options provided. Several picklist attributes may use a global option set so that the options they provide are always the same and can be maintained in one place. A published dependency occurs when a picklist attribute references a global option set. You cannot delete a global option set that is being used by a picklist attribute.
Plug-in Assembly (PluginAssembly)
Assembly that contains one or more plug-in types. Plug-ins are registered to events that are typically associated with an entity. This creates a published dependency.
Set of logical rules that define the steps necessary to automate a specific business process, task, or set of actions to be performed. Processes provide a wide range of actions that create published dependencies on any other solution component referenced by the process. Each process also has a published dependency on the entity it is associated with.
Data summary in an easy-to-read layout. A report will have published dependencies on any entity or attribute data included in the report. Each report must also be associated with a Report category creating an internal dependency on a solution component called Report Related Category (ReportCategory). Reports may be configured to be sub-reports creating a published dependency with the parent report.
SDK Message Processing Step (SDKMessageProcessingStep)
Stage in the execution pipeline that a plug-in is to execute.
Security Role (Role)
Grouping of security privileges. Users are assigned roles that authorize their access to the Microsoft Dynamics CRM system. Entity forms can be associated with specific security roles to control who can view the form. This creates a published dependency between the security role and the form.
|Only Security Roles from the organization business unit can be added to a solution. Only a user with read access to those security roles can add them to a solution.|
Service Endpoint (ServiceEndpoint)
Service endpoint that can be contacted.
Site Map (SiteMap)
XML data used to control the application navigation pane. The site map may be linked to display an HTML Web resource or an icon in the site map may use an image Web resource. When the
$webresource: directive is used to establish these associations a published dependency is created. For more information, see $webresource directive.
Web Resource (WebResource)
Data equivalent to files used in Web development. Web resources provide client-side components that are used to provide custom user interface elements. Web resources may have published dependencies with entity forms, ribbons and the SiteMap. When the
$webresource: directive is used to establish associations in a ribbon or the SiteMap, a published dependency is created. For more information, see $webresource directive.
|Web resources may depend on other Web resources based on relative links. For example, an HTML Web resource may use a CSS or Script Web resource. A Silverlight Web resource displayed outside of an entity form or chart must have an HTML Web resource to host it. These dependencies are not tracked as solution dependencies.|
Other ResourcesPackage and Distribute Extensions
Microsoft Dynamics CRM 2011
Send comments about this topic to Microsoft.
© 2013 Microsoft Corporation. All rights reserved.