locked
Update of Managed solutions RRS feed

  • Question

  • At the moment I am busy creating various solutions for CRM 2011. These are packaged using (multiple) managed solutions for installation. Installation of these solutions works as expected the solution. However updating an existing solution with a never version is proving troublesome to say the least. I have seen the following errors so far:

    • Importing a view on which the iscustomizable property has changed (customizable in version 1, not customizable in version 2) causes an error during import; The view cannot be found for update.
    • Plugin Steps deleted in version 2 of the solutions are not being deleted in the target system after update. As these steps are part of a managed solution they cannot be deleted, the only method to get the new version is to delete the old version, but this also deletes all data.
    • A plugin type deleted from an assembly causes the update of a solution to fail. This because the target system does not remove the plugin steps.
    • A changed label on (for example) an attribute which has isrenamable set to false fails during import because the attribute cannot be renamed. This seems normal but I would expect that the original managed solution can update it self regardless of managed properties. AFAIK this is the case for adding attributes (in a version 2) to managed entities with customizable set to false.
    • Import two solutions with sitemap customizations works, the new items from both solutions are imported as expected. Updating solution 1 with a version 2 cause the sitemap items from the solution 2 to be removed from the sitemap, updating solution 2 does not restore the sitemap items.

    For most of these issues I have work arrounds of doing things manually or modifying some fields in the database but this is not what I would expect. Second most of what I now need to do to update a solution is impossible to do for CRM online. Does anyone have any suggestions how to handle these issues.


    Patrick Verbeeten

    W: www.wavextend.com
    W: www.patrickverbeeten.com
    Thursday, July 21, 2011 7:40 AM

Answers

  • Point 1: Just for clarification, are you using the same publisher for all of your solutions?  If you are using different publishers you will run into issues similar to this. 

    Point 2: When you import the second version of the solution it won't delete any metadata.  Solutions are additive - any component that has been imported as that solution will remain a part of the solution until the solution is uninstalled, or the component is deleted (special cases, such as delete a cusotmizable web resource).

    Point 3: This is by design.  If this same behavior is performed using the PluginRegistratoin tool it will fail as well.  Similarly to point 2, when the solution update is installed CRM doesn't have the capability to go through and delete the metadata that is not part of the solution.

    The rest of the points I will have to follow up on and try to update this post.

    Thanks for the input!


    Brandon


    Friday, July 22, 2011 11:31 PM

All replies

  • Patrick,

    I have been experiencing very similar issues - see my recent post - what I believe is that when a managed solution is updated (with overwrite option) the system should first check for managed components that exist in the prior version of the solution and if they no longer appear in the new version one of two things should occur:

    1. If the component appears in the default solution its MANAGED flag should be flipped to UNMANAGED - allowing you to delete in the default solution - and it should be removed from the solution
    2. Otherwise the component should be deleted - allowing for example a newer/alternate version of plugin, webresource etc.

    Whilst the basic principle of managed solutions is great there seem to be a few things to be improved in the implementation, or maybe we're doing something wrong???

    Chris

     

    Thursday, July 21, 2011 11:58 AM
  • Chris,

     I would expect the component to be deleted, unless other components depend on it then it should be left in the system (managed if other managed solutions use it).

    I do agree with your assement of great principle, but improvements are needed to complete it

     

    Patrick


    Patrick Verbeeten

    W: www.wavextend.com
    W: www.patrickverbeeten.com
    Thursday, July 21, 2011 12:20 PM
  • Point 1: Just for clarification, are you using the same publisher for all of your solutions?  If you are using different publishers you will run into issues similar to this. 

    Point 2: When you import the second version of the solution it won't delete any metadata.  Solutions are additive - any component that has been imported as that solution will remain a part of the solution until the solution is uninstalled, or the component is deleted (special cases, such as delete a cusotmizable web resource).

    Point 3: This is by design.  If this same behavior is performed using the PluginRegistratoin tool it will fail as well.  Similarly to point 2, when the solution update is installed CRM doesn't have the capability to go through and delete the metadata that is not part of the solution.

    The rest of the points I will have to follow up on and try to update this post.

    Thanks for the input!


    Brandon


    Friday, July 22, 2011 11:31 PM
  • All solutions are from the same publisher. The updates are actually the same solution updated and exported from the source system again. The actual error I get when I change the iscustomizable property of a form from yes to no:

     System.Exception: No object matched the query: update [SystemFormBase] set [IsCustomizable]=0 where ([FormIdUnique] in
    ('edbd5af4-2352-4897-bdf7-6813db7652e8')) ---> System.ServiceModel.FaultException`1[Microsoft.Xrm.Sdk.OrganizationServiceFault]: No object matched the query: update [SystemFormBase] set [IsCustomizable]=0 where ([FormIdUnique] in ('edbd5af4-2352-4897-bdf7-6813db7652e8'))

    I have schecked the database and the unique ID is correct, it does exist in the target database but the iscustomizable property is 1.

     

    With regards to deleting plugins, but also attributes and entities this means that the only method to remove them from the system is to the delete the solution they were created by. In your opnion would the following work:

    1. Version 1 of the solution is installed containing 2 plugintypes and 2 entities
    2. Next a version 2 is installed with a new uniquename with only 1 plugintype and 1 entity, but with the plugin type still in the assembly.
    3. Version 1 is deleted from the system
    4. Next a version 3 is installed with a new uniquename with 1 plugin type and the plugin type nolonger exists in the assembly
    5. Version 2 is deleted

    I would expect that at step 3 one entity would be deleted and that after step 5 the plugin type would be completely gone from the system. Can you confirm that this approach would work also for deleting attributes, this way an attribute type change can be done (with data loss). The only problem with this approach is that changing the uniquename is not possible, except for rebuilding it. Second thing this method also requires the user to perform to actions to install a new version, not really a problem but its somthing that can be forgotten and may cause issues down the road.
    Based on this a suggestion: Include the version number in the uniquename, on installation this can be detected, CRM could automatically offer to install the new version and delete the old one.

    Brandon, thank you for the information so far.

    Patrick


    Patrick Verbeeten

    W: www.wavextend.com
    W: www.patrickverbeeten.com
    Saturday, July 23, 2011 7:11 AM
  • Patrick -

    The suggestion that you propose for deleting an attribute/plugintype will work.  Note that it is a little bit easier with regards to plugin types because there are less possible dependencies (sdkmessageprocessingstep being the only one).  For attributes it gets a little bit more tricky because you will need to remove all dependencies to the attribute (form, saved query, etc).  

    Thanks,

    Brandon 

    Monday, July 25, 2011 5:48 PM