【转】全面解析Unity3D自动生成的脚本工程文件

http://blog.csdn.net/jjiss318/article/details/7632041

我们在Unity3D开发的时候,经常会看到它会产生不少固定命名工程文件,诸如:

Assembly-CSharp-vs.csproj

Assembly-CSharp-firstpass-vs.csproj

Assembly-CSharp-Editor-vs.csproj

Assembly-CSharp-Editor-firstpass-vs.csproj

看得不少人云里雾里的。那么,这些工程是如何产生的呢?各自的作用是什么?下面就来逐一解析。

一. 首先从脚本语言类型来看,Unity3D支持3种脚本语言,都会被编译成CLI的DLL

如果应用中含有C#脚本,那么Unity3D会产生以Assembly-CSharp为前缀的工程,名字中包含"vs的"是产生给Visual Studio使用的,不包含"vs"的是产生给MonoDevelop用的。


应用中包含的脚本语言


工程前缀


工程后缀


C#


Assembly-CSharp


csproj


JavaScript


Assembly-UnityScript


unityproj


Boo


Assembly-Boo


booproj

如果工程中这3中脚本都存在,那么Unity3D将会生成3种前缀类型的工程。

二. 对于每一种脚本语言,根据脚本放置的位置(其实也部分根据了脚本的作用,比如编辑器扩展脚本,就必须放在Editor文件夹下),Unity3D会生成4种后缀的工程。其中的firstPass就表示先编译,Editor表示放在Editor文件夹下的脚本。

下面以C#脚本为例。如果工程中只有C#脚本,不考虑为VS和MonoDevelop各自生成工程的差异性,我们可以得到4个工程文件:

Assembly-CSharp-firstpass-vs.csproj

Assembly-CSharp-Editor-firstpass-vs.csproj

Assembly-CSharp-vs.csproj

Assembly-CSharp-Editor-vs.csproj

(1) 所有在Standard Assets,Pro Standard Assets或者 Plugins文件夹中的脚本会产生一个Assembly-CSharp-firstpass-vs.csproj文件,并且先编译;

(2) 所有在Standard Assets/Editor, Pro Standard Assets/Editor 或这Plugins/Editor文件夹中的脚本产生Assembly-CSharp-Editor-firstpass-vs.csproj工程,接着编译;

(3) 所有在Assets/Editor外面的, 并且不在(1),(2)中的脚本文件(一般这些脚本就是我们自己写的非编辑器扩展的脚本)会产生Assembly-CSharp-vs.csproj工程,被编译;

(4) 所以在Assets/Editor中的脚本产生一个Assembly-CSharp-Editor-vs.csproj工程,被编译。

之所有这样建立工程并按此顺序编译,也是因为DLL间存在的依赖关系所决定的。

好了,至此也说得比较清楚了,也不会因为见到那么多的工程文件而疑惑了。

最后问诸位一个小问题:

一个Unity3D的工程,最多可以产生多少个工程文件?

4*3*2 = 24个

Why is the unity folder so cluttered with IDE files

Whenever I create a new Unity project, add a C# script file and synchronize it with an external source code editor, there appears a number of .sln and .csproj files generated in the main project folder.

I wouldn‘t bother it wasn‘t for the fact that there‘s 6 x .csproj and 2 x .sln with names like:

  • Assembly-CSharp.csproj
  • Assembly-CSharp-Editor.csproj
  • Assembly-CSharp-Editor-vs.csproj
  • Assembly-CSharp-firstpass.csproj
  • Assembly-CSharp-firstpass-vs.csproj
  • Assembly-CSharp-vs.csproj

After a solution is opened automatically by Unity, it has 3 projects with pretty similar structure - every project has an Assets folder, but seems to include a different permutation of assets.

Whether I use VS or MonoDevelop doesn‘t matter. The question is:

Is this a standard project structure or did I get something wrong? Is it possible to reduce the clutter, which makes me unsure which project I should be working on, or are all these files necessary?

The reason I‘m asking is there seems to be a lot of redundancy and it‘s not very clear what each of these projects is responsible for.

评论

1条回复

  • 排序:

3

最佳解答

个解答,截止stevethorne · 2014年05月02日 13:26

This is the standard solution structure for a Unity project. Each one can have a number of projects in the solution. Mine usually have 6 projects in the solution. You didn‘t do anything wrong, and there‘s nothing you can do to reduce this. These are needed for both unity and the IDE that you‘re using.

If you‘re wondering why they do this, it‘s due to the fact that they need to make sure that things get compiled in the correct order. You can take a look at this page for more details on the compile order. That might also help you understand what‘s put in each project.

For those not wanting to go searching for what‘s in each project, here‘s a basic synopsis:

Assembly-CSharp-firstpass.csproj

  • contains the files in the StandardAssets folder.

Assembly-CSharp.csproj

  • contains the files outside of the Editor folder.

Assembly-CSharp-Editor.csproj

  • contains the files inside of the Editor folder.

The projects that replace "CSharp" with "UnityScript" contain the Unity Script files in the same manner.

As for the ones ending in -vs, I‘d imagine those are for the visual studio projects.

时间: 2024-10-13 01:39:30

【转】全面解析Unity3D自动生成的脚本工程文件的相关文章

自动生成项目的Makefile文件

自动生成项目的Makefile文件 理论基础 跟我一起写 Makefile:   http://bbs.chinaunix.net/forum.php?mod=viewthread&tid=408225 例解 autoconf 和 automake 生成 Makefile 文件:   http://www.ibm.com/developerworks/cn/linux/l-makefile/index.html 步骤 写好Makefile.am 运行 autoscan , 自动创建两个文件: a

sublime打开文件时自动生成并打开.dump文件

GBK Encoding Support 没有安装前打开ASNI格式编码文件会乱码,安装成功重启则可以打开正常 关于.dump文件生成的解释: 当打开一个非utf-8格式且包含汉字的文件时,sublime text 2会自动生成一个dump文件,文件修改过程中,不会修改原文件,只有按"保存"了才会将dump的数据更新到原文件里,关闭当前编辑的dump文件则会自动删除dump文件. 但是有时候 GBK Encoding Support 插件也会出些bug,就想这样,生成.dump文件后自

织梦栏目在动态或者伪静态下仍然自动生成空的栏目文件夹

1.打开 /include/arc.listview.class.php 搜索 CreateDir(MfTypedir($this->Fields['typedir'])); 有3处地方都要改成 if($this->TypeLink->TypeInfos['isdefault']!=-1) { CreateDir(MfTypedir($this->Fields['typedir'])); } 2.打开 /dede/catalog_add.php 搜索 if($ispart != 2

自动生成Mybatis的Mapper文件

自动生成Mybatis的Mapper文件 工作中使用mybatis时我们需要根据数据表字段创建pojo类.mapper文件以及dao类,并且需要配置它们之间的依赖关系,这样的工作很琐碎和重复,mybatis官方也发现了这个问题,因此给我们提供了mybatis generator工具来帮我们自动创建pojo类.mapper文件以及dao类并且会帮我们配置好它们的依赖关系. 实际上,最非常流行MyBatis-Plus中内置了代码生成器:采用代码或者 Maven 插件可快速生成 Mapper . Mo

【转发】自动生成Sqlalchemy的models文件

原文来源:https://blog.csdn.net/caoxing81/article/details/46639023 自动生成Sqlalchemy的models文件的包早用过了,今天维护一个较老的工程,有个字段类型做了改动,调了得10几分钟才搞定.记录下自动生成models文件的python包sqlacodegen    sqlacodegen已经加入pypi,只需要使用pip install sqlacodegen就可以安装了安装后即可运行命令生成models.py文件了    假设数据

自动生成LR脚本且运行

背景:作为一个测试,特别是性能测试,尤其在活动的测试,时间紧,有很多要测的,我们的LR11因为浏览器兼容问题全录制不了脚本了,用浏览器加代理或手机加代理录制,我感觉好麻烦 ,所以就想如果能用脚本把所有的测试请求,全部自动生成脚本拿来直接用,岂不是爽歪歪. 最近我老大,非要我用python.他有个特点,每当我们用哪个东西刚刚上手的时候,他就要求我们再扩展. 所以我们这里的人的特质就是:懂的很多,但是都不精通. 我的urls.txt 我的脚本就是逐行读取URL,然后把action_name\web_

通过mybatis工具generatorConfig.xml自动生成实体,DAO,映射文件

简介 Mybatis属于半自动ORM,可以利用mybatis工具generatorConfig.xml自动生成DAO.实体.映射文件的方式来代替手动书写的方式,这样既提高了工作效率也可以在项目避免出现的一些细微难调试的BUG. 前提条件: 1.需要准备的第三方jar包为: mybatis-generator-core-1.3.2.jar和mysql-connector-java-5.1.39-bin.jar, 其中mybatis-generator-core-1.3.2.jar的下载地址为: h

自动生成hibernate的hbm文件

本文有待商榷 当我们在新增插件的时候发现会出现duplicate location,意思是所选的anchive所包含的zip路径已经复用,现象如下: 如上图所示黄色标记部分“Duplicate location”,这时,我们需要对先前添加的archive进行删除,过程如下: 1.进入window —— Preference ,选择Available Software Sites,弹出已经添加过的软件安装路径 2.选中已经添加过的路径,点击“Remove”,即可 是不是很神奇,这样,就不会出现无法

MyBatis在不适用MyBatis-generator代码自动生成时的map文件的书写规范(总结)

首先我们参考一段通过MyBatis-generator的自动生成的代码 <?xml version="1.0" encoding="UTF-8" ?> <!DOCTYPE mapper PUBLIC "-//mybatis.org//DTD Mapper 3.0//EN" "http://mybatis.org/dtd/mybatis-3-mapper.dtd" > <mapper namespa