少有人走的路 通过上面的实例，我们可以具体体会到模块与模块之间的“动态信息注入”方式。这种方式的好处是
1） 首先，被注入方不需要知道将会被谁注入，保证了逻辑的单一性，易于横向扩展
2） 其次，注入的协议的可配置型，基于XML的描述，可实现很方便的修改和维护
3） 结合“接口加实现”的服务模式，可以快速整合各个模块的资源，实现了有效的“服务化”
上面的代码只是实现了注入，也就是当具体业务模块被运行环境加载后的被相应的处理模块识别并解析，但OSGi.NET也同时支持某个业务模块的动态抽离，在这里就是从处理模块中移除已注入信息。接下来我们来解决上一节没处理完的“异常”。
默认的，运行时环境会将所有扩展信息收集起来，并通过扩展点名来加以区分。但是你依然可以通过ExtensionChanged事件来加上自己的业务逻辑，比如我们这里需要的模块扩展移除时如何将他的注入信息也一同移除。直接看完整的代码
这段代码主要完成了当具体业务模块从运行时环境中添加或移除时，如何处理相应的扩展信息，RemoveAudioFormatExtension代码如下
添加的逻辑没有什么变化，依然使用CollectAudioFormatExtension。
为了让我们可以看到添加、移除时的变化，对主程序也少做修改，如下
按F5运行起来，基本界面没什么太大变化。接着我们打开桌面的“远程管理工具”，并按照提示输入字母l
假如我们选择对OSGi.NET.APEDecoderPlugin执行停止（stop）操作，就继续输入sp 5（5为它的Id值）
提示已经成功停止，我们再次回到主程序界面，点击回车，将得到如下结果
我们可以清楚的看到，支持的类型中已经没有了APE这一项。也就是说OSGi.NET.APEDecoderPlugin被停止后，他的扩展信息也被从AudioFormatExtensionService移除了。再来看看添加是什么情况，在“远程管理工具”中输入s 5，如下
启动成功，回到主程序再次回车，可看到如下结果
APE选项又回来了。
