CRM Callouts & Microsoft Enterprise Library Application Blocks RRS feed

  • Question

  • We are writing a callout for a project and we would like to use the Microsoft Enterprise Library (MEL) for configuration, logging, and data access.  It is our enterprise standard to utilize those blocks for those activities on all of our efforts.  The problem is that I don't see a readily available app.config or web.config file for which I can add the configuration context necessary to utilize those features.


    I also am very averse to modifying any core Microsoft Dynamics CRM 3.0 app.config or web.config file because it has the potential of being wiped out during any future upgrades.  So far we have envisioned two options but would like some community feedback to help us define a best practice.


    Option 1: Use the MEL ConfigurationManager to load context from a file and execute against that context

    • PRO: It seems as if it may get us closer
    • CON: Externally loaded context does not become the "current context".  Existing in-house libraries hard-wired to execute against the "current context" may not be utilized.

    Option 2: Add the configuration context to the machine.config

    • PRO: We may utlize all existing in-house libraries
    • CON: We have a standard to not use the machine.config for anything to avoid potential maintenance headaches.

    We are leaning towards [Option 2] and changing our standard to allow authorized modifications to the machine.config only.  This is because we enjoy leveraging the current context in our core libraries to avoid having to pass context and configuration information through every layer of our code.

    Thursday, June 21, 2007 9:25 PM


  • Well, we had some further discussion with some of our internal technical
    experts and our architect and we decided on an alternative.

    We have libraries that wrap MEL blocks as well as provide other functions.
    We are going to add a singleton to our core libraries with a property that
    lazy loads the configuration context from GetCurrentContext. A developer
    would also have the option of manually setting the configuration context from
    an external file. We will then rewrite all of our libraries to execute
    against a specific context, the property on the singleton, instead of calling
    GetCurrentContext. This should persist singatures and behavior for existing
    applications while providing a much less intrusive solution for callouts.

    Our external configuration files will be in the same folder as the callout
    DLL and we will reflect against the executing assembly to get its location.
    Friday, June 22, 2007 5:42 PM