There is an interesting article in the latest MSDN magazine about Reg-free COM and .NET components: http://msdn.microsoft.com/msdnmag/issues/05/04/RegFreeCOM/default.aspx
The technology was present for quite a while, but still not very well known. Part of the reason is that the technical details (at least on the COM side) are buried deep in the MSDN technical reference on SxS here: http://msdn.microsoft.com/library/en-us/sbscs/setup/creating_registration-free_com_objects.asp
Side-by-side (SxS) assemblies had an interesting history. Years ago, when people were still counting their disk free space KB or MB, there was a natural need for shared libraries. You didn’t want to replicate the same MSVCRT.DLL for every single installed application. So people ended up in… DLL hell. That is what you get when an application can replace the existing MSVCRT.DLL with an older (or newer) version, causing AVs all over the place.
But in the meantime the disk space was not an issue anymore. So the tendency, at least for a while, was to have a separate copy of DLL per application. Now, (almost) each application has its own copy of MSVCRT.DLL. In fact, the version 8 of the runtime (msvcr80.dll) is not even in the latest versions of Windows. The same strategy is usewd also by most Java runtimes. It is recommended that each Java application or service has its own copy of the runtime.
But in the last years, security became a very big issue for practically everyone. So, what you would do when you want to patch a runtime that is spread all over the place? The cheesy solution would be a quick file “search&replace”, but will it work? You don’t know. But anyway, the fact that you do not have a centralized location certainly helps. And this is where SxS comes into play. In some scenarios, it is actually easier to “patch” the shared version than to go to every single directory for a manual patch. This was the case with the infamous MS04-028 where all applications using the (SxS-based) gdiplus.dll were immediately “fixed” by Windows Update, but applications that had a local copy of the same DLL had to be upgraded manually.
So, what is the final solution? Ultimately, I guess that the best answer depends on your specific scenario. XCOPY deployment might end up creating lots of copies of the same DLL, which are harder to upgrade in case of a security patch. SxS (or GAC for .NET components) might be also a very good solution but doesn’t offer an easy deployment experience.