why does an assembly in the BIN folder get referenced at runtime from another assembly even though it was not included in project (but remained in build folder)

• Question

• 

  

  0

  Sign in to vote

  Hi there,

  I solved this already after a day, but a) thought it might help others and b) wanted to (try to) understand WHY this happened and how I could have discovered it sooner.

  I think this is fairly agnostic but just in case - CRM 2011 (7.0) and .NET 4.5.2 and Enterprise Library 5

  So the deal was:

  two projects, both referencing a common library that talked to CRM via the Generated (SDK) Microsoft.Xrm.Sdk.Client.CrmOrganizationServiceContext

  this instance of this context is created in the CONTSTRUCTOR of the class library.

  Anyway we USED EntLib 5.0 a while ago in this project but recently updated it to 6.0.

  So we start getting this bizzare error from the constructor failing turning up in only ONE of our projects.

  TypeInitializationException - The type initializer for 'Microsoft.Xrm.Client.Services.OrganizationServiceCache' threw an exception.
  

  
  

  so we tried pretty much everything

  fusion logs were all clean
  project references were all good
  because Unity was building everything it was failing in the buildup
  one project you could step into everything the other you could not

  Finally what caused us to go looking further afield was this info from Unity error in building things

  At the time of the exception, the container was:
  
  
    Resolving CRMService,(none)
    Calling constructor CRMService(ILog logger, SmtpClient mail)
   -- Could not load type 'Microsoft.Practices.EnterpriseLibrary.Common.Configuration.Manageability.ConfigurationElementManageabilityProviderAttribute' from assembly 'Microsoft.Practices.EnterpriseLibrary.Common, Version=6.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'.

  Anyway it turns out that in the local and source controlled directories there was an orphaned EntLib 5.0 file ( Microsoft.Practices.EnterpriseLibrary.Caching.Database.dll) that wasn't correctly deleted/removed from things in this project, and so was still being dropped everywhere, and so obviously was being used as the "local" (preferred, in the order of build/bindings) of the compiler, and for some reason (perhaps xrm.client uses entlib internally?) was interfering with the way things were working.

  So we found the offending file, removed it from the source control folder and everyone is happy again!

  So does anyone have any insights into how we could have discovered this without spending as much time as we did - process? tools? etc...

  Thanks in advance.

   

  ---

  - sure I'm noJedi but that's no reason to stop trying to make stuff levitate! -

  • Moved by DotNet Wang Tuesday, May 10, 2016 9:57 AM

  Monday, May 9, 2016 3:04 PM