Unmanaged Deployments: Deletion of legacy components and dependency handling

A blog post by Robert Pröll


Posted: 04.2019 | Category: ALM | Author: Robert Pröll Tags: DEPLOYMENTS DYNAMICS CRM CI/CD DEVOPS ALM

Robert Pröll | .NET Software Architect

Intro

- The decision if unmanged or managed is not part of this article, so let’s assume we are on a dev environment or unmanaged prod instance.

In enterprise projects it is very common that the data model changes quite often due to a business decision or minor technical reasons like wrong data types.

Let’s focus on the worst cases where fields are already in use in multiple places like charts, views, workflows etc.
– Those cases which always got the lowest priority to avoid any side-effects, until hard technical limits are reached (see 5. Alternative Key Limitation).

Duplicate Field Name: A field with this name already exists. Please enter a different unique name. If you contact support, please provide the technical details.”


Technical Background:

Like a staging process for managed solutions a dependency check will be performed if a component will be deleted.

CRM holds a list of depending components for each field, so each depending component needs to be either modified or deleted.  

Some dependencies are managed internally by CRM but others must be handled by hand:

  • Forms, Views, Charts, Apps etc.

Solve dependency-based import issue is always an irritating job, even with the help of the CRM UI it takes some time to recursively go through the dependency graph.


KDTooling

We have developed a more efficient way to get the job done. It’s a combination of explicitly specified components (like fields) and automatically detected legacy components (unmanaged components which are not referenced by any unmanaged solution).

The process modifies components like forms with the most possible granularity, so only a field will be removed without any other unnecessary changes.

Components like charts will be deleted only if they don’t make sense after the modification. (Chart with one field).


Autoresolve of Dependencies

Configuration

Sample: Fields for account


Conclusion 



About the author

Robert Pröll

.NET Software Architect

Key areas of interest: ALM, .NET C#, PowerShell, Azure, Dynamics 365 Tooling

Robert started in the area of ASP.NET projects and has now more than 10 years of experience in the international Dynamics Enterprise business.

He works mainly as a principal software architect at Kupp and as an external consultant for Microsoft.