项目清单文件

当 Unity 加载项目时，Unity 包管理器会读取项目清单，以便它可以计算要检索和加载的包的列表。当用户通过“包管理器”窗口安装或卸载包时，包管理器会将这些更改存储在项目清单文件中。项目清单文件通过依赖对象管理包列表。

此外，项目清单还充当包管理器的配置文件，包管理器使用清单自定义注册表 URL 并注册自定义注册表。

您可以找到名为manifest.json在Packages文件夹。与包清单文件一样，项目清单文件使用 JSON（JavaScript 对象表示法）语法。

性能

所有属性都是可选的。但是，如果项目清单文件不包含任何值，则不会加载“包管理器”窗口，并且包管理器不会加载任何包。

钥匙	JSON 类型	描述
依赖	对象	项目所需的包集合。这仅包括直接依赖项（间接依赖项列在包清单每个包都有一个清单，该清单向包管理器提供有关包的信息。清单包含包的名称、版本、用户说明、对其他包的依赖关系（如果有）以及其他详细信息等信息。更多信息请参阅术语表).每个条目都将包名称映射到项目所需的最低版本： `{` `"dependencies": {` `"com.my-package": "2.3.1",` `"com.my-other-package": "1.0.1-preview.1",` `etc.` `}` `}` 指定版本号表示您希望包管理器从包注册表（即包的源是注册表）下载包。但是，除了使用版本之外，您还可以指定本地文件夹或 tarball 文件的路径，或 Git URL。注意：您无需在此处指定嵌入式包，因为包管理器会在项目的`Packages`文件夹并自动加载它们。如果包管理器自己的包清单中存在具有相同名称的嵌入式包，则包管理器将忽略任何条目。
启用锁定文件	布尔	启用锁定文件以确保以确定性方式解析依赖关系。这设置为`true`默认情况下。有关详细信息，请参阅使用锁定文件。
resolution策略	字符串	升级间接依赖关系当项目请求一个本身“依赖”另一个包的包时，就会出现间接或传递依赖关系。例如，如果您的项目依赖于`alembic@1.0.7`包，而包又取决于`timeline@1.0.0`package，那么你的项目直接依赖于 Alembic，间接依赖于 Timeline。更多信息请参阅术语表基于语义版本控制规则。这设置为`lowest`默认情况下。有关更多信息，请参阅下面的设置解决策略。
范围注册表	对象数组	除了默认注册表之外，还指定自定义注册表。这允许您托管自己的包。有关更多详细信息，请参阅作用域注册表。
可测试对象	字符串数组	列出要在 Unity 中加载其测试的包的名称测试框架测试框架包（以前称为测试运行程序）是一种 Unity 工具，可在编辑模式和播放模式下测试代码，也可以在目标平台（如独立、Android 或 iOS）上测试代码。更多信息请参阅术语表.有关更多信息，请参阅向包添加测试。注意：您无需在此处指定嵌入式包，因为 Unity 测试框架假定它们默认是可测试的。

例

{
  "scopedRegistries": [{
    "name": "My internal registry",
    "url": "https://my.internal.registry.com",
    "scopes": [
      "com.company"
    ]
  }],
  "dependencies": {
    "com.unity.package-1": "1.0.0",
    "com.unity.package-2": "2.0.0",
    "com.company.my-package": "3.0.0",
    "com.unity.my-local-package": "file:<path>/my_package_folder",
    "com.unity.my-local-tarball": "file:<path>/my_package_tarball.tgz",
    "com.unity.my-git-package": "https://my.repository/my-package.git#v1.2.3"
  },
  "enableLockFile": true,
  "resolutionStrategy": "highestMinor",
  "testables": [ "com.unity.package-1", "com.unity.package-2" ]
}

设置解决策略

虽然可以通过将间接依赖项显式添加到项目清单来强制 Unity 的包依赖项解析使用更高版本的间接依赖项，但这不是一个好的策略，原因有两个：

它使项目所有者承担了更多维护依赖项版本的责任。
随着时间的推移，你可能会有项目不需要的依赖项。

更好的方法是通过设置 resolutionStrategy 属性来自定义包管理器如何根据语义版本控制规则选择间接依赖项：

价值：	描述：
最低	不要升级间接依赖项。相反，它完全使用请求的版本。这是默认模式。
最高补丁	升级到具有相同主要和次要组件的最高版本。例如，对于请求的版本 1.2.3，此策略选择范围内的最高版本`[1.2.3, 1.3.0)`（即，`>= 1.2.3`和`< 1.3.0`).
highestMinor （最高次要）	升级到具有相同主要组件的最高版本。例如，对于请求的版本 1.2.3，此策略选择范围内的最高版本`[1.2.3, 2.0.0)`（即，`>= 1.2.3`和`< 2.0.0`). 注：版本`1.0.0`标志着第一个稳定的、生产就绪的版本。在此之下，版本`0.X.Y`表示其 API 尚不稳定，并且连续的次要版本可能会引入重大更改。SemVer 规范的这一部分允许在不妨碍快速开发的情况下发布包的早期版本。因此，当目标版本是`0.X.Y`，highestMinor 的行为类似于 highestPatch，以确保选择向后兼容的版本。例如，使用请求的版本`0.1.3`，则此策略选择范围内的最高版本`[0.1.3,0.2.0)`.
最高	升级到最高版本。例如，对于请求的版本 1.2.3，此策略选择范围内的最高版本`[1.2.3,)`（即，`>= 1.2.3`没有上限）

注意：这些范围绝不允许依赖项从稳定版本跳转到实验性或预发布包。

其他资源

包清单文件

使用项目清单文件进行包管理

包装检验

手册

项目清单文件

性能

例

设置解决策略

其他资源