cannot load csla.dll

demon_roby@hotmail.com posted on Friday, May 04, 2007

hi, i'm a new user of csla framework, i find it really interesting.
I make a project to undestand how it works with a dataPortal (remoting on IIS) and a win app, and it seems to work properly, my application can get object and update; authentication is windows, i use the impersonate to pass credential.
now the real problem, my application get a 'Pippo object', populates the properties, save the object (all this work) and then send it to a NTService that host a provider which exposes a queue.
in this enqueuing process this provider needs to call some operation on this 'Pippo', in fact on calling dataPortal methods it FAULTS..
the error is

System.IO.FileLoadException: Impossible to load file or 'Csla' or one of its dependency. Access denied.
File Name: 'Csla'

=== Preassociation infos ===
REG: User = Unknown
REG: DisplayName = Csla
 (Partial)
REG: Appbase = file:///Z:/WinServiceProjects/AMCommunicator/AMCommunicator/bin/Release/
REG: PrivatePath iniziale = NULL
Assembly chiamante: Csla, Version=2.1.4.0, Culture=neutral, PublicKeyToken=93be5fdc093e4c30.
===
... [omissis] ...

REG: tentativo di download del nuovo URL file:///Z:/WinServiceProjects/AMCommunicator/AMCommunicator/bin/Release/Csla.DLL.
ERR: errore irreversibile durante il recupero della base di codice successiva per il download (hr = 0x80070005).

everyone that have an idea of what is wrong?
remoting is still impersonating the win app, perhaps it cannot call the dataportal impersonating me?
thanks for any information.

RockfordLhotka replied on Saturday, May 05, 2007

It looks like your queue software is trying to load Csla.dll from a Z: drive. Is this a network drive? If so, you are probably running into .NET security (CAS), because a network drive defaults to being in the Intranet zone.

Or, perhaps the user account of the Windows service doesn't have access to the folder containing Csla.dll?

Also, if you are dynamically loading assemblies you'll almost certainly run into a bug/feature of .NET where deserialization is unable to find an already loaded assembly in memory. This is NOT the problem you are having now, but one you are likely to have after you solve the current one

If you look at the EnterpriseServices data portal host class in CSLA you'll find code for a "serialization workaround" and this code should solve this second problem.

But your first problem certainly looks like a security problem where your process simply doesn't have security to the file itself, or security to load the file.