Referencing assemblies in GAC

I found out that you can't actually refer to assemblies from the GAC directly. So in development, you need to add reference to the physical assemblies (wherever that assemblies are located), set "Copy Local" to false and at run time, the CLS will load the assembly reference from the GAC.

More information here:

http://www.eggheadcafe.com/PrintSearchContent.asp?LINKID=1175
http://www.codeproject.com/KB/dotnet/demystifygac.aspx

Is that Padding or Margin?

I've always got confused about the difference between Padding and Margin. Yeah sure for a seasoned web developers or UI developers this is easy, but I hardly touch any UI code these days (that may change).

Dan Rigsby has this really good post about the difference between Padding and Margin (in WPF), bookmarked and linked.

Hashtable Serialization

I've experienced the pain of Hashtable serialization/deserialization. It's just doesn't work as you expect it to.

The following two posts are very useful explaining what the issues with Hashtable's serialization mechanism:

http://stackoverflow.com/questions/279524/hashtable-ondeserialization

http://clevercoder.wordpress.com/2006/11/30/hashtable-serialization-and-the-ideserializationcallback-interface/

Manually creating Interop dll using tlbimp.exe

Visual Studio .Net automatically creates Interop dll when you reference the COM dll in your project. This is all nice and behaves as expected, but at times you may want to create the Interop dll manually.

Tlbimp.exe is the tool to use. However, strange as it may seems, by default it doesn't do what Visual Studio does. How interesting ...

Visual Studio .Net by default add "Interop." at the beginning of the generated Interop dll and set the namespace as the name of the dll sans the ".dll".

For example, if the dll is called MyCOM.dll. Visual Studio generates: Interop.MyCOM.dll and creates the Interop dll under MyCOM namespace.

To achieve the same effect using tlbimp, you need to use both the /out and /namespace flag. For example:

tlbimp /out:Interop.MyCOM.dll /namespace:MyCOM MyCOM.dll

Sorted.

LoaderLock was detected

Blimey … what was that? This kind of exception, that only happens during debugging, confuses developers. Googling about the problem shows that Microsoft at times gives pointless answer. Some blame iTunes about this problem ;)

Rather than following the advice to turn this rather useful check in VS 2005, the most probable causes of this problem are:

1) An unmanaged dll calls a managed dll on its DLLMain or
2) Not marshalling your call back to the main UI thread.

Vivek wrote a bit more about this problem here.