views:

90

answers:

1

I have a rather simple internal ASP.Net Website that has issues loading the Microsoft.Practices.EnterpriseLibrary.Data dll about once a week. Here is the Exception message:

System.IO.FileLoadException: Could not load file or assembly 'Microsoft.Practices.EnterpriseLibrary.Data, Version=2.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. Access is denied.
File name: 'Microsoft.Practices.EnterpriseLibrary.Data, Version=2.0.0.0, Culture=neutral, PublicKeyToken=null'
   at foobar.Intranet.Logic.Data.UserDB.SelectByUserName(String userName)
   at foobar.Intranet.Logic.Info.User.ValidateUser(String userName) in F:\Development\foobar\foobar\foobar.Intranet.Logic\Info\User.cs:line 130
   at Login.ValidateUser(String username, String password) in e:\foobar\foobar.Intranet\Login.aspx.cs:line 32

=== Pre-bind state information ===
LOG: User = Unknown
LOG: DisplayName = Microsoft.Practices.EnterpriseLibrary.Data, Version=2.0.0.0, Culture=neutral, PublicKeyToken=null
 (Fully-specified)
LOG: Appbase = file:///E:/foobar/foobar.Intranet/
LOG: Initial PrivatePath = E:\foobar\foobar.Intranet\bin Calling assembly : foobar.Intranet.Logic, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null.
===
LOG: This bind starts in default load context.
LOG: Using application configuration file: E:\foobar\foobar.Intranet\web.config
LOG: Using host configuration file: \\?\C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet.config
LOG: Using machine configuration file from C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\config\machine.config.
LOG: Policy not being applied to reference at this time (private, custom, partial, or location-based assembly bind).
LOG: Attempting download of new URL file:///C:/WINDOWS/Microsoft.NET/Framework/v2.0.50727/Temporary ASP.NET Files/foobar.intranet/668896d8/82d7e51c/Microsoft.Practices.EnterpriseLibrary.Data.DLL.
LOG: Attempting download of new URL file:///C:/WINDOWS/Microsoft.NET/Framework/v2.0.50727/Temporary ASP.NET Files/foobar.intranet/668896d8/82d7e51c/Microsoft.Practices.EnterpriseLibrary.Data/Microsoft.Practices.EnterpriseLibrary.Data.DLL.
LOG: Attempting download of new URL file:///E:/foobar/foobar.Intranet/bin/Microsoft.Practices.EnterpriseLibrary.Data.DLL.
ERR: Failed to complete setup of assembly (hr = 0x80070005). Probing terminated.

Things of note:

  • A simple IIS Reset fixes the issue.
  • We had the same code running on a single webserver with no problems. We then moved the site to two new, load balanced (using sticky sessions) webservers (all three Windows Server 2003 R2 Standard Edition SP1). Now each of the load balanced webservers throw this exception about once a week just out of the blue.
    • The only major difference I can think of, is I've installed the 4.0 .NET framework on the load balanced servers. The website is still running under ASP.NET 2.0 so I don't see how this would be an issue
  • I've configured the indexing service to not search the "Temporary ASP.NET Files" folder, but it didn't help.
  • We use the Microsoft.Practices.EnterpriseLibrary.Data dll everywhere on our site. Almost every single page uses our logic dll which in turn utilizes the EnterpriseLibrary dlls.
  • While the errors where happening once, I even looked to see what processes were locking the dll in the "Temporary ASP.NET Files" folder, and it wasn't any different than the locks on the server that was working fine.
  • Once the error starts, it errors every single time until an iisreset is performed

Any insight anyone could offer would be much appreciated. Let me know if I missed something.

Thanks!

A: 

Take a look at the Assembly Binding Log Viewer. It might point you in the right direction.

I had a quick look at other SO answers and one person suggested that the application may have been developed against a signed version of the DLL but the production runtime only has access to an unsigned version. It looks like your production is loading an unsigned assembly (PublicKeyToken=null).

David Neale
I opened the Assembly Binding Log Viewer, but nothing showed up. I updated the location of the log to a custom location so that it won't clear it out. I'm guessing it's going to give me the same information as the exception message after "=== Pre-bind state information ===". I wonder if the "Policy not being applied to reference at this time" has something to do with it?Both the production and development are using an unsigned. And the issues the users were describing, were happening every time, not once a week.
Daryl