locked
CRM 2011: assembly version conflict between mullti-tenanted orgs RRS feed

  • Question

  • I am considering using CRM as the platform for a new xRM solution and would like to know if a behaviour I observed in CRM previously has been changed in the current version 2011.

     

    On a previous CRM 4.0 project we found that logic implemented in plugin assemblies could only really be deployed one version per CRM instance and not different versions per org on the same CRM instance. 

     

    eg If I implemented logic in an assembly named DoProcess.dll, I could not install v1.2 with one org, and v1.3 of the same dll with the same name in a different org on the same instance as only one instance of that DLL would be loaded into memory (by IIS or the CRM workflow engine) at a time.  Or rather, we could register each version to each org, but only the first one loaded would appear to be used by both until it was unloaded.

     

    This meant that all orgs on the same CRM instance using my assembly must be upgraded simultaneously which caused stress to us and the clients we were hosting, and pretty much cancelled out most of the benefits that multi-tenancy had promised with CRM 4.0.  The behaviour seemed inconsistent with my presumption that customisations on each tenant of a multi-tenanted instance should be independent of each other.

     

    2 possible solutions were found.  One was to incorporate some kind of version information in the name of the dll, and this worked fine except every workflow step that accessed the "DoProcess_v12.dll" would effectively have to be recreated to look at "DoProcess_v13.dll" once the new version was installed.  Another solution was limit each CRM instance to hosting one org.  Neither was a desirable solution.

     

    Do any of the changes to CRM2011 ease this stress?  ie If I implement logic in an assembly named DoProcess.dll, can I install v1.2 with one org, and v1.3 of a dll with the same name in a different org on the same instance with no conflicts? 

    Friday, July 8, 2011 4:22 AM

Answers

  • Yes, there is an assembly versioning new feauture with CRM 2011. Each assembly version has 4 numbers: Major.Minor.Build.Revision.

    For one organization:

    You can have multiple assemblies with the same strong name as long as the major or minor is different.

     

    For multiple organizations:

    You can have the same assembly registered in each organization, even if the strong name is exactly the same.

     

    The assemblies are loaded in such a way that they are only cached at the organization level, the cache does not go accross organizations, even if both orgs use the same IIS/Async Server, so you can assume the customizations are independent for each org (beware: only once ALL orgs have been upgraded to CRM2011!)

     

    Now, for solving your workflow problem, there is a new feauture for "assembly update" in which you can update the content of an assembly and then you must update the build/revision number. All workflows will immediately start using the new assembly without having to update the workflow definition.


    Gonzalo | gonzaloruizcrm.blogspot.com

    Friday, July 8, 2011 12:57 PM
    Moderator

All replies

  • Yes, there is an assembly versioning new feauture with CRM 2011. Each assembly version has 4 numbers: Major.Minor.Build.Revision.

    For one organization:

    You can have multiple assemblies with the same strong name as long as the major or minor is different.

     

    For multiple organizations:

    You can have the same assembly registered in each organization, even if the strong name is exactly the same.

     

    The assemblies are loaded in such a way that they are only cached at the organization level, the cache does not go accross organizations, even if both orgs use the same IIS/Async Server, so you can assume the customizations are independent for each org (beware: only once ALL orgs have been upgraded to CRM2011!)

     

    Now, for solving your workflow problem, there is a new feauture for "assembly update" in which you can update the content of an assembly and then you must update the build/revision number. All workflows will immediately start using the new assembly without having to update the workflow definition.


    Gonzalo | gonzaloruizcrm.blogspot.com

    Friday, July 8, 2011 12:57 PM
    Moderator
  • Thanks for a fantastic answer Gonzalo.  It is very much appreciated.

    Paul.

    Sunday, July 10, 2011 10:43 PM