礼拜五某位猪仔作福，使得我有一下午空闲作一个小实验，这个实验是基于MS的一个不知名的类库，埋没了很久，没有人用很可惜。实验的内容是通过SXS把这个埋没的小草的闪光点发挥出来。在经过一段时间（准确的说是1，2个小时温习SXS，google了MS社区的几个要踢某位写SXS文章的屁股的MVP洋大人回帖后），渐渐的，渐渐的，萌发了一种冲动，这是一中很强烈的冲动，当然最后还是克制住了，现在很开心的把结果给大家展示一下（不想听我废话可以直接看几行代码）。
很多时候我们会陷入到DLL版本控制的困境中，而一套有层次的.net程序的配置布局是支持重定向你的ASSEMBLY的，但是在典型的WIN32环境，是怎么解决的呢？某人发明了winSXS，某群人实现了winSXS，其他人，比如我，已经学习了怎么使用winSXS，最后厚着脸皮来介绍怎么使用。
浅层次的说，制作一个winSXS是很容易的，比如下面这个示例。但是当环境变得复杂，当DLL变得庞大臃肿，当EXE(COM)的介入，使得winSXS的配置和调试，和测试变得异常的乏味和消磨时间。有人写了一个十分狗屎的工具谣言可以帮助你减轻烦恼，千万不要相信它，老老实实的把那段MSDN的章节看完，像品中药一样的闻一下，然后摒住呼吸，一口气咽下去...这个时候你还不能说可以做到游刃有余，但是起码可以做到兵来将挡，知道怎么去应对。
深层次的说，winSXS就像为WINDOWS的DLLs制作的狗皮膏药那样，廉价，却不失为一种可行的办法，总有需要的人和场合。它有自己的cache，集中管理你的文件的版本，有一个隐晦的规则在众多路径中定位到真正你想要的文件，然后加载。它有一个线程相关的上下文环境来支持动态的调用，比如WINDOWS的标准控件版本就是通过它来呈现出不同版本，风格的外观。
罗嗦了半天，如果你是通过google发现了这段代码，请忽略我上面这么多废话，直接看下面的代码 J
{
[DllImport( " Kernel32.dll " , SetLastError = true )]
private static extern IntPtr CreateActCtxW( ref ACTCTX pActCtx);
[DllImport( " Kernel32.dll " , SetLastError = true )]
private static extern IntPtr CreateActCtxA( ref ACTCTX pActCtx);
[DllImport( " Kernel32.dll " , SetLastError = true )]
[ return : MarshalAs(UnmanagedType.Bool)]
private static extern bool ActivateActCtx(IntPtr hActCtx, out IntPtr lpCookie);
[StructLayout(LayoutKind.Sequential, Pack = 4 , CharSet = CharSet.Unicode)]
private struct ACTCTX
{
public int cbSize;
public uint dwFlags;
public string lpSource;
public ushort wProcessorArchitecture;
public Int16 wLangId;
public string lpAssemblyDirectory;
public string lpResourceName;
public string lpApplicationName;
public IntPtr hModule;
}
static void Main( string [] args)
{
ACTCTX actctx = new ACTCTX();
actctx.cbSize = Marshal.SizeOf(actctx);
actctx.lpSource = " html2xhtml.dll " ;
actctx.dwFlags |= 0x008 ;
actctx.lpResourceName = " #1 " ;
IntPtr lpCookie;
var ptr = CreateActCtxW( ref actctx);
var flag = ActivateActCtx(ptr, out lpCookie);
var utilities = new XHTMLUtilities();
var txt = new WebClient().DownloadString( " http://news.sina.com.cn " );
var result = utilities.convertToXHTML(txt);
}
}