vs编译idl文件_Unity中 .asmdef文件的作用

项目中引用了一个插件源码，修改插件源码的时候遇到一个问题，就是一个脚本文件调用另外一个脚本文件的函数的时候一直提示缺失命名空间的引用，找不到此对象。但是我明明已经把它的命名空间加上了，还是提示错误，后面才发现原来这两个脚本属于两个程序集定义，当前调用的脚本程序集没有包含另外一个，导致引用失败。

网上找了一篇博客对 .asmdef文件进行了详细的介绍，这里贴出原文链接：

[洪流学堂]Unity2017.3新功能：程序集定义(Assembly Definition File)功能详解​blog.csdn.net

Unity2017.3已经发布，其中一大新功能是：程序集定义文件（Assembly Definition File），下面文中我们就简称ADF

得益于此功能，开发者可以在一个文件夹中自定义程序集。定义明晰的依赖关系，可以确保脚本更改后，只会重新生成必需的程序集，减少编译时间。

项目越大脚本越多，编译时间必然会越长。在进行项目迭代时，这很容易制约效率，因此设置好程序集定义文件可以提高工作效率，减少脚本编译的时间。

如上图，如果你仅更改了Main.dll中的脚本，其它程序集都不需要重新编译。由于Main.dll包含的脚本更少，因此它的编译速度比Assembly-CSharp.dll更快。 同样，Stuff.dll的更改仅会导致Main.dll和Stuff.dll重新编译。

创建方法

ADF是资源文件，可以通过Assets > Create > Assembly Definition菜单创建。该文件的扩展名是.asmdef。

注意：ADF所在的文件夹名称，以及ADF的文件名，跟程序集的名称没有关系。程序集的名称只跟ADF文件中的Name属性有关。创建时对ADF命名的话，属性中的Name也会相应修改。

实战环节

下面我们使用一个实际案例看看这个功能如何使用
例如在2017.3之前的版本中的的脚本目录结构是这样的

在2017.3之前的版本中，这些脚本最后会全部被编译到一个Assembly-CSharp.dll中

再来看下如果我们创建了程序集定义文件(Assembly Definition File)后会怎样

创建ADF文件

我们按照目录结构分别创建一个ADF，并且在Scripts文件夹下创建一个Main的ADF

我们随便打开一个脚本，可以看到VS将这几个分别识别为了几个C#工程

刚刚创建的ADF还差一些没有设置，就是依赖关系，比如Network要依赖SDK中的内容，如果不设置，就会像下图一样报错

同时VS中也会报错

下面我们来修复这个问题，选中Network ADF文件，然后在References中添加SDK的引用，别忘了点击下面的Apply

现在不报错了，再打开VS，也不报错了，可以看到Network这个C#工程中加了一条SDK的引用

常见问题：多层级的ADF

如果一个文件夹及子文件夹中，有多个ADF，每个脚本被添加到离这个脚本最短路径的ADF中去。
比如上面实战环节的Utils中并没有创建ADF，那么ADF就会被添加到父目录的Main中

如果你搞不清楚一个脚本究竟被包含在了哪个ADF中，只需要选中这个脚本，在Inspector面板中就会清楚的看到

最佳实践

强烈建议你对项目中的所有脚本使用ADF，或完全不使用。否则，没有使用ADF的脚本会在每次ADF重新编译时也被重新编译。这会减少你在项目中ADF所带来的好处。

还有就是一定要对目录结构好好进行划分

感觉这个功能设计是好的，但是实际项目中由于脚本文件的划分，和自己定义公共插件库的划分不是非常明确，导致脚本直接会经常出现引用，如果引用过多，就导致ADF失去了他的优势，反而感觉比较麻烦，容易出现问题。个人感觉如果项目编译真的很慢，而且项目脚本功能有明确的划分，实在ADF还是不错的选择。