I have a Tridion 2011 Event System project that uses the SignalR DLL from Microsoft. I copied it into the bin folder and restarted the COM+ and Tridion Content Manager Service Host.
But in the Event Log I get the following error message:
Could not load file or assembly 'Microsoft.AspNet.SignalR.Client, Version=1.1.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The system cannot find the file specified.
Do I need to load the DLL into the GAC?
The answer to your question is no, referenced 3rd party assemblies do not need to be registered in the GAC. .NET does look in the GAC first for the assembly, but if it doesn't find it it proceeds to check private paths such as the same folder as the parent assembly and bin folders.
Have a look at the answer provided here: https://stackoverflow.com/questions/49972/in-what-order-are-locations-searched-to-load-referenced-dlls. It explains the order of locations that .NET searches to load referenced assemblies.
I wouldn't think so. When we did the TrackEverything event system we didn't have to put the MongoDB drivers in the GAC (AFAIR), but we did have to have them in the same folder as the event DLL.
The GAC is the best place to put referenced DLLs if those DLLs are used in other implementation areas like TBBs or Workflows. Some good samples are Logging Frameworks DLLs, Email Notification DLLs.
If your DLL is just used for your Event System, then putting this in the same directory as the Event System DLL should be fine.
The GAC is probably the most convenient place. Having said that, as long as you are prepared to ensure that your dll is on the `probing path' of all the executables that might invoke the events system, having it in the GAC should not be completely necessary.
Simply stated. Put it in the GAC. After all, why wouldn't you? The GAC is part of a very carefully designed strategy to manage exactly such issues. Are you coming from an old-skool dll-hell mind-set? Time to get over it. The GAC is goodness epitomised!
