什么是WinSxS?[ZT]
(转载:http://www.boxcounter.org/?action=show&id=91)
如何安装VC库？
一个看似简单，其实一点都不简单的问题。我一直以为放在应用程序的目录下是最好的，可以避免Dll Hell，其实不然！
这篇文章“Why does VC8 install libraries to WinSxS?”做了非常好的解释！原来微软也走过了很多的弯路。(boxcounter: 这篇文章讲了一些历史，强烈推荐阅读)
VC6里，为了更新的方便，建议放在System32下。
VC7里，考虑到Dll Hell，建议放到应用程序的目录下。
VC8里，建议放到系统目录WinSxS下以保证更新方便，并使用Manifest支持不同版本Dll的共存。
总 结一下就是，VC6和VC7库都最好安装到System32目录下。在2K系统里，VC8也安装到System32目录下。在XP以后的系统里，则安装到 WinSxS目录下。安装VC8库的时候，建议使用MergeModule来安装，以正确的安装到WinSxS目录下。否则如果放在本地目录的话，记得把 manifes文件也拷贝过来。
VC8库的安装可不那么简单，有很多技巧，有人还为此写了工具。
Bootstrapper for the VC++ 2005 Redists
不过又说SP1之后，问题没有那么复杂了，但是还是要了解得更多才好。
Visual C++ Application: How to use manifests and re-distributable assemblies?
Side by Side Assembly看起来是好东西，但是问题也不少，除了问题很难调试。
Diagnosing SideBySide failures
这一切都是我始料未及的，本来我只是想知道Windows目录下的WinSxS到底是什么回事的，搞到现在我还是没有找到WinSxS的微软官方文档。倒是意外的发现了一个微软的工具IExpress，可以用来制作自解压程序，找类似的免费工具很久了。
终于找到了微软的官方文档“Isolated Applications and Side-by-side Assemblies”，原来是推出XP时就有了的技术。以前只是大概听说，从来没有细琢磨过，原来这么有学问。
这篇“How To Build and Service Isolated Applications and Side-by-Side Assemblies for Windows XP”文章讲得比较详细，看完基本就了解整个的实现原理和开发步骤了。文章说，.NET Framework也是使用了同样的技术（Simplifying Deployment and Solving DLL Hell with the .NET Framework），只是更简单了。原来如此，我还以为assembly等概念是.NET发明的呢，不过是由它发明光大而已！
总结一下：
使用assembly的好处
1. 一个组件的不同版本可以side by side加载在同一个进程里（当然组件要能处理这种并存的情况）。
2. 不需要注册表就可以使用COM组件。
如何制作一个assembly？
编写一个manifest文件，就可以了，这是最简单的private assembly。如果要share，还需要进行数字签名，以及安装到WinSxS目录下，有点麻烦。
为什么要是使用private assembly？
因为是跟应用程序放在一起，side by side好像意义不大。不过可以为了将来转成share assembly做准备。还有，就是可以使用无需注册表的COM组件。
如何开发一个side by side的assembly？
开发可以在同一个进程里加载一个dll/assembly的不同版本并不容易，你要考虑很多情况。比如避免在不同版本的assembly之间交换数据，因为结构可能不一致。比如，避免使用共享内存以及全局信号量等等。
为什么WinSxS目录会变得越来越大？
看到网上有人说自己的WinSxS目录已经达到十几个G了，真是太夸张了。而有人说，自己的只有十几M。这到底什么回事？
这 是因为assembly发布之后就不会更改，如果有Bug修改就发布新的版本，并与就旧版本同时并存。这样就可以保持兼容性，而且安装更新也可以不用重启 计算机，总之是很方便了。但是，随着时间的增加，系统和应用程序会不断的进行升级，assembly的版本就会越来越多，占用的硬盘空间自然就会越来越 大。
如何更新Assembly？
SidebySide是通过强制指定assembly的版本号来达到版本 兼容的，但是那样的话assembly如何更新？如果assembly改变了版本号，那么依赖它的应用程序就不能自动享有更新了。而如果不改变版本号，那 么Dll Hell的版本不兼容问题就有冒出来了。
微软使用了PublisherConfiguration来解决这个问题，你可以强制 要求所有（或者指定）的旧版本自动转到新版本来。这时候，随这新版本assembly发布，同时发布一个PublisherConfiguration来 强制版本号跳转（Redirect）。这样，已发布的应用程序不需要重新打包和部署，就可以使用新版本的assembly了。当然，新版本的 assembly需要保证向后兼容。PublisherConfiguration是全局的跳转，也可以为不同的应用程序做不同的跳转，即 ApplicationConfiguration。两种Configuration都是在不改变现有应用程序的情况下，改变其Assembly之间的绑 定关系，适合于Policy式的集中管理。Application Configuration可以覆盖PublisherConfiuration的设定，强制对特定Assembly版本的依赖以保证兼容性--这使得它 可能错过Assembly的重要更新。
既要保持不同Assembly之间的隔离，又想要自动更新，这其实是一个两难问题，根本没有完美解，Publisher Configuration和Application Configuration只是给出了一个平衡的解决方案。
小结
在一个复杂的不断演进的系统里，组件版本的管理是个大问题。如何在不改变现有应用的情况下逐渐演进，更是一大挑战。
如何安装VC库？
一个看似简单，其实一点都不简单的问题。我一直以为放在应用程序的目录下是最好的，可以避免Dll Hell，其实不然！
这篇文章“Why does VC8 install libraries to WinSxS?”做了非常好的解释！原来微软也走过了很多的弯路。(boxcounter: 这篇文章讲了一些历史，强烈推荐阅读)
VC6里，为了更新的方便，建议放在System32下。
VC7里，考虑到Dll Hell，建议放到应用程序的目录下。
VC8里，建议放到系统目录WinSxS下以保证更新方便，并使用Manifest支持不同版本Dll的共存。
总 结一下就是，VC6和VC7库都最好安装到System32目录下。在2K系统里，VC8也安装到System32目录下。在XP以后的系统里，则安装到 WinSxS目录下。安装VC8库的时候，建议使用MergeModule来安装，以正确的安装到WinSxS目录下。否则如果放在本地目录的话，记得把 manifes文件也拷贝过来。
VC8库的安装可不那么简单，有很多技巧，有人还为此写了工具。
Bootstrapper for the VC++ 2005 Redists
不过又说SP1之后，问题没有那么复杂了，但是还是要了解得更多才好。
Visual C++ Application: How to use manifests and re-distributable assemblies?
Side by Side Assembly看起来是好东西，但是问题也不少，除了问题很难调试。
Diagnosing SideBySide failures
这一切都是我始料未及的，本来我只是想知道Windows目录下的WinSxS到底是什么回事的，搞到现在我还是没有找到WinSxS的微软官方文档。倒是意外的发现了一个微软的工具IExpress，可以用来制作自解压程序，找类似的免费工具很久了。
终于找到了微软的官方文档“Isolated Applications and Side-by-side Assemblies”，原来是推出XP时就有了的技术。以前只是大概听说，从来没有细琢磨过，原来这么有学问。
这篇“How To Build and Service Isolated Applications and Side-by-Side Assemblies for Windows XP”文章讲得比较详细，看完基本就了解整个的实现原理和开发步骤了。文章说，.NET Framework也是使用了同样的技术（Simplifying Deployment and Solving DLL Hell with the .NET Framework），只是更简单了。原来如此，我还以为assembly等概念是.NET发明的呢，不过是由它发明光大而已！
总结一下：
使用assembly的好处
1. 一个组件的不同版本可以side by side加载在同一个进程里（当然组件要能处理这种并存的情况）。
2. 不需要注册表就可以使用COM组件。
如何制作一个assembly？
编写一个manifest文件，就可以了，这是最简单的private assembly。如果要share，还需要进行数字签名，以及安装到WinSxS目录下，有点麻烦。
为什么要是使用private assembly？
因为是跟应用程序放在一起，side by side好像意义不大。不过可以为了将来转成share assembly做准备。还有，就是可以使用无需注册表的COM组件。
如何开发一个side by side的assembly？
开发可以在同一个进程里加载一个dll/assembly的不同版本并不容易，你要考虑很多情况。比如避免在不同版本的assembly之间交换数据，因为结构可能不一致。比如，避免使用共享内存以及全局信号量等等。
为什么WinSxS目录会变得越来越大？
看到网上有人说自己的WinSxS目录已经达到十几个G了，真是太夸张了。而有人说，自己的只有十几M。这到底什么回事？
这 是因为assembly发布之后就不会更改，如果有Bug修改就发布新的版本，并与就旧版本同时并存。这样就可以保持兼容性，而且安装更新也可以不用重启 计算机，总之是很方便了。但是，随着时间的增加，系统和应用程序会不断的进行升级，assembly的版本就会越来越多，占用的硬盘空间自然就会越来越 大。
如何更新Assembly？
SidebySide是通过强制指定assembly的版本号来达到版本 兼容的，但是那样的话assembly如何更新？如果assembly改变了版本号，那么依赖它的应用程序就不能自动享有更新了。而如果不改变版本号，那 么Dll Hell的版本不兼容问题就有冒出来了。
微软使用了PublisherConfiguration来解决这个问题，你可以强制 要求所有（或者指定）的旧版本自动转到新版本来。这时候，随这新版本assembly发布，同时发布一个PublisherConfiguration来 强制版本号跳转（Redirect）。这样，已发布的应用程序不需要重新打包和部署，就可以使用新版本的assembly了。当然，新版本的 assembly需要保证向后兼容。PublisherConfiguration是全局的跳转，也可以为不同的应用程序做不同的跳转，即 ApplicationConfiguration。两种Configuration都是在不改变现有应用程序的情况下，改变其Assembly之间的绑 定关系，适合于Policy式的集中管理。Application Configuration可以覆盖PublisherConfiuration的设定，强制对特定Assembly版本的依赖以保证兼容性--这使得它 可能错过Assembly的重要更新。
既要保持不同Assembly之间的隔离，又想要自动更新，这其实是一个两难问题，根本没有完美解，Publisher Configuration和Application Configuration只是给出了一个平衡的解决方案。
小结
在一个复杂的不断演进的系统里，组件版本的管理是个大问题。如何在不改变现有应用的情况下逐渐演进，更是一大挑战。
