搭建可调试Unity内Packages下的代码工作环境
一、关于Package Manager不久之前，Unity官方推出PackageManager这样的功能，用以集成unity官方出的各种插件，但是这个玩意用起来有很多不舒服的地方，不仅打开之后刷新速度特别慢，而且可能产生刷新不出来想要的插件的情况。一定概率长时间刷不出任何东西（仅能通过断网暂时解决）。最难受的一点就是对于程序员来讲，更改或调试下载下来的插件代码特别麻烦，如果使用寻常打开cs文件的方式，双击之后，在Visual Studio之中不仅无法跳转函数，而且使用类似Debug.Log这样的函数无法给出补全。
这几天想了解一下SRP、LWRP、HDRP的相关源码，所以非常需要一个调试环境，通过打断点调试、修改源码、跨文件跳转定义、Debug.Log这样的方式可以快速了解源码结构。而创建一个新的LWRP工程，然后使用VS很明显是不行的。通过右键打开，可以看到所有的 Packages下的包都是在Library\PackageCache路径下，所以我们在Asset下的VS工程是没办法包含到这里的。
这里我们就要猜测一下PackageManager里的包是如何加载到工程里面的了，根据文档，当打开一个项目，unity内部会通过Packages文件夹下的manifest.json文件为每个包对服务器发起请求，服务器返回请求的信息和数据给unity，然后unity开始在工程中安装这些包。每个项目都有一个独有的manifest 文件，作为项目的依赖项。但是根据实操，这个过程还漏了一步，就是当通过对比发现项目Library\PackageCache下的代码被改动过时，unity会自动使用官方代码覆盖改动过的代码。这可以通过更改Library\PackageCache下的代码，然后重启unity验证。官方将这些代码定义为immutable(read-only)的，原文：Unity treats package Assets just like any other Asset in the Project, except that these Assets are immutable(read-only).
猜测unity下载下来的包会放在下面这个路径下，并用此路径下的代码和工程中Library\PackageCache下的代码做比对。
根据unity文档，其他系统的路径如下，这部分内容被称为Global Cache：
二、更改并调试URP
首先将Library\PackageCache下的URP包复制到另外一个独立的文件夹，此文件夹与项目无关，这样有利于引擎独立开发，并被多项目使用。
然后在Package Manager中Add Package from disk
此时在Unity Editor视图下右键URP的文件，发现已经可以自动跳转到我们自己的文件夹里了。
下载Rider，并将External Tools设置为Rider，相关项记得勾选上，附一个rider下载：
链接：https://pan.baidu.com/s/1GVLm9AmC0nMREpSLqtBEqA
提取码：ztqr
进入Rider之后，在Universal RP/Runtime/UniversalRenderPipeline.cs的Render（）函数中添加代码，并添加断点，点击Run>Debug “Attach to Unity Editor”开启调试，切到Unity之后，Rider立刻进入断点调试。其他功能像是函数跳转、代码补全、structure等等也能正常使用。尝试使用过VS，发现VS除了断点调试这个功能外其他功能都能正常使用。
页:
[1]