locked
member variables in plugins? RRS feed

  • Question

  • Hello, I inherited a CRM app that uses a base Plugin class.  I recently implemented some batch update functionality which is returning the following intermittent error:

    VerifyCommitted - Transaction has not been committed

    I did some basic googling and only found 1 or 2 references but the references seemed to indicate that the error above is based on the use of member variables in plugins.  Can you please confirm if the use of member variables in plugins is a no-no?  Are there any types of similar rules I should check for in the CRM code base that I've inherited?

    What's your opinion on the use of base Plugin in general?  From an OO perspective, I think association is generally preferred over inheritence these days. I'd like to know about any experiences you've had using a base plugin.  Is it safe to do in CRM or do you feel that this type of design should simply be avoided from a design perspective?
    Tuesday, April 1, 2014 12:29 AM

Answers

  • I would definitely steer clear of member variables in a plugin, as you have no control over the instantiation of the plugin class.

    Regardng a base class; we've used this model since CRM 4.0 with no problems, and there are no reasons not to use it with CRM


    Microsoft CRM MVP - http://mscrmuk.blogspot.com/ http://www.excitation.co.uk

    Tuesday, April 1, 2014 3:08 PM
    Moderator
  • I think you could use member variables in your MyBusinessLogicManager class safely, as long the MyBusinessLogicManager instance is not itself stored in a member variable of the plugin class.

    I believe AutomaticProperties behave as you suggest; however I suppose it's possible that this could be configured via a compiler directive somewhere.


    Microsoft CRM MVP - http://mscrmuk.blogspot.com/ http://www.excitation.co.uk

    Wednesday, April 2, 2014 3:21 PM
    Moderator

All replies

  • I would definitely steer clear of member variables in a plugin, as you have no control over the instantiation of the plugin class.

    Regardng a base class; we've used this model since CRM 4.0 with no problems, and there are no reasons not to use it with CRM


    Microsoft CRM MVP - http://mscrmuk.blogspot.com/ http://www.excitation.co.uk

    Tuesday, April 1, 2014 3:08 PM
    Moderator
  • Thanks David.  Would that only be an issue when implemented directly in the plugin?  For example, what if I had a PreCaseUpdate plugin which instantiated and delegated some logic to a separate MyBusinessLogicManager class?

    In this scenario, could the MyBusinessLogicManager class safely use member variables or not?  Also, I'm assuming that automatic properties are not treated as member variables since I think this automatic property: 

    private string MyAutomaticProperty
    {
       get
       {
            return "test";
       }}

    would actually get compiled into a method getMyAutomaticProperty in IL?

    Wednesday, April 2, 2014 1:26 AM
  • I think you could use member variables in your MyBusinessLogicManager class safely, as long the MyBusinessLogicManager instance is not itself stored in a member variable of the plugin class.

    I believe AutomaticProperties behave as you suggest; however I suppose it's possible that this could be configured via a compiler directive somewhere.


    Microsoft CRM MVP - http://mscrmuk.blogspot.com/ http://www.excitation.co.uk

    Wednesday, April 2, 2014 3:21 PM
    Moderator