Microsoft Dynamics CRM (Archived)

Solution Components

(0) Share

Report

Posted on by Jay2014

Hi,

I have always compiled my customization separately in Solutions as follows :

* Entities

* Processes

Just thought i check, is there any better practice really ? Compiling the solutions in different entities makes it easier to maintain

Thanks,

*This post is locked for comments

I have the same question (0)

All responses (10)

Answers (0)

David Jennaway 14,065 on at

Like (1)

Report

There are many ways to do this, with several pros and cons. In general, I prefer to minimise dependencies between solutions, which means the solutions are more likely to be group by functional area (e.g. sales entities), rather than splitting out by component type.

That said, we sometimes split out code components (web resources, and plugin assemblies and steps), as they often have a different development owner

Was this reply helpful? Yes No
Jay2014 on at

Like (0)

Report

I like the idea of splitting by functional area, so if you have sales and Marketing .. That means you will have Contacts and Sales in both solutions ? Is that not harder to maintain than just having an entities Core Solution ?

Was this reply helpful? Yes No
Suggested answer

gdas 50,091 Moderator on at

Like (0)

Report

Hi ,

Although I am not clear about your questions . When you change any processes or entity component you should do publish or publish all customization going to solution or customization area in D365. In addition for web resource publish you can use XRMToolBox web resource manager or visual studio developer extension.

marketplace.visualstudio.com/items

www.xrmtoolbox.com/.../MsCrmTools.WebResourcesManager

Was this reply helpful? Yes No
gdas 50,091 Moderator on at

Like (0)

Report

You can also create one solution and use solution patching for your project different phases. Take a look my article for more understanding -

goutamdascrm.wordpress.com/.../solution-patch-in-microsoft-dynamics-365

Was this reply helpful? Yes No
Suggested answer

Kokulan 18,054 on at

Like (1)

Report

We have always found going with the approach of grouping solution components based on functional areas in most cases. But we did have scenarios where we wanted to have separate solution for Reports, or Templates or Security Roles.

So i would recommend the approach of sticking to functional grouping as much as you could and only have component type based solutions if there is a need for it.

Was this reply helpful? Yes No
Jay2014 on at

Like (1)

Report

For example, if i have Functional Group 1 and Functional Group 2 with a Contact entity related to Entity B just required by Functional Group 1. In essence Entity B would have to be added to both Functional Group 1 and Functional Group 2 because of its dependency to the contact entity right ?

Does this approach not lead to a lot of entities being added to Functional Solutions if they have other dependencies outside the Functional Solution ?

Was this reply helpful? Yes No
gdas 50,091 Moderator on at

Like (0)

Report

This is one of the reason it will be good practice to have one solution and the use patching. Let's say you have two solution with same entities , now both the solution moved as a managed in different env. Now in future you want to delete one field from one solution ,in that case you can't delete because of dependency of other managed solutions. Different solution is good when you have no dependency of components.

Was this reply helpful? Yes No
Jay2014 on at

Like (1)

Report

Thanks, i will stick to one Solution unless you have different views ?

Was this reply helpful? Yes No
Suggested answer

Kokulan 18,054 on at

Like (0)

Report

Just wanted to make a point for an unmanaged solution as well here: If the solution is internal not for any external customer, we tend to keep solution unmanaged on all environments. It may not be the best solution for all the scenarios but it solves a lot of issues we face between managed and unmanaged components. We decided to follow this for some projects due to the experience we had with managed solution deployment.

With the unmanaged solution, approach, we create a patch for every change we make, the path solution is just a container to move the changes to other environments.

Coming back to your decision on using Single solution, it will work most of the time but we found as we add more and more components it becomes one big solution with every single component

And I also found if we are developing for two completely different functional areas, it will be easy to find components if the solutions are separate.

In short, it depends on the number of components you will end up having in your solution, and also how many distinctively different functional areas you will be doing customization for.

Was this reply helpful? Yes No
Suggested answer

Rajesh Chungath 467 on at

Like (0)

Report

My suggestion is create separate solutions for each modules and make sure entity form or site map is getting updated always from the same solution. If we follow managed solution deployment and update same entity form/sitemap from different solutions my result duplication of filed in form or site map. This issue will occur if we move fields from one section to other or remove fields from form.

Was this reply helpful? Yes No