Clean your bin

    The startup configuration of DD4T is the real challenge. Luckily there are available templates that are ready to use, like this.

If you are going to start your own project from scratch, one of the steps to run DD4T locally is to copy your Content Delivery dll-s in your bin folder. But to copy something in the bin folder where your program will generate things is a real pain. Prepare yourself to face different strange situations like rebuilding and everything stops working. If you are not very familiar with the process of loading dlls from the CLR you can go crazy. I’ve always taken for granted that at any time I can delete my bin and my obj folders, and they will be generated automatically for me. No worries. I’ve references in my project everything is fine. But since I’ve started working with Tridion and started copy-pasting dll-s and jar files into my bin folder it was not any more this clean space that I don’t touch and has only generated content.

In some moment everything is working than some of the dll-s just disappear, or are strangely replaced with different version. I decided to get more familiar with the way that assembly files work and from where and when something is called from my bin folder.

Call the assemblies

So basically the standard steps that CLR will perform to find an assembly are:

  1. Looks in if the assembly has been loaded already. /for strongly named assemblies/
  2. Looks in the GAC (Global Assembly Cache). /for strongly named assemblies/
  3. Looks in the APPBASE folder (in the common case your bin folder).
  4. Looks in a subdirectory in APPBASE folder named after the assembly being loaded.
  5. Looks in additional subdirectories specified in applicationName.exe.config file.
  6. Looks in the private paths specified in the config file.

*Strongly named assembly – has PublicKeyToken != null.

The one I used was the private paths. The division of the dll-s is very easy. Just add in the web.cofig -> configuration -> runtime -> assemblyBinding

				
   <probing privatePath="folderName"/>
				

With this syntax CLR will look in folder with that name on the same level as your bin folder. You can specify subfolder of bin simply by using

				
   <probing privatePath="bin\folderName"/>
				

Then just move your dll-s there.

    This simple step will save you a lot of problems with disappearing dll-s in the bin. Whatever is needed will be automatically copied to your bin, like it should be.

Author: Elena Kirilova