Why should I reference the ExceptionHandling.Logging DLL in client code?

I have a data access level that is compiled in a dll. Inside this layer, I use Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.Logging.dll to register exceptions, and then throw them back to the caller.

I have a client application that references a data access dll, but does not directly call it in Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.Logging.dll. I get the following runtime exception in my client code when a data access level exception occurs if I do not add a link to the Enterprise Library DLL from my client application.

Type 'Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.Logging.LoggingExceptionHandler, Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.Logging, Version = 5.0.414.0, Culture = neutral, PublicKeyToken = 31bf3856ad364e35' cannot be resolved or specify the correct name. Check the correct name. type.

I don’t understand why the client needs to refer to the Enterprise Library DLL, even if he does not refer to it in the code.

Any thoughts would be appreciated.

+4
source share
2 answers

All of this is a matter of localizing the CLR and binding to your assemblies at runtime.

Since your client directly calls your DAL.dll, it needs a link to the DAL.dll file at compile time. Similarly, since your DAL.dll directly calls EL.Logging.dll, it needs a link to the EL.Logging.dll file at compile time.

However, since the Client is not directly dependent on EL.Logging.dll, it does not require a compilation link. However, during the execution of the CLR, you will have to search and link all 3 assemblies: Client, DAL.dll and EL.Logging.dll.

You do not need to add a link to the compilation, but at the same time, if the Copy local checkbox is set to true, you deploy the EL.Logging.dll file in the Client folder. Now at runtime, all DLL files are local.

Other ways to achieve the same effect are:

  • Register your corporate library with the GAC
  • Create an action to create messages
  • Manually deploy the XCopy required DLL files.
  • Specify <codebase> in the configuration to find assemblies
  • Use <probing> in the configuration to search for subdirectories (maybe it doesn't suit you)
+7
source

There is no need to reference the Enterprise Library DLL from your client application.
The problem is that the file is neither in the GAC nor in the bin folder. It is copied when adding a link to it from your launch project (client application), because the Copy Local property is set to True (by default).

Only DLLs that directly reference your startup project are copied to the \ bin folder.

Dlls that link to links are NOT copied.

Another way, if you do not want to refer directly to the dll file, is to create a post-build script.

0
source

Source: https://habr.com/ru/post/1342866/


All Articles