R
Ron Hess
I built the Microsoft (June 2005) Enterprise Library as strong named
assemblies. In a Web application called ConfigTest, I use the Data Access
Application Block. When the application starts and the code that uses the
enterprise library is executed, I get the following error page:
Server Error in '/ConfigTest' Application.
----------------------------------------------------------------------------
----
The located assembly's manifest definition with name
'Microsoft.Practices.EnterpriseLibrary.Data' does not match the assembly
reference.
Description: An unhandled exception occurred during the execution of the
current web request. Please review the stack trace for more information
about the error and where it originated in the code.
Exception Details: System.IO.FileLoadException: The located assembly's
manifest definition with name 'Microsoft.Practices.EnterpriseLibrary.Data'
does not match the assembly reference.
Source Error:
An unhandled exception was generated during the execution of the
current web request. Information regarding the origin and location of the
exception can be identified using the exception stack trace below.
Assembly Load Trace: The following information can be helpful to determine
why the assembly 'Microsoft.Practices.EnterpriseLibrary.Data' could not be
loaded.
=== Pre-bind state information ===
LOG: DisplayName = Microsoft.Practices.EnterpriseLibrary.Data,
Version=1.1.0.0, Culture=neutral, PublicKeyToken=null
(Fully-specified)
LOG: Appbase = file:///c:/inetpub/wwwroot/ConfigTest
LOG: Initial PrivatePath = bin
Calling assembly : (Unknown).
===
LOG: Policy not being applied to reference at this time (private, custom,
partial, or location-based assembly bind).
LOG: Post-policy reference: Microsoft.Practices.EnterpriseLibrary.Data,
Version=1.1.0.0, Culture=neutral, PublicKeyToken=null
LOG: Attempting download of new URL
file:///C:/WINDOWS/Microsoft.NET/Framework/v1.1.4322/Temporary ASP.NET
Files/configtest/2f32983c/f9a353e7/Microsoft.Practices.EnterpriseLibrary.Dat
a.DLL.
LOG: Attempting download of new URL
file:///C:/WINDOWS/Microsoft.NET/Framework/v1.1.4322/Temporary ASP.NET
Files/configtest/2f32983c/f9a353e7/Microsoft.Practices.EnterpriseLibrary.Dat
a/Microsoft.Practices.EnterpriseLibrary.Data.DLL.
LOG: Attempting download of new URL
file:///c:/inetpub/wwwroot/ConfigTest/bin/Microsoft.Practices.EnterpriseLibrary.Data.DLL.
WRN: Comparing the assembly name resulted in the mismatch: PUBLIC KEY TOKEN
Stack Trace:
[FileLoadException: The located assembly's manifest definition with name
'Microsoft.Practices.EnterpriseLibrary.Data' does not match the assembly
reference.]
System.Type.GetType(String typeName, Boolean throwOnError) +0
Microsoft.Practices.EnterpriseLibrary.Configuration.Transformer.XmlSerialize
rTransformer.Deserialize(Object section)
Microsoft.Practices.EnterpriseLibrary.Configuration.ConfigurationBuilder.Rea
dConfiguration(String sectionName)
Microsoft.Practices.EnterpriseLibrary.Configuration.ConfigurationContext.Get
Configuration(String sectionName)
Microsoft.Practices.EnterpriseLibrary.Data.DatabaseConfigurationView.GetData
baseSettings()
Microsoft.Practices.EnterpriseLibrary.Data.DatabaseConfigurationView.GetData
baseProviderData(String instanceName)
Microsoft.Practices.EnterpriseLibrary.Data.DatabaseProviderFactory.GetConfig
urationType(String instanceName)
Microsoft.Practices.EnterpriseLibrary.Configuration.ConfigurationFactory.Cre
ateInstance(String configurationName)
Microsoft.Practices.EnterpriseLibrary.Data.DatabaseProviderFactory.CreateDat
abase(String instanceName)
Microsoft.Practices.EnterpriseLibrary.Data.DatabaseFactory.CreateDatabase(St
ring instanceName)
ConfigTest.WebForm1.Button1_Click(Object sender, EventArgs e)
System.Web.UI.WebControls.Button.OnClick(EventArgs e) +108
System.Web.UI.WebControls.Button.System.Web.UI.IPostBackEventHandler.RaisePo
stBackEvent(String eventArgument) +57
System.Web.UI.Page.RaisePostBackEvent(IPostBackEventHandler
sourceControl, String eventArgument) +18
System.Web.UI.Page.RaisePostBackEvent(NameValueCollection postData) +33
System.Web.UI.Page.ProcessRequestMain() +1292
----------------------------------------------------------------------------
----
Version Information: Microsoft .NET Framework Version:1.1.4322.2032; ASP.NET
Version:1.1.4322.2032
I even changed the version of the common, configuration, and data
(Microsoft.Practices.EnterpriseLibrary) assemblies to 1.2.0.0 before running
this application. The assemblies are stored in the bin folder under the
virtual folder for the web app (not in the GAC, but I even tried that and
got the same results - they can be stored in the GAC so they definitely are
strong named assemblies). The references in VS.NET show these assemblies
(common, configuration, and data) as version 1.2.0.0 and they are copied
local to the web app (copied to its bin folder). I can't figure out why the
Pre-bind state information is referencing Version=1.1.0.0.
Any ideas on how to fix this problem? I was able to use these assemblies as
"weakly named", but they are used in a work project by an assembly that is
strongly named, so I needed to make them that way as well.
Thanks!
assemblies. In a Web application called ConfigTest, I use the Data Access
Application Block. When the application starts and the code that uses the
enterprise library is executed, I get the following error page:
Server Error in '/ConfigTest' Application.
----------------------------------------------------------------------------
----
The located assembly's manifest definition with name
'Microsoft.Practices.EnterpriseLibrary.Data' does not match the assembly
reference.
Description: An unhandled exception occurred during the execution of the
current web request. Please review the stack trace for more information
about the error and where it originated in the code.
Exception Details: System.IO.FileLoadException: The located assembly's
manifest definition with name 'Microsoft.Practices.EnterpriseLibrary.Data'
does not match the assembly reference.
Source Error:
An unhandled exception was generated during the execution of the
current web request. Information regarding the origin and location of the
exception can be identified using the exception stack trace below.
Assembly Load Trace: The following information can be helpful to determine
why the assembly 'Microsoft.Practices.EnterpriseLibrary.Data' could not be
loaded.
=== Pre-bind state information ===
LOG: DisplayName = Microsoft.Practices.EnterpriseLibrary.Data,
Version=1.1.0.0, Culture=neutral, PublicKeyToken=null
(Fully-specified)
LOG: Appbase = file:///c:/inetpub/wwwroot/ConfigTest
LOG: Initial PrivatePath = bin
Calling assembly : (Unknown).
===
LOG: Policy not being applied to reference at this time (private, custom,
partial, or location-based assembly bind).
LOG: Post-policy reference: Microsoft.Practices.EnterpriseLibrary.Data,
Version=1.1.0.0, Culture=neutral, PublicKeyToken=null
LOG: Attempting download of new URL
file:///C:/WINDOWS/Microsoft.NET/Framework/v1.1.4322/Temporary ASP.NET
Files/configtest/2f32983c/f9a353e7/Microsoft.Practices.EnterpriseLibrary.Dat
a.DLL.
LOG: Attempting download of new URL
file:///C:/WINDOWS/Microsoft.NET/Framework/v1.1.4322/Temporary ASP.NET
Files/configtest/2f32983c/f9a353e7/Microsoft.Practices.EnterpriseLibrary.Dat
a/Microsoft.Practices.EnterpriseLibrary.Data.DLL.
LOG: Attempting download of new URL
file:///c:/inetpub/wwwroot/ConfigTest/bin/Microsoft.Practices.EnterpriseLibrary.Data.DLL.
WRN: Comparing the assembly name resulted in the mismatch: PUBLIC KEY TOKEN
Stack Trace:
[FileLoadException: The located assembly's manifest definition with name
'Microsoft.Practices.EnterpriseLibrary.Data' does not match the assembly
reference.]
System.Type.GetType(String typeName, Boolean throwOnError) +0
Microsoft.Practices.EnterpriseLibrary.Configuration.Transformer.XmlSerialize
rTransformer.Deserialize(Object section)
Microsoft.Practices.EnterpriseLibrary.Configuration.ConfigurationBuilder.Rea
dConfiguration(String sectionName)
Microsoft.Practices.EnterpriseLibrary.Configuration.ConfigurationContext.Get
Configuration(String sectionName)
Microsoft.Practices.EnterpriseLibrary.Data.DatabaseConfigurationView.GetData
baseSettings()
Microsoft.Practices.EnterpriseLibrary.Data.DatabaseConfigurationView.GetData
baseProviderData(String instanceName)
Microsoft.Practices.EnterpriseLibrary.Data.DatabaseProviderFactory.GetConfig
urationType(String instanceName)
Microsoft.Practices.EnterpriseLibrary.Configuration.ConfigurationFactory.Cre
ateInstance(String configurationName)
Microsoft.Practices.EnterpriseLibrary.Data.DatabaseProviderFactory.CreateDat
abase(String instanceName)
Microsoft.Practices.EnterpriseLibrary.Data.DatabaseFactory.CreateDatabase(St
ring instanceName)
ConfigTest.WebForm1.Button1_Click(Object sender, EventArgs e)
System.Web.UI.WebControls.Button.OnClick(EventArgs e) +108
System.Web.UI.WebControls.Button.System.Web.UI.IPostBackEventHandler.RaisePo
stBackEvent(String eventArgument) +57
System.Web.UI.Page.RaisePostBackEvent(IPostBackEventHandler
sourceControl, String eventArgument) +18
System.Web.UI.Page.RaisePostBackEvent(NameValueCollection postData) +33
System.Web.UI.Page.ProcessRequestMain() +1292
----------------------------------------------------------------------------
----
Version Information: Microsoft .NET Framework Version:1.1.4322.2032; ASP.NET
Version:1.1.4322.2032
I even changed the version of the common, configuration, and data
(Microsoft.Practices.EnterpriseLibrary) assemblies to 1.2.0.0 before running
this application. The assemblies are stored in the bin folder under the
virtual folder for the web app (not in the GAC, but I even tried that and
got the same results - they can be stored in the GAC so they definitely are
strong named assemblies). The references in VS.NET show these assemblies
(common, configuration, and data) as version 1.2.0.0 and they are copied
local to the web app (copied to its bin folder). I can't figure out why the
Pre-bind state information is referencing Version=1.1.0.0.
Any ideas on how to fix this problem? I was able to use these assemblies as
"weakly named", but they are used in a work project by an assembly that is
strongly named, so I needed to make them that way as well.
Thanks!