Export (0) Print
Expand All
This topic has not yet been rated - Rate this topic

Compartmentalize Your Solutions

[Applies to: Microsoft Dynamics CRM 2011]

For long term success, you should consider how many solutions you want to release and whether the solutions will share components.

You must determine how many Microsoft Dynamics CRM organizations you will need to develop your line of solutions. You can use a single organization for most of the strategies described in this topic. However, if you choose to have only one organization and later realize that you need more than one, it can be challenging to refactor the structure of your solutions for people who have already installed them.

Using multiple organizations when you develop your solutions provides better flexibility yet also introduces more complexity. It is worth your time to develop a strategy for how you intend to organize multiple solutions with shared components. The content in this topic introduces basic concepts. For more comprehensive guidance, see Enterprise Solution Lifecycle Management.

Strategies to Compartmentalize Your Solutions

The following are some strategies for creating solutions listed in order from simplest to most complex:

No Custom Solutions

If you do not intend to distribute your solution, there is no requirement to create a solution. You can customize Microsoft Dynamics CRM directly by using only the default solution.

You can still export your default solution as an unmanaged solution to transport it between organizations.

TipTip
If you change the customization prefix for the default publisher to a value that matches a publisher you may want to create in the future, any new customizations that you create will include this customization prefix in the name. This way, if you choose to use solutions, you can add the customizations that you created in your default solution to an unmanaged solution so they can have consistent names.

Single Solution

By creating a solution, you establish a working set of customizations. This makes it easier to find items that you have customized.

This approach is recommended when you only want to create a single managed solution. If you think you may have to split up the solution in the future, you should consider using multiple solutions

Multiple Solutions

If you have two unrelated solutions that do not share components, the most direct approach is to create two unmanaged solutions. However, if you believe you may have to eventually share components, you should consider how you will manage them.

noteNote
It is very common in solutions to modify the application ribbons or the Sitemap. If both of your solutions modify these solution components, they are shared components.

Multiple Solutions with Some Shared Components

You may have multiple solutions that share components. You may have a certain set of common functionality within multiple solutions and that common functionality is compatible with any of the other functionality unique to each solution. For example, you may have a set of utility plug-ins that each solution uses yet each of the separate solutions do not share any other components.

In this case, each solution can be developed in a single organization. Some components can be included in more than one solution as long as any changes that were made to them are compatible with all other solutions that use them. It is important that all the solutions share the same solution publisher. If the solution publisher is not identical, organizations will not be able to install more than one of your solutions.

Solution Libraries

For an ISV with multiple solutions or a large enterprise deployment, it is expected that many solution components will have to be shared. The best ways for solutions to share components is to create solution libraries. You create a solution library by creating an unmanaged solution in a separate organization and then package those components into a managed solution. Install the managed solution into another organization and let developers reference these shared components from the solutions they create.

The Microsoft Dynamics CRM Solutions Framework lets you build layers of solutions that depend on each other. Typically, you create a solution library representing a ”base” solution. Other solutions can be built on top of this base solution.

This allows for cleaner separation of components. Development teams that are working on solution libraries and those working on the dependent solutions can develop at different paces. The dependent solutions must be created after the solution libraries are installed.

This requires that you create a prerequisite solution that customers must install before they can install a dependent solution. Developers working on the solution libraries can continue to work on them and update them as necessary as long as they don’t break any dependent solutions that require them.

See Also

Microsoft Dynamics CRM 2011
Send comments about this topic to Microsoft.
© 2013 Microsoft Corporation. All rights reserved.
Did you find this helpful?
(1500 characters remaining)
Thank you for your feedback

Community Additions

ADD
Show:
© 2014 Microsoft. All rights reserved.