Friday, January 19, 2007 3:02 PM
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
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:
And here is what the Program.cs file looks like:
static void Main(string args)
DataAccess dataAccess = new DataAccess(false);
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=220.127.116.11 , 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:
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.
Friday, January 19, 2007 3:47 PM
Check the "CopyLocal" property for the reference.
May be it is set to "false"?
Saturday, January 20, 2007 10:58 AM
I said in my previous post already that I checke dthe CopyLocal. And it is definately set to true.
Monday, January 22, 2007 9:56 AMHi
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 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?
Monday, January 22, 2007 10:07 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 11:45 AMThank you I'll try a re-install of VS2005 and see how that goes.
Thursday, January 25, 2007 2:32 PM
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!
I'm from china.
Thursday, January 25, 2007 2:39 PM
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.
Saturday, July 18, 2009 6:53 AMhi denhan,
how to strongly name Microsoft.Practices.ObjectBuilder.dll?