如何在.NET解决方案中创建可访问同方案其他项目的Azure Function

选解决方案内新建独立AZFunctions文件夹存Function项目，另外两个方案直接排除，原因很明确：

• 直接在现有API项目里加Function代码完全走不通：Azure Function用的是Microsoft.NET.Sdk.Functions专属SDK，和你现有API用的Microsoft.NET.Sdk.Web宿主模型、启动逻辑、部署方式完全不兼容，硬混在同一个项目里会导致依赖冲突、启动报错，后续根本没法维护。
• 解决方案外单独建项目是自找麻烦：Function需要直接引用Core、Infrastructure两个类库，放解决方案外会导致项目引用路径跨层级，本地调试、CI/CD配置都要额外做路径适配，后续改实体、重构代码的时候很容易漏同步引用，平白增加出错概率。
• 解决方案内新建独立项目是唯一合理的选择：可以直接添加对Core、Infrastructure的项目引用，和现有API共享底层类库代码，调试时可以同时启动API、Function、前端多个进程，代码重构、版本迭代都在同一个解决方案上下文里，逻辑完全不割裂。

只要按规范操作，不会出现已部署Function运行故障，注意三个核心规则：

• 迁移文件统一托管在Infrastructure项目，绝对不要让Function项目生成、执行EF迁移：所有实体修改、迁移生成、数据库更新操作全部走Infrastructure项目执行，Function项目只通过引用Infrastructure类库调用DbContext做数据操作，不持有任何迁移逻辑。
• 严格遵守部署顺序：所有涉及新数据库结构的代码版本（不管是API还是Function），必须等数据库迁移执行完成、表结构完全更新到位后再部署，从流程上避免出现代码查询不存在的表/字段的问题。
• 跨版本兼容优先做非破坏性迁移：删字段前先把所有应用（API、Function）里对该字段的依赖全部移除、部署完成后再删数据库字段；加字段设置默认值或允许为空，不要在迁移里做会导致旧版EF Core映射报错的变更——这是所有多应用共享DbContext场景的通用规范，不是Azure Function特有的问题。

不用强行合并两个配置文件，按本地、线上环境分别处理即可：

• 本地开发阶段：两个项目的自有配置分别存在各自的配置文件里，local.settings.json只存Function本地运行专属配置（比如Stripe webhook签名密钥、AzureWebJobsStorage本地连接串），API的appsettings.json存API专属配置。两边重复的公共配置（比如数据库连接串、第三方服务通用密钥）可以在解决方案根目录建一个sharedSettings.local.json，两个项目都在启动时通过配置管道加载这个共享文件，记得把这个文件和local.settings.json一起加入.gitignore，不要提交到代码仓库。
• 线上部署阶段：根本不需要依赖项目里的配置文件，Azure Function的所有配置直接在Azure门户的「应用程序设置」里配置，和API的线上配置完全隔离，敏感配置统一存在Azure Key Vault按需引用即可，不会出现配置冲突或泄露问题。
• 别为了省事儿把API的appsettings.json做硬链接给Function用，后续两个应用部署到不同环境、需要不同配置值的时候，改起来会非常麻烦，独立配置+本地共享公共项是维护成本最低的方案。

内容的提问来源于stack exchange，提问作者chuckd