少有人走的路 所谓的多环境支持，官方是这么介绍的
1） 支持控制台应用程序。
2） 支持Windows窗体应用程序。
3） 支持WPF应用程序。
4） 支持Windows服务应用程序。
5） 支持ASP.NET应用程序。
6） 支持Windows Mobile应用程序。
7） 支持UIOSP平台嵌套。
这个理解起来不难，主要是因为OSGi.NET是基于.NET框架且与语言以及类型无关，也就是说.NET能支持什么环境，OSGi.NET也就能支持什么环境，他能适应各种.NET生产和装配环境。
最新的版本已经可以支持MVC 3和4了。
我们已经在“模块化和插件化”的小结部分提到了RemotingManagement和WebServiceWrapperService两个插件，他们就可以同时被用在Windows窗体、WPF、Windows服务、ASP.NET和最近的MVC上了。
在前面的几节里，我们从宏观的角度解析了一下OSGi.NET的四大特性，这些特性将成为我们后续的理论和实践基础。从这些特性中，可以大致了解OSGi.NET可以做些什么，但还不足以让你有足够的信息了解如何去做，如何面对不同的问题更恰当的使用这些特性，这是我们这节“高级话题”所要探讨的。
先结合上几节的介绍，简单归纳一下OSGi.NET的设计原则，或者说“最佳实践”
1） 尽量逻辑隔离，物理隔离。逻辑隔离是必须的，低耦合、高内聚，物理隔离是最好的，可替换
2） 尽量以“接口+实现”的方式来处理逻辑依赖，各模块之间的依赖越小越好
3） 尽量把接口和实现的逻辑放在不同的模块中，结合动态性实现可维护、可更新
4） 尽量以“扩展点和扩展”的方式处理模块之间的资源依赖，比如UI上的图标等
5） 尽量将共享的程序集放在一个共享模块中，避免重复依赖和版本混乱，也可减小模块体积
6） 尽量不要在“激活器（Activator）”的start函数中调用服务实现，避免因模块启动顺序导致服务可能为空。其他地方如有需要尽量用UIShell.OSGi.ServiceTracker<T>来处理
7） 尽量对具有逻辑或资源依赖的模块的关键生命周期状态进行相应的处理，比如安装，停止，卸载等，即所谓的“保持系统动态性”
8） 尽量依赖另一模块的共享程序集而非整个模块，可有更快的加载速度
9） 尽量将已有的模块封装打包到一个统一的部署平台，利于共享、测试、发布
