locked
why does customisations.xml contain properties from another solution RRS feed

  • Question

  • I have two solutions in a crm development environment. Having made some changes to one of these and tested I try to import it to another system at which point it fails. A bit of digging reveals that the failure is while trying to import "acme_sprocket_ActivityPointers". Now "sprocket" is a custom entity which I enabled to be linked to activities so I can see why that would be there, except for one thing which is that sprocket doesn't exist in this solution!

    I have two solutions "Widget manager" and "Sprocket manager". Customisations that I make to "Sprocket manager" appear in the customisation.xml for "Widget manager" even though the corresponding entities are not in that solution. This of course means that when the import process reads the customisation file it fails unless the customer just happened to also have the second solution which they probably do not.

    So why is CRM doing this and how do I stop it!

    Thursday, November 7, 2013 5:09 PM

All replies

  • You are assuming that components in both solutions are independent of each other but they are not. Let me guess, relation between 'sprocket' and 'activity' is 1:N making a lookup of sprocket in activity? Now you have activity in your second solution(widget manager) too? So in 'widget manager' solution you have an entity having an attribute pointing to another entity(sprocket) which is not part of 'widget manager' solution or the default solution. Obviously the import fails. While exporting the solution, CRM must have shown you the dependency list (listing 'sprocket' entity as one of the dependent components). You can analyse closely in that window whether you are including some additional component unknowingly or not.

    CRM is just doing its job of making sure that solution integrity is not broken!


    - Arvind

    Friday, November 8, 2013 7:22 AM
  • You are assuming that components in both solutions are independent of each other but they are not. Let me guess, relation between 'sprocket' and 'activity' is 1:N making a lookup of sprocket in activity? Now you have activity in your second solution(widget manager) too? So in 'widget manager' solution you have an entity having an attribute pointing to another entity(sprocket) which is not part of 'widget manager' solution or the default solution. Obviously the import fails. While exporting the solution, CRM must have shown you the dependency list (listing 'sprocket' entity as one of the dependent components). You can analyse closely in that window whether you are including some additional component unknowingly or not.

    CRM is just doing its job of making sure that solution integrity is not broken!


    - Arvind

    That's correct that there is a 1:N relationship between sprocket:activity in solution 1 because sprocket can be linked to calendar events so it has to be linked to activities in the customisation for the sprocket entity.

    If CRM has included the link to sprocket in solution 2 because activity can link to sprocket in another solution then CRM is wrong. If I buy cement from a builders' merchants I don't expect them to insist on also delivering bricks just because another customer bought bricks for which they also needed cement! Equally just because solution 1 makes activity dependent on sprocket doesn't mean that if I am working on solution 2 in which activity is not dependent on sprocket I should be forced to include it. To insist so would be to fail the simplest of database normalisation principles.

    Having said that what I have noticed is that activity was included in solution 2 for some reason. If I remove activity from solution 2 CRM protests that activity is a required component. Activity is not a required component and in this mode CRM will import the solution and it works despite protesting at export that required components are missing. If I add activity to solution 2 CRM to get rid of the required component warning CRM does not demand that I include sprocket but then fails when importing the solution. All of which makes it look like CRM's integrity checking is broken and its basic database design is suspect.

    So thanks for the heads up about activity being included I wouldn't have thought to check that CRM had added that in otherwise but it does make me distrust CRM even more. It is not "just doing its job".


    • Edited by J N Brand Friday, November 8, 2013 10:29 AM
    Friday, November 8, 2013 10:27 AM
  • Agree to the fact that the way required component check works in CRM is not very clean and misses scenarios(like yours one) which is eventually caught while importing the solution .... very frustrating at times!

    We created table A and added a foreign key of it in Activity table. Now whereever this Activity table is ported, it will need table A or else it will be in a broken state because of the foreign key column. While selling the bricks and cement to other customer, the merchant came up with the idea of selling both together by packing them in bags (cemet+bricks). He is not selling the individual components anymore. If you buy cement(Activity), you need to take sprocket(bricks) too.

    Since solution(unmanaged) is nothing more than grouping of object, Activity in solution 1 and 2 represent the same set of tables and views in DB. It doesn't matter in which solution(1 or 2) activity is made dependent on some component, it will be reflected in all solutions where activity is included(created previously/now/in future).


    - Arvind (My posts represent my own views and not of Accenture's)

    Friday, November 8, 2013 12:27 PM
  • Though that illustrates why CRM fails basic normalisation.

    To use the builder's merchant analogy again. Packing cement in with the bricks makes sense because to build a wall you have to have mortar. Packing bricks in with the cement does not make sense because buying cement does not mean you are building a wall.

    In the same sense in your example you have created table A and linked it to activitives. In CRM this has created a property in activities which is a link to table A. This is wrong. Just because you can have table A linked from activities does not mean that every activity must link to table A. The link is a property of table A and not a property of activities (1). Had it been made a property of table A then other solutions from the same system could include activities without failing import or needing to include unrelated entities.

    (1) although to support all options of 0:N, 1:N, N:N linking etc it might make more sense to have the links defined in a supporting table rather than directly in table A. In that sense the link is more accurately a property of solution A rather than either table A or activities


    • Edited by J N Brand Friday, November 8, 2013 1:48 PM
    Friday, November 8, 2013 1:42 PM
  • I think you are missing some basics of database design.  To implement a 1:N relationship between table A and table B, an field is normally added to table B and a foreign key is created.  This isn't new or unique to Dynamics CRM, it is basic database design.  Table B may not have to have this field populated, but the field will be present in the schema.  To implement a N:N relationship, a join table is used, which is exactly what Dynamics CRM does.  A join table is not typical to implement a 1:N relationship as it is not required to fulfill the requirement and adds unnecessary complexity.  This is the methodology expected when normalizing a database.

    The issue with CRM solutions has nothing to do with normalization in the underlying database, as the database is not exported with a solution only the metadata necessary to create it.  The issue is that unmanaged solutions are not designed to separate concerns within CRM, only managed solutions are.  This is why exporting the unmanaged solution will not pull managed fields from third party solutions, and why removing a managed solution removes its fields whereas removing an unmanaged solution does not.  The name really says it all, nothing in an unmanaged solution is managed for you.  I make no assertions as to the reasons or validity of this approach, but this is the approach that is taken.

    Friday, November 8, 2013 3:11 PM
  • It seems we are assuming 'Activity' entity as some special entity which should not get modified because it links to lot of other entities. Activity and any other system entity are just like any custom entity. Any modification to any entity will reflect at all places. Microsoft CRM is highly customizable and does not restrict developer/customizer to make any changes to it. Its up to us to decide what changes are to be made to get the required customization done. If I choose to create some additional fields on email entity, it will allow me to do that and will show those changes at all places email entity is being used. As explained earlier, creating solutions just group them under a name so that they can be taken and deployed together to some other environment. Putting components in different solution does not create multiple copies of them. Managed solutions try to provide isolation but if two of them have changes related to same entity, the changes will be merged after both solutions are installed.


    - Arvind (My posts represent my own views and not of Accenture's)

    Monday, November 11, 2013 8:13 AM
  • Activity is "special" only in the sense that it is a part of the core CRM. If I am writing a solution there is absolutely no reason why I should not modify activities to include a reference to another entity and that is a perfectly valid solution and has no problems with normalisation. The problem comes when there is more than one solution. Now while my customisation for the first solution is perfectly valid and normalised the activities table now contains fields which are by definition redundant in the second solution, in order to preserve integrity CRM demands the inclusion of another entity which is also completely redundant in that solution. Yes to create a normalised relation between A and B we add a foriegn key in A to B we shouldn't have to also include a foriegn key to gamma.

    To argue that the normalisation isn't a problem because the metadata not the data is exported is just silly. Whether a database is normalised or not is implicit in the definition of the database not how it's populated. Yes it is a problem with management (or perhaps that should be mismanagement) of solutions because CRM has no real concept of managing a solution while in development. At that point a solution appears to be just a loose collection of links to other items in CRM and not a container containing those items. 

    Of course a simpler way to look at it is to say if I have given someone a solution to manage company car maintenance contracts and that solution also includes references to pet insurance is that valid? Is it rational? and yet CRM because of the way it implements relations to custom solutions can force that irrationality on you.



    • Edited by J N Brand Thursday, November 14, 2013 10:20 AM
    Monday, November 11, 2013 10:07 AM
  • I feel we are confusing between products like CRM, Sharepoint, etc. with totally other line of products like Visual Studio, SQL Server, etc.

    One Dev environment of CRM should be used to target only one project because we modify/customize the product itself to immitate the actual production environment. Its not a factory to create multiple deliverables related to different projects. In case we have such deliverables, we'll need to reset the product to its initial installation status(factory-reset kind of thing) before starting work on a new project. We normally do that by creating a separate dev environment for new project. With CRM we have the advantage to go with a new organization too instead of a new installation.


    - Arvind (My posts represent my own views and not of Accenture's)


    Tuesday, November 12, 2013 5:05 AM