views:

100

answers:

2

Hi All,

We are creating a shared libraries which is basically wrapper over the Microsoft Application Blocks (Caching, Logging etc).

I am trying to make this library available to multiple ASP.Net application.

This library is deployed in a shared foler.

I have created a custom Container which will be used by all ASP.net application to use any service (logging, caching) etc from Library. Location of the Library Folder is used by the container to locate the library dll.

All the configuration for the Application Block is in app.config which is loaded dymanically by the Application blocks.

The problem i am facing is that the Configuration tries to load the Application block assuming that Application Block Dlls will stored in the GAC but For some reason I cannot place the application block assemblies in GAC. I have them in the same folder as Library Dll.

Because of this, the Library Dll is not able to load the Application Block. I think one way of resolving this is to Specify the CodeBase element in the runtime section in Machine.Config. I would like to know if there is any better way where in I can specify the location of the Application blocks dlls in Config file.

Any thoughts?

Regards,

+1  A: 

In .NET you cannot (easily) share libraries between multiple applications unless they are placed in the GAC.

AFAIR, the CodeBase element is only meant to point to a particular COM component, so it exists to support COM interop. That said, you could export your .NET library as a COM component and reference it through COM interop, but I wouldn't recommend it, because there's a performance overhead as well as a maintainance overhead. Remember dll hell? That's where that approach will lead you.

You should put your assemblies in the GAC if you need to share them between multiple applications.

Otherwise, you will need to deploy them with each application.

Those are the only options with .NET.

Mark Seemann
Thanks for the reply. Other way i found was to hook to the AssemblyResolve event of AppDomain.Current class (http://www.devcity.net/Articles/254/1/article.aspx). But this would mean that all the application will have to implement it in the form_load or Page_load which i feel is not a good option.Anyways, thanks a lot for ur time
rauts
+1  A: 

For some reason I cannot place the application block assemblies in GAC

Ent Lib 4.x comes with two versions of the DLLs. One version is strong-named and can be added to the GAC; the other isn't and can't. If you're using version 4.x, make sure you're trying to add the files from C:\Program Files\Microsoft Enterprise Library 4.1 - October 2008\Bin rather than the ones from C:\EntLib41Src\bin and you should be okay. If not, can you let us know what the problem is - the GAC is the way to go, IMO.

serialhobbyist
Thanks for the reply. My whole problem is that i am not using the Application Blocks directly but i am creating a wrapper which would reference the application block. I dont want the application developers using my wrapper to register the Application Blocks in GAC.
rauts
Are you saying you want their applications to use your wrapper which uses EntLib but you don't want them to be able to use EntLib directly? Or you don't want them to have to register anything in the GAC to be able to use your wrapper?
serialhobbyist
I dont want them to register anything in the GAC to be able to use my wrapper.
rauts
Can you get them packaged with SMS/SCCM/whatever and deployed to your web servers by the admins?
serialhobbyist