Very often there is a requirement to create Web Resources to be used in Dynamics CRM that provide some form of user interface. Sometimes it may just be to display some data that you otherwise could not display using QuickView Forms, sometimes its to provide some buttons to trigger integrations that need to be on a Dashboard.
I have seen instances where the standard Windows Grey buttons are used, and also seen Web Resources that are graphically styled like they have come straight out of the Web 2.0 UI style guide. These often look inconsistent with how Dynamics CRM looks, and can either be distracting, or look like a dog’s dinner.
Often, most good CRM developers will create a standard style sheet, upload it to their solution, and reference it from any Web Resource that needs it. I would say that this is still a good thing to do, but I wanted to enhance it a bit so that a UI provided by a Web Resource would blend in with CRM without any additional work. This has especially become crucial when a lot of companies will brand their Sandbox environments different to their Production environments (sometimes using garish colour schemes) to instantly alert their users as to which environment they are on. CRM provides Custom Themes for this task, and although they are still quite limited, I wanted to be able to tap in to this feature.
So, I had the idea of creating a mechanism that would automatically retrieve the Theme and style up any User Interface elements using those settings.
When working with Managed Solutions, and layering them on top of each other, be mindful of one very important fact.
If you include an entity in a solution, that is also present in another solution, then the most recent solution to be installed in a system will take precedent over others when it comes to certain things such as entity forms.
For example, if you have solution A containing entity 1 and install it managed onto a server, and then later install solution B which also contains entity 1, then it’s solution B’s customisations that will be applied. If you later edit entity 1’s form within solution A and try and install it onto the server containing both solutions, the form customisations will not take.
You must always try and ensure, where possible, that each entity only exists in one solution. This would not apply if you were always going to be providing both solutions as a pair to be installed.
To safeguard, always attempt to create a new form in each solution so that customisations are carried out in each solutions specific form, and always try to avoid accidentally including entities in solutions where they don’t need to be as you can’t always roll them back due to dependancies.
Good news is that with CRM 2016, you can include only the bits you need in a solution making it easier to avoid these kind of layering issues.