Do we need to GAC the adapter assembly?

We have created a projected based on WCF LOB Adapter SDK. So just want to understand, do we really need to GAC the adapter project assembly? Also, if the adapter is using third party assemblies, is it really required to GAC them as well? For example, if we using Log4Net (for logging errors & information), do we have to GAC Log4Net.dll as well? Can we avoid GACing the adapter DLL for a BizTalk application?

So do we need to GAC the adapter assembly? There are some posts out there that debate about usefulness of installing the assembly in GAC. However, I am not going diverge. The adapter assembly is a WCF binding and in order to register it with WCF configuration, we need to link the binding in <system.ServiceModel><extensions><bindingExtensions> configuration sections with corresponding assembly information, as shown below. WCF can then load this DLL from the GAC, instead of probing various other .NET paths. If the assembly is changed, it needs to be updated in one place.




<add name="echoAdapter" type="Microsoft.Samples.Echo.EchoAdapterBindingElementExtension,EchoAdapter, Version=, Culture=neutral, PublicKeyToken=blah" />



<add name="echoAdapterBinding" type="Microsoft.Samples.Echo.EchoAdapterBindingCollectionElement,EchoAdapter, Version=, Culture=neutral, PublicKeyToken=blah" />




In order to install an assembly to Global Assembly Cache (GAC), the assembly must be assigned a strong-name key. All assemblies referenced by a strong-named assembly must also be strong-named. If you reference an assembly written by a third party that is not strong-name signed, you cannot strong-name sign your assembly. So what to do in this case? If the referenced assembly belongs to a third-party, and you can’t convince the third-party to strong name it, you can either register the assembly for verification skipping or force sign the assembly.

To register the assembly for verification skipping

SN.exe –Vr thirdparty.dll

To force sign the third-party assembly, first disassemble and then reassemble the assembly with a strong name. Your original assembly will be overwritten, so if you want to keep the original version, ensure you make a backup copy of it before proceeding with the following steps.

Use Microsoft intermediate language (MSIL) Disassembler to disassemble the assembly:
ILDASM.exe thirdparty.dll /

Then, use MSIL Assembler to reassemble the assembly with a strong name:
ILASM.exe /dll /key=strongkeyfile.snk

Reader comments, suggestions and other tips and tricks are welcome regarding this post.