winapi - Shell Extensions: Static-Linking vs. Dynamic-Linking of C/C++ Run-Time DLLs -

when building windows explorer shell extensions (currently using vs2010 sp1), suggest static-linking (to crt, c++ run-time , other support libraries atl) or dynamic-linking?

one of benefits of static-linking option make deployment easier (in fact, in way, it's possible deploy shell extension in-proc com server dll, without external dependencies on other c/c++ run-time dlls).

in case of dynamic-linking, if msvcr100.dll, msvcp100.dll, etc. dlls in windows\system32 used shell extension, thing if microsoft fixes (e.g. security fixes) in dlls, the fixes automatically used custom shell extension.
however, bad thing "global" fixes may introduce bugs , break things in dependant code.

as app-local deployment of vcredist dlls, i'm not sure how might work in case of shell extension. kind of manifest should embedded in shell extension com dll refer vcredist dlls under shell extension's folder?

having use dll version of crt pretty hard requirement when have multiple modules interact each other. 1 particularly important aspect using same allocator in modules. object allocated in 1 module can safely destroyed code in module. comes in c++ frequently, doing simple returning std::string function troublesome. gets created in callee , needs destroyed in caller. disaster strikes if function call made across module boundaries , 2 modules use different heaps.

the layout of standard c++ objects tied crt implementation well. different versions of compilers use different std::string implementations. disaster strikes if 1 module uses different implementation other, caller cannot correctly use object created callee. simple debug settings can cause mismatch, iterator debugging support in microsoft crt particularly notorious causing mismatch, makes stl object bigger.

these problems avoided in com. there's strong memory management protocol, based on iunknown interface's addref , release methods. keeps creator of object owner of object , responsible destroying it. other allocations, bstr , safearray, must made heap that's guaranteed shared within process. cotaskmemalloc, cotaskmemfree , imalloc implement plumbing.

and avoids object layout problem, com strictly works interfaces only. doing passing c++ objects or exceptions across interop boundary strictly forbidden. implementation details calling convention, strictly __stdcall, , interface v-table layout, strictly tied iid of interface. changing interface requires picking new iid.

long story short, therefore have no need @ use shared version of crt. , in fact many com servers compiled /mt. using /md fine well, you'd consider if com server implemented using multiple modules.