当然如果不想搞压缩包，也还可以直接把模块文件夹复制到用户项目的BEMod文件夹下，这是得益于白易在引入模块化的VS配置后顺带把BEmod也加入到了全局包含目录中：
每当一个系统模块被引入到白易插件管理下的当前项目中时，该模块在白易插件运行时内会被标记为引用+1，而其他模块都可以声明要依赖于哪个系统模块（即就是当时模块工程的开发环境内手动打勾所需依赖的系统模块库），当其他模块中含有该系统模块时也被引入后，若主程项目本身也有依赖该系统模块，则该系统模块引用计数可以来到2、由此类推...
只有当一个系统模块的引用计数为1（即除了自身以外不再有任何的其他模块的被引用），才允许用户把该系统模块的勾给取消，否则一律弹出提示并告知收集到的哪些模块当前正被引用中（可能是用户模块也可能是其他系统模块），当引用计数为0时即会解除当前系统模块。
如果说用户模块是完全自闭式的代码内联它解决的是版本依赖的隔离问题，那么系统模块更多在于对版本的管理上；
也就是在全局统一只需引入一次同名模块的对应的一种版本，若真起冲突的时由一个全局管理层对依赖版本提供预警机制！
在模块入口头文件的文档注释规范.mht中@version文档注释会真正起到版本管理检测的作用，这个是真实作用于全局系统模块上的（而用户模块那边对于此标记并没有实质性的处理）。
PS：系统模块库在开发阶段它与用户版模块的开发没有本质区别它们都是模块工程项目，这意味着在开发之前该系统模块库内部也能再单独依赖引入其他用户模块来作为内联式的模块（由于白易的符号改编式规则此时已经起到了版本隔离的功效），最后再安装后做成系统模块库（这样算是真静态版模块）！
实际上，用户模块的本质就是做版本隔离实现任意工程的私有化方案而并不限于说再做成系统模块的工程本身，所以这里顺带只是提个醒确实可以这样做，在开发系统模块的工程中直接双击用户模块表就可以引入了。
直接对系统模块所在的目录（即：白易安装目录/BEModG/模块名）压缩成zip（.bec）就可以制作成用户模块了。
当然如果不想搞压缩包，也还可以直接把模块文件夹复制到用户项目的BEMod文件夹下，这是得益于白易在引入模块化的VS配置后顺带把BEmod也加入到了全局包含目录中：
而且它的优先级会比$(BEModG)还要提前，也就是即便同样使用了<>进行引入系统模块，如果在用户的BEMod中能够找到的话则优先使用用户版的模块
不过白易目前暂时没有一键将系统模块完全导出到用户项目内联式的模块做法，如果一个系统模块又还依赖其他系统模块的话，这个工作暂时只能一个个引入（预计到白易1.0正式版时会做的）。
编译并安装基础模块0
然后在模块1中引入此依赖
接着安装这个模块1到系统模块
在主程里打勾模块1的同时会一并打勾模块0
而现在若想把模块0取消的话，会弹出提示
把模块1取消后模块0会跟着一起取消（这是因为模块0的引用计数会随模块1解除后跟着自减1，于是到0时就一并解除了）
假若用户一开始自己主动先勾了模块0，然后再接着勾模块1：
， 
现在把模块1解除，而模块0还在的
还原一下模块0.ref=2，模块1.ref=1的场景
注意：版本依赖检查，检查的是依赖的系统模块与自身模块它所声明的版本号与系统当前所拥有的实际模块版本进行的匹配。
接着生成一下当前项目的版本依赖报告：
PS：这里可以继续展开查看子依赖
首先版本号的声明来源于模块入口头文件的文档注释规范.mht中的@version注释字段
比较逻辑如下：
结果状态判定：
匹配：声明版本 == 实际版本。
可更新：声明版本 < 实际版本（提示有新版可用）。
版本异常：声明版本 > 实际版本（通常意味着所依赖环境中的系统模块版本过低）。
未找到（也属于版本异常）：无法提取到版本号或找不到对应物理文件（内部对于此版本号会直接判定为-1，最终会纳入版本异常的状态）
尽管不会阻止引入(打勾)，但会立即弹出该异常检测报告，且编译时自然会提示相应模块依赖哪些模块的入口头文件未找到！
总结（为了确保白易模块版本检测正常工作）：建议版本号格式遵循：主版本.次版本（例如 1.0, 1.10, 2.4）。超出两位的版本号（如 1.2.3）虽然有效，但第三位及之后的部分将不参与检测（适合用于发布不影响版本号兼容性的补丁次级迭代）