为啥我的 Service Fabric 代码会锁定自己的 PDB？

Posted 2023-03-27

【中文标题】为啥我的 Service Fabric 代码会锁定自己的 PDB？

【英文标题】：Why does my Service Fabric code lock its own PDBs?为什么我的 Service Fabric 代码会锁定自己的 PDB？

【发布时间】：2017-06-04 09:54:39

【问题描述】：

我正在开发一个 Service Fabric 应用程序，该应用程序包含许多无状态服务和一个有状态服务。当我第一次发布时，一切都很好，它已部署到我的本地集群。在此之后，如果我尝试打包或发布应用程序而不先明确停止它，我会收到以下错误：

CSC : error CS2012: Cannot open 'C:...\ProjectFolder\obj\x64\Debug\ProjectName.pdb' for writing -- '进程无法访问文件'C:...\ProjectFolder\obj \x64\Debug\ProjectName.pdb'，因为它正被另一个进程使用。'

根据process explorer，PDB被我自己的ProjectName.exe锁定。这是我的应用程序中的单一有状态服务。

为什么我的 exe 会锁定自己的 PDB？ 如果是 Visual Studio 做的，我可以理解。 我在我自己的代码中看不到任何应该导致这种情况的东西，所以我假设这是我正在调用的 Fabric 代码中的某些东西。 PDB 与应用程序一起部署，但锁定的是原始源目录中的文件 - 为什么不是与运行代码相邻的 PDB？ 为什么我只看到与有状态服务有关的错误，而没有看到与无状态服务有关的错误？ 我怀疑这与有状态服务在启动时产生大量错误有关，Fabric 可能需要符号才能正确显示。 我如何才能阻止它发生 - 要么使用正确的 PDB，要么根本不使用它们，除非我通过 Visual Studio 进行调试？

编辑：在github 提出。当前workaround为此：

目前的解决方法是限制网络服务访问构建文件夹 (obj\x64\Debug) 中的 pdb。

【问题讨论】：

它是有状态服务 asp.net 核心吗？您的解决方案中有任何类库项目吗？

我避免使用任何 asp.net 核心或 .net 核心。我在使用 Fabric 获得适合他们的平台和配置时遇到了太多问题。来自结构的直接部门是仅限 64 位的服务。其中的一两个，包括有状态服务，在任何 cpu 中构建的解决方案中引用一个类库。这可能会导致问题吗？

我看到一个问题，在更改类库的构建配置后会发生这种情况。在这种情况下，它通过辅助构建来解决。你是卡在构建中还是可以再做一个构建，这很好？

我可以通过第二次发布来解决，因为我认为它会停止 Fabric 应用程序的运行。但是两次构建或打包仍然失败。不过，我会在周一回到办公桌前确认这一点。

会是堆栈跟踪解析吗？当您抛出异常或以其他方式请求堆栈跟踪时，.NET 是否不会自动查找 PDB 以查看它是否可以将行号插入堆栈帧？

【参考方案1】：

根据提出的issue，现在看来此问题已修复。

“将关闭该问题，因为我们认为 5.6 运行时和 1.6 工具现已解决了这两个问题。”

似乎升级现在是第 4 点的答案。如果有人能回答 1-3，我会很乐意移动绿色的大勾号。