none
Microsoft.Practices.ObjectBuilder.dll not being copied to a Project through a reference

    Question

  • Hi

    Here is my situation:

    Firstly I have a class library called Data, I'm using Enterprise Libraries Data block so I have the following references in the Data Project

    • Microsoft.Practices.EnterpriseLibrary.Common.dll
    • Microsoft.Practices.EnterpriseLibrary.Data.dll
    • Microsoft.Practices.ObjectBuilder.dll
    • System
    • System.Data
    • System.Xml
    Inside the Data project is a class called DataAccess. This is what DataAccess looks like:

    using System;
    using Microsoft.Practices.EnterpriseLibrary.Data;
    namespace Data
    {
      
    public class DataAccess
      
    {
         
    public DataAccess(bool useTransactions)
          {
            
    Database database = DatabaseFactory.CreateDatabase();
          }
       }
    }

    Lastly I have another Console application project called Tester, which has a reference to the Data class library. Here are all the references for the Tester project:

    • Data
    • System
    • System.Data
    • System.Xml

    And here is what the Program.cs file looks like:

    using System;
    using Data;

    namespace Tester
    {
      
    class Program
      
    {
         
    static void Main(string[] args)
          {
            
    DataAccess dataAccess = new DataAccess(false);
            
    Console.Write("Perfect!");
            
    Console.ReadLine();
          }
       }
    }

    Pretty straight forward. When I run the Tester console application I get the following Error:

    System.TypeInitializationException: The type initializer for 'Microsoft.Practice s.EnterpriseLibrary.Common.Configuration.ObjectBuilder.EnterpriseLibraryFactory' threw an exception. ---> System.IO.FileNotFoundException: Could not load file o r assembly 'Microsoft.Practices.ObjectBuilder, Version=1.0.51205.0, Culture=neut ral, PublicKeyToken=443a159333f77b8c' or one of its dependencies. The system can not find the file specified. File name: 'Microsoft.Practices.ObjectBuilder, Version=1.0.51205.0, Culture=neut ral, PublicKeyToken=443a159333f77b8c' at Microsoft.Practices.EnterpriseLibrary.Common.Configuration.ObjectBuilder.E nterpriseLibraryFactory..cctor() === Pre-bind state information === LOG: User = OSIRISDMN\dmccall LOG: DisplayName = Microsoft.Practices.ObjectBuilder, Version=1.0.51205.0, Cultu re=neutral, PublicKeyToken=443a159333f77b8c (Fully-specified) LOG: Appbase = file:///C:/Testing/Tester/bin/Debug/ LOG: Initial PrivatePath = NULL Calling assembly : Microsoft.Practices.EnterpriseLibrary.Common, Version=2.0.0.0 , Culture=neutral, PublicKeyToken=443a159333f77b8c. === LOG: This bind starts in default load context. LOG: No application configuration file found. LOG: Using machine configuration file from C:\WINDOWS\Microsoft.NET\Framework\v2 .0.50727\config\machine.config. LOG: Post-policy reference: Microsoft.Practices.ObjectBuilder, Version=1.0.51205 .0, Culture=neutral, PublicKeyToken=443a159333f77b8c LOG: Attempting download of new URL file:///C:/Testing/Tester/bin/Debug/Microsof t.Practices.ObjectBuilder.DLL. LOG: Attempting download of new URL file:///C:/Testing/Tester/bin/Debug/Microsof t.Practices.ObjectBuilder/Microsoft.Practices.ObjectBuilder.DLL. LOG: Attempting download of new URL file:///C:/Testing/Tester/bin/Debug/Microsof t.Practices.ObjectBuilder.EXE. LOG: Attempting download of new URL file:///C:/Testing/Tester/bin/Debug/Microsof t.Practices.ObjectBuilder/Microsoft.Practices.ObjectBuilder.EXE. --- End of inner exception stack trace --- at Microsoft.Practices.EnterpriseLibrary.Common.Configuration.ObjectBuilder.E nterpriseLibraryFactory.BuildUp[T](IConfigurationSource configurationSource) at Microsoft.Practices.EnterpriseLibrary.Common.Configuration.ObjectBuilder.N ameTypeFactoryBase`1.CreateDefault() in C:\Program Files\Microsoft Enterprise Li brary January 2006\Src\Common\Configuration\ObjectBuilder\NameTypeFactoryBase.cs :line 52 at Microsoft.Practices.EnterpriseLibrary.Data.DatabaseFactory.CreateDatabase( ) in C:\Program Files\Microsoft Enterprise Library January 2006\Src\Data\Databas eFactory.cs:line 45 at Data.DataAccess..ctor(Boolean useTransactions) in C:\Testing\Data\DataAcce ss.cs:line 10 at Tester.Program.Main(String[] args) in C:\Testing\Tester\Program.cs:line 12

    If I have a look in the debug folder for the Tester project the following files are present:

    • Tester.exe
    • Tester.vshost.exe
    • Data.dll
    • Microsoft.Practices.EnterpriseLibrary.Common.dll
    • Microsoft.Practices.EnterpriseLibrary.Data.dll
    • Data.pdb
    • Microsoft.Practices.EnterpriseLibrary.Common.pdb
    • Microsoft.Practices.EnterpriseLibrary.Data.pdb
    • Tester.pdb
    • Microsoft.Practices.EnterpriseLibrary.Common.xml
    • Microsoft.Practices.EnterpriseLibrary.Data.xml

    As you can see the Microsoft.Practices.ObjectBuilder.dll is missing. The dll in the Data project does say copy local true. I can't seem to figure out why the dll is not being copied to the Tester debug directory. Any assistence would be appreciated.

    Thanks
    Denham

    Friday, January 19, 2007 3:02 PM

Answers

  • That's very strange.

    We use a lot of external libraries and we use EntLib too. All the libraries are copied correctly.

    We have a several number of different solutions but I haven't seen this behavior even when VS2005 SP1 has not ben installed.

    May be it is a local bug on your PC...

    BTW, do you have SP1 installed? A lot of bugs have been fixed in it so I recommend :)

    Monday, January 22, 2007 10:07 AM

All replies

  • Check the "CopyLocal" property for the reference.

    May be it is set to "false"?

    Friday, January 19, 2007 3:47 PM
  • Hi

    I said in my previous post already that I checke dthe CopyLocal. And it is definately set to true.

    Thanks!

    Saturday, January 20, 2007 10:58 AM
  • Hi

    We seem to have found a problem with VS2005 when copying references. Here is what we did to reproduce the problem, without using EntLib.

    We created 3 projects
    • First
    • Second
    • Console

    First references Second
    Console references First

    We build the console project and the First.dll and Second.dll are copied into the debug directory. (That is correct)

    Now we remove the Second project from the solution, and Make the First project reference the Second.dll directly (not the project)
    Now we build the console and only the First.dll is copied to the output directory. (This is wrong)

    So it seems even though First references Second's dll directly the console app referencing only the First project does not copy all First's project dependencies across. Is this a bug or the default behavior?

    Thanks
    Denham
    Monday, January 22, 2007 9:56 AM
  • That's very strange.

    We use a lot of external libraries and we use EntLib too. All the libraries are copied correctly.

    We have a several number of different solutions but I haven't seen this behavior even when VS2005 SP1 has not ben installed.

    May be it is a local bug on your PC...

    BTW, do you have SP1 installed? A lot of bugs have been fixed in it so I recommend :)

    Monday, January 22, 2007 10:07 AM
  • Thank you I'll try a re-install of VS2005 and see how that goes.
    Monday, January 22, 2007 11:45 AM
  •  

    I meet the same problem. I don't know how to sovle the problem. 

     

    When I meet the problem,I copy the  Microsoft.Practices.ObjectBuilder.dll  to the bin ,then the problem seems

    to be solved,but i will meet the problem again a few hours later.

    Have you sovled the problem 

    I need your help!

    My Email:zb19830924@163.com

    I'm from china.

    Thank You!

     

     

     

    Thursday, January 25, 2007 2:32 PM
  • Hi

    The problem we experienced was that Microsoft.Practices.ObjectBuilder.dll being referenced was not strongly named. As soon as we strongly named our Microsoft.Practices.ObjectBuilder.dll, it all worked correctly.

    Therefore the Data project was strongly named and all it's references except for Microsoft.Practices.ObjectBuilder.dll. That is why Microsoft.Practices.ObjectBuilder.dll was not being copied. As soon as we also strongly named the Microsoft.Practices.ObjectBuilder.dll and referenced it, it solved the problem.

    Hope this helps.

    Thursday, January 25, 2007 2:39 PM
  • hi denhan,

    how to strongly name Microsoft.Practices.ObjectBuilder.dll?
    Saturday, July 18, 2009 6:53 AM